[ENet-discuss] enet is dropping packets

Ruud van Gaal ruud at racer.nl
Tue Jun 19 14:41:11 PDT 2012


What happens if you do pass 0 to the timeout, and let it just spin (as a
test)?
Does it still drop huge amounts of packets and expose the same kinds of
problems?
Ruud

On Tue, Jun 19, 2012 at 11:13 PM, Soren Dreijer <dreijer at echobit.net> wrote:

> Well, so regardless of whether the timer enet uses is inaccurate, it's
> guaranteed that enet_host_service() returns as soon as new packets have
> been
> received (courtesy of select()). That means that my process should be
> spinning at 100% CPU if it's struggling to keep up with all the incoming
> packets, but it isn't.
>
> That's what puzzles me. You're correct in that I could just do my own sleep
> to optimize the loop so I can send packets as fast as possible, but that
> doesn't solve the issue at hand, unfortunately.
>
> I'm trying to repro this in a staging environment since I can't just
> restart
> the server in production as it'll impact a good bunch of users.
>
> > -----Original Message-----
> > From: enet-discuss-bounces at cubik.org [mailto:enet-discuss-
> > bounces at cubik.org] On Behalf Of James B
> > Sent: Tuesday, June 19, 2012 3:54 PM
> > To: enet-discuss at cubik.org
> > Subject: Re: [ENet-discuss] enet is dropping packets
> >
> >
> > why not just call enet_host_service with a timeout of 0, then if you
> haven't
> > received any packets in X seconds do your own sleep(1) so you don't eat
> all
> > the cpu.  also i don't know what platform you are on, but making enet
> sleep
> > is not a wise choice IMO, for example on windows it uses timeGetTime
> which
> > can be 5ms or more inaccurate, meaning you could only be processing the
> > event loop 200 times per second rather than 1000 as you think.  what's
> worse
> > in my testing is Sleep() and timegettime can be more inaccurate than
> that,
> > sometimes sleep will sleep 5ms or 30ms, no matter the argument passed,
> > which is why its much better to use an adaptive technique where you only
> > sleep during times of low load, and where you control the sleep.  a good
> > implementation might be to examine your current packets processed per
> > second, and if this is under some value then sleep(1), if not then
> sleep(0)
> >
> > ----------------------------------------
> > > From: dreijer at echobit.net
> > > To: enet-discuss at cubik.org
> > > Date: Tue, 19 Jun 2012 15:30:14 -0500
> > > Subject: Re: [ENet-discuss] enet is dropping packets
> > >
> > > > Eh, it is an upper bound on the wait time if nothing is received!
> > >
> > > Are you absolutely sure about this? I seem to recall back when I
> started
> > > with enet that calling enet_host_service() with a high timeout would
> cause
> > > huge delays in receiving packets because enet_host_service() wouldn't
> > return
> > > until the timeout has expired. I'll verify that again, but I thought
> that
> > > was how it worked at least.
> > >
> > > I find it hard to believe that my dedicated thread cannot service
> packets
> > > for 124 users (who aren't really sending THAT much data) if the thread
> is
> > > running as fast as it can.
> >
> >
> > _______________________________________________
> > ENet-discuss mailing list
> > ENet-discuss at cubik.org
> > http://lists.cubik.org/mailman/listinfo/enet-discuss
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20120619/44d5d254/attachment-0001.html>


More information about the ENet-discuss mailing list