[ENet-discuss] enet is dropping packets
dreijer at echobit.net
Tue Jun 19 14:13:18 PDT 2012
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
> received any packets in X seconds do your own sleep(1) so you don't eat
> the cpu. also i don't know what platform you are on, but making enet
> 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
> 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
> > 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
> > huge delays in receiving packets because enet_host_service() wouldn't
> > until the timeout has expired. I'll verify that again, but I thought
> > was how it worked at least.
> > I find it hard to believe that my dedicated thread cannot service
> > for 124 users (who aren't really sending THAT much data) if the thread
> > running as fast as it can.
> ENet-discuss mailing list
> ENet-discuss at cubik.org
More information about the ENet-discuss