[ENet-discuss] enet is dropping packets

Soren Dreijer dreijer at echobit.net
Tue Jun 19 21:25:12 PDT 2012


I'll give that a try if I manage to reproduce it in the staging environment.

 

From: enet-discuss-bounces at cubik.org [mailto:enet-discuss-bounces at cubik.org]
On Behalf Of Ruud van Gaal
Sent: Tuesday, June 19, 2012 4:41 PM
To: Discussion of the ENet library
Subject: Re: [ENet-discuss] enet is dropping packets

 

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/7142bbb5/attachment.html>


More information about the ENet-discuss mailing list