[ENet-discuss] timer resolution

[Lee Salzman]

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
>