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

Mon Oct 22 02:56:35 PDT 2012

I think GetTickCount() has worse accuracy than timeGetTime() even (perhaps
also influenced by timeBeginPeriod() though).
Another option I use on PC's is QueryPerformanceTimer(), but I can imagine
those are a bit flaky on mobile or performance-tuning machines.

Cheers,
Ruud

On Mon, Oct 22, 2012 at 2:51 AM, Lee Salzman <lsalzman at gmail.com> wrote:

> 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<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<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<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<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<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<http://lists.cubik.org/mailman/listinfo/enet-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20121022/da7e6e3f/attachment-0001.html>