[ENet-discuss] Enet's Timer Precision Needs (timeBeginPeriod)

[Lee Salzman]

You can try replacing it with something like GetTickCount() in the code instead of using the timeBeginPeriod/timeGetTime stuff and see what happens... Really, I can't entirely predict how much this will break ENet's timing or not, try and see...

On 10/22/2012 02:58 AM, Mike Kasprzak wrote:
> (Hey Sven)
>
> Okay, then let me give a practical example so I don't get a "you
> should always use 1ms" response. ;)
>
> To meet Intel's Power Certification requirements, an application must
> idle (not run, but idle) with a timer period 15.6 ms. Basically, if
> you never call "timeBeginPeriod", then you pass. timeBeginPeriod
> changes the ms clock rate of all running applications on Windows, and
> the lowest period set will always have priority. Lower timer periods
> across all of Windows have an effect on power drain, and that is why
> they care. If you're the main in-focus application it's fine, but if
> you're minimized, it's "not neighborly" to be forcing other
> applications to run at a lower timer period when they don't need to.
> At least, that's the best way I can think of to explain that
> requirement.
>
> So the practical use: A game would want to set it to 1 ms due to
> broken vsync and better ping, but if the game is minimized then it
> doesn't need such a low rate.
>
> I found calls to "timeBeginPeriod" in SDL and enet. Again, it's right
> there in the win32 implementation of enet_initialize.
>
> Now sure, I can just go right in to win32.c and remove it. Easy.
> That's not the issue.
>
> The issue is if I do that, can anyone think of a reason enet will break on me?
>
> And with that in mind, should enet be doing this all the time anyways?
> SDL gives you the option of building the SDL library without timer
> support, which is a way of disabling it.
>
> I'm totally cool with it staying as a default and all, but should
> there be a "proper" way of disabling it besides editing source? Then
> it becomes my responsibility to set the timer period on Windows as I
> gain/lose application focus (or not at all). I'm just hoping there's
> not some reason enet will suddenly start losing data because my clock
> updates are 15ms slow. :)
>
> Thanks,
>
> Mike Kasprzak
> Sykhronics Entertainment
> www.sykhronics.com
>
>
> On Sun, Oct 21, 2012 at 6:57 PM, Sven Bergström<fuzzyspoon at gmail.com>  wrote:
>> MIKE, what are you doing on my list!
>>
>> So, I think it's also implementation detail of the game itself, much like
>> ruud suggests.
>> Some games would not need lower precision, some games would.
>>
>> Though that doesn't mean I understand the full extent of the changes on ENet
>> internals,
>> it doesn't appear to (by digging around in the code) change enough to cause
>> problems.
>>
>> I'd wait for lee to weigh in, though.
>>
>> Sven
>>
>>
>> On Sun, Oct 21, 2012 at 7:49 PM, Ruud van Gaal<ruud at racer.nl>  wrote:
>>> I would say the time accuracy has an influence on ping time, where it
>>> helps to get millsecond accuracy instead of just 15ms.
>>> Resend times are big enough to probably not be influenced much.
>>>
>>> Still, any game quickly uses 1ms timing, if only for accurate fps timing.
>>>
>>> I think ENet will run, but just a bit more jerky than is needed.
>>>
>>> Ruud
>>>
>>>
>>> On Sun, Oct 21, 2012 at 6:06 PM, Mike Kasprzak<mike at sykhronics.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> I have a bit of an overly technical enet implementation question, so
>>>> apologies in advance.
>>>>
>>>> Long story short, I've been going through and doing some work to make
>>>> an older game of mine pass Intel's power use certification tests. To
>>>> do that, you run Intel's Power Checker tool alongside your app/game:
>>>>
>>>>
>>>> http://software.intel.com/en-us/software-assessment?&paneltab[tabs-28-main]=pid-252-28#pid-252-28
>>>>
>>>> The older game is totally single player game that doesn't use
>>>> networking at all. That said, I was investigating one of my fail
>>>> points (timer precision) by running my new games client and server,
>>>> where I noticed even the server (without any graphics at all) was also
>>>> using a 1ms precision. A bunch of digging later, I found a
>>>> "timeBeginPeriod (1);" call inside win32 implementation of
>>>> enet_initialize.
>>>>
>>>> My question is: How important is timer precision to enet's overall
>>>> implementation?
>>>>
>>>> I realize that's a vague question, so let me clarify. Raising (or not
>>>> changing) the timer precision means calls to timeGetTime() will simply
>>>> not return new numbers until the timer period has passed. So, if the
>>>> Windows default of 15ms is used, no matter how many times you call it
>>>> during those 15ms, it will not change. For reference, timeGetTime is
>>>> used inside enet_time_get and enet_time_set, so that's how it affects
>>>> enet.
>>>>
>>>> So a better question: What would a lower precision timer break in enet?
>>>>
>>>> Like, is the time used in any way that may delay packets? Or is it
>>>> purely statistical, like it will just ruin our frame of reference on
>>>> when a packet was sent/received?
>>>>
>>>> Thanks,
>>>>
>>>> Mike Kasprzak
>>>> Sykhronics Entertainment
>>>> www.sykhronics.com
>>>> _______________________________________________
>>>> 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
>>>
>>
>> _______________________________________________
>> 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
>