[ENet-discuss] timer resolution

[Brad Monahan]

I decided to use timeGetTime() with timeBeginPeriod() / timeEndPeriod() 
instead of the performance timers. I figured the nanosecond resolution 
wasn't _needed_ and a lot more editing of the library would have to be done. 
I also thought that anything <= 1ms resolution was good enough. I'm much 
more satisfied with that than with 10-20ms resolution. To implement you need 
to add two lines and edit two lines in the library as follows.

This needs to be added to enet_initialize():
timeBeginPeriod(1);

This needs to be added to enet_deinitialize();
timeEndPeriod(1);

This needs to be editing in enet_time_get():
from
return (enet_uint32) GetTickCount () - timeBase;
to
return (enet_uint32) timeGetTime () - timeBase;

This needs to be edited in enet_time_set():
from
timeBase = (enet_uint32) GetTickCount () - newTimeBase;
to
timeBase = (enet_uint32) timeGetTime () - newTimeBase;


The timeBeginPeriod() and timeEndPeriod() functions lowers the granularity 
of the timer to 1ms. timeEndPeriod() must be called with the same parameter 
used in timeBeginTime().


-Brad





>From: Lee Salzman <lsalzman at telerama.com>
>Reply-To: Discussion of the ENet library <enet-discuss at cubik.org>
>To: Discussion of the ENet library <enet-discuss at cubik.org>
>Subject: Re: [ENet-discuss] timer resolution
>Date: Sat, 28 Feb 2004 17:48:23 -0500
>
>I bid thee: send me a patch. :) I don't know quite enough about Win32 to
>implement this myself, but just enough to get myself in trouble. If the
>patch looks sane, I will integrate it.
>
>In so far as unix playforms and portability, I have to count on
>gettimeofday() to do the Right Thing with respect to timer resolution. I
>know Linux is really good about this and does not exclusively rely on
>its 100 Hz timer, and augments it with info from the time stamp counter
>on x86.
>
>Lee
>
>On Sat, Feb 28, 2004 at 09:31:24PM +0000, Brad Monahan wrote:
> > I noticed enet uses GetTickCount() for timing in the win32 side of 
>things.
> > I'm in the process of changing this so it uses QueryPerformanceCounter
> > instead, falling back on timeGetTime and timeBeginPeriod/timeEndPeriod 
>(for
> > up to 1ms resolution) if the performance timer is not available. I'm 
>using
> > the roundTripTime calculated by enet for the interpolation/extrapolation 
>on
> > my client and it seems to not be accurate enough for this purpose. 
>Should I
> > even be doing this? I thought that was a feature of enet. It keeps track 
>of
> > the average ping so you can do stuff like that. I know GetTickCount() 
>has
> > _atleast_ a 10ms resolution if not closer to 20ms (if I remember 
>correctly)
> > and the performance timer has well under 1ms resolution. This is just a
> > suggestion post for the next version of enet. It would be very easy to
> > implement and there would be a much greater performance aspect. I don't
> > know how good the unix timer is or it's resolution, so I can't offer
> > anything on the unix side of things, but this would make a great 
>addition
> > on the win32 side.
> >
> > -Brad
> >
>
>_______________________________________________
>ENet-discuss mailing list
>ENet-discuss at cubik.org
>http://lists.cubik.org/mailman/listinfo/enet-discuss

_________________________________________________________________
Store more e-mails with MSN Hotmail Extra Storage – 4 plans to choose from! 
http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/