[771] Delay and Timer granularity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[771] Delay and Timer granularity

Steven Kelly
What is the expected duration of "(Delay forMilliseconds: 1) wait"? I
was surprised to find that it actually takes 15ms, even with the new
Timer mechanism enabled, and on Windows>=Vista with
UseThreadpoolAPI=true. Interestingly, it's not just an overhead, it's a
rounding up to the next 15ms. Delays from 1-15ms all take 15ms, and from
16-30ms all take 30ms. The same results are seen with "Timer after: 1
milliseconds signal: sem".

The documentation in TimerSystem says that I should see a granularity of
~1ms. Is that incorrect, or am I doing something wrong? I've attached my
test code - run the first line, save and restart, then inspect the rest.

Cheers,
Steve


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Delay&TimerGranularity.txt (624 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Henrik Hoyer

This is normal behavior on Windows

http://www.geisswerks.com/ryan/FAQS/timing.html
/Henrik Hoyer
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Steven Kelly
Henrik Hoyer wrote:
> This is normal behavior on Windows
>
> http://www.geisswerks.com/ryan/FAQS/timing.html

The simpler timing mechanisms on NT-based Windows have a granularity of
15ms (or 10ms for single processor machines). But VW can use smarter
mechanisms, e.g. the microsecond clock is now accurate, as seen in
#microsecondsToRun:. And the documentation of the new native Timers says
they should be around 1ms, as I wrote.

Steve

PS The link you reference is rather out of date, missing info on XP,
Vista and Win7. Better information can be found e.g. here:

http://stackoverflow.com/questions/3763544/what-periodic-timer-objects-a
re-available-in-the-windows-api

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Andres Valloud-6
In reply to this post by Steven Kelly
Off the top of my head, I wonder what is the behavior of
QueryPerformanceCounter() on that machine.  We had an instance of a
customer for which (Delay forSeconds: 1) wait took ~20 seconds of wall
time on an XP machine.  As it turns out, MSDN states in various places
that, on XP, you might need the /usepmtimer boot.ini switch to work
around various bugs that have accumulated over the years.  I'd go take a
look at the QueryPerformanceCounter() MSDN documentation from a Vista
point of view.

On 9/23/2011 5:02 AM, Steven Kelly wrote:

> What is the expected duration of "(Delay forMilliseconds: 1) wait"? I
> was surprised to find that it actually takes 15ms, even with the new
> Timer mechanism enabled, and on Windows>=Vista with
> UseThreadpoolAPI=true. Interestingly, it's not just an overhead, it's a
> rounding up to the next 15ms. Delays from 1-15ms all take 15ms, and from
> 16-30ms all take 30ms. The same results are seen with "Timer after: 1
> milliseconds signal: sem".
>
> The documentation in TimerSystem says that I should see a granularity of
> ~1ms. Is that incorrect, or am I doing something wrong? I've attached my
> test code - run the first line, save and restart, then inspect the rest.
>
> Cheers,
> Steve
>
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Steven Kelly
Re: [vwnc] [771] Delay and Timer granularity
Thanks Andres. It looks like the new threadpool timers might not work as well on Windows 7. I've now tried on three Windows 7 machines with different hardware and OS histories, and all gave the same results as below. The microsecond clock works fine, not sure if that uses QueryPerformanceCounter().
 
On an old Vista laptop, the results were much better, around the documented ~1ms granularity and accuracy.
 
Since our Windows customers are on XP and Windows 7, I guess I either need to expect 15ms granularity, or then roll my own for now. It would be nice to have a timer that works on all three Windows versions with a 1ms granularity - Timer Queues seem to offer one: http://msdn.microsoft.com/en-us/library/ms686796(v=VS.85).aspx
 
Steve
 


From: [hidden email] on behalf of Andres Valloud
Sent: Sat 24/09/2011 09:34
To: [hidden email]
Subject: Re: [vwnc] [771] Delay and Timer granularity

Off the top of my head, I wonder what is the behavior of
QueryPerformanceCounter() on that machine.  We had an instance of a
customer for which (Delay forSeconds: 1) wait took ~20 seconds of wall
time on an XP machine.  As it turns out, MSDN states in various places
that, on XP, you might need the /usepmtimer boot.ini switch to work
around various bugs that have accumulated over the years.  I'd go take a
look at the QueryPerformanceCounter() MSDN documentation from a Vista
point of view.

On 9/23/2011 5:02 AM, Steven Kelly wrote:


> What is the expected duration of "(Delay forMilliseconds: 1) wait"? I
> was surprised to find that it actually takes 15ms, even with the new
> Timer mechanism enabled, and on Windows>=Vista with
> UseThreadpoolAPI=true. Interestingly, it's not just an overhead, it's a
> rounding up to the next 15ms. Delays from 1-15ms all take 15ms, and from
> 16-30ms all take 30ms. The same results are seen with "Timer after: 1
> milliseconds signal: sem".
>
> The documentation in TimerSystem says that I should see a granularity of
> ~1ms. Is that incorrect, or am I doing something wrong? I've attached my
> test code - run the first line, save and restart, then inspect the rest.
>
> Cheers,
> Steve
>
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Steven Kelly
Re: [vwnc] [771] Delay and Timer granularity
Just tried again on the Vista machine after hibernate+wake, and now that too gives 15ms. Starting the same programs that were open during the previous test doesn't change this. I guess some other program had asked for 1ms timer granularity (with timeBeginPeriod?). Maybe VW should offer that too? Off by default, since it reduces battery life by 25%.


From: Steven Kelly

Thanks Andres. It looks like the new threadpool timers might not work as well on Windows 7. I've now tried on three Windows 7 machines with different hardware and OS histories, and all gave the same results as below. The microsecond clock works fine, not sure if that uses QueryPerformanceCounter().
 
On an old Vista laptop, the results were much better, around the documented ~1ms granularity and accuracy.
 
Since our Windows customers are on XP and Windows 7, I guess I either need to expect 15ms granularity, or then roll my own for now. It would be nice to have a timer that works on all three Windows versions with a 1ms granularity - Timer Queues seem to offer one: http://msdn.microsoft.com/en-us/library/ms686796(v=VS.85).aspx
 
Steve
 


From: [hidden email] on behalf of Andres Valloud
Sent: Sat 24/09/2011 09:34
To: [hidden email]
Subject: Re: [vwnc] [771] Delay and Timer granularity

Off the top of my head, I wonder what is the behavior of
QueryPerformanceCounter() on that machine.  We had an instance of a
customer for which (Delay forSeconds: 1) wait took ~20 seconds of wall
time on an XP machine.  As it turns out, MSDN states in various places
that, on XP, you might need the /usepmtimer boot.ini switch to work
around various bugs that have accumulated over the years.  I'd go take a
look at the QueryPerformanceCounter() MSDN documentation from a Vista
point of view.

On 9/23/2011 5:02 AM, Steven Kelly wrote:


> What is the expected duration of "(Delay forMilliseconds: 1) wait"? I
> was surprised to find that it actually takes 15ms, even with the new
> Timer mechanism enabled, and on Windows>=Vista with
> UseThreadpoolAPI=true. Interestingly, it's not just an overhead, it's a
> rounding up to the next 15ms. Delays from 1-15ms all take 15ms, and from
> 16-30ms all take 30ms. The same results are seen with "Timer after: 1
> milliseconds signal: sem".
>
> The documentation in TimerSystem says that I should see a granularity of
> ~1ms. Is that incorrect, or am I doing something wrong? I've attached my
> test code - run the first line, save and restart, then inspect the rest.
>
> Cheers,
> Steve
>
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Steven Kelly
Re: [vwnc] [771] Delay and Timer granularity
And the solution is... (drum-roll)... open a Youtube video! If that's in a visible tab of my browser, on Win7 I get 1ms granularity. If it's in a non-visible tab, I get 10ms granularity.


From: Steven Kelly
Just tried again on the Vista machine after hibernate+wake, and now that too gives 15ms. Starting the same programs that were open during the previous test doesn't change this. I guess some other program had asked for 1ms timer granularity (with timeBeginPeriod?). Maybe VW should offer that too? Off by default, since it reduces battery life by 25%.


From: Steven Kelly

Thanks Andres. It looks like the new threadpool timers might not work as well on Windows 7. I've now tried on three Windows 7 machines with different hardware and OS histories, and all gave the same results as below. The microsecond clock works fine, not sure if that uses QueryPerformanceCounter().
 
On an old Vista laptop, the results were much better, around the documented ~1ms granularity and accuracy.
 
Since our Windows customers are on XP and Windows 7, I guess I either need to expect 15ms granularity, or then roll my own for now. It would be nice to have a timer that works on all three Windows versions with a 1ms granularity - Timer Queues seem to offer one: http://msdn.microsoft.com/en-us/library/ms686796(v=VS.85).aspx
 
Steve
 


From: [hidden email] on behalf of Andres Valloud
Sent: Sat 24/09/2011 09:34
To: [hidden email]
Subject: Re: [vwnc] [771] Delay and Timer granularity

Off the top of my head, I wonder what is the behavior of
QueryPerformanceCounter() on that machine.  We had an instance of a
customer for which (Delay forSeconds: 1) wait took ~20 seconds of wall
time on an XP machine.  As it turns out, MSDN states in various places
that, on XP, you might need the /usepmtimer boot.ini switch to work
around various bugs that have accumulated over the years.  I'd go take a
look at the QueryPerformanceCounter() MSDN documentation from a Vista
point of view.

On 9/23/2011 5:02 AM, Steven Kelly wrote:


> What is the expected duration of "(Delay forMilliseconds: 1) wait"? I
> was surprised to find that it actually takes 15ms, even with the new
> Timer mechanism enabled, and on Windows>=Vista with
> UseThreadpoolAPI=true. Interestingly, it's not just an overhead, it's a
> rounding up to the next 15ms. Delays from 1-15ms all take 15ms, and from
> 16-30ms all take 30ms. The same results are seen with "Timer after: 1
> milliseconds signal: sem".
>
> The documentation in TimerSystem says that I should see a granularity of
> ~1ms. Is that incorrect, or am I doing something wrong? I've attached my
> test code - run the first line, save and restart, then inspect the rest.
>
> Cheers,
> Steve
>
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Michael Lucas-Smith-2
Hi Steve,

We use WaitForSingleObject in the "classic" timers (we manage our own sorted queue of timer alarms instead of having the operating system do it). However, we never call timeBeginPeriod(). If you'd be so kind as to stop watching youtube videos; could you please try calling timeBeginPeriod() from DLLCC in your image to see if it can affect your timer resolution?

timeBeginPeriod: resolution
    <C: unsigned int timeBeginPeriod(unsigned int resolution)>
    ^self externalAccessFailedWith: _errorCode

If the result is > 0 then it failed and you can see what kind of error here: http://pinvoke.net/default.aspx/winmm/MMRESULT.html

This could be a very interesting change, as timeBeginPeriod should be transparent to all other win32 calls we make from the VM.

Cheers,
Michael


On Sep 24, 2011, at 10:26 AM, Steven Kelly wrote:

Re: [vwnc] [771] Delay and Timer granularity
And the solution is... (drum-roll)... open a Youtube video! If that's in a visible tab of my browser, on Win7 I get 1ms granularity. If it's in a non-visible tab, I get 10ms granularity.


From: Steven Kelly
Just tried again on the Vista machine after hibernate+wake, and now that too gives 15ms. Starting the same programs that were open during the previous test doesn't change this. I guess some other program had asked for 1ms timer granularity (with timeBeginPeriod?). Maybe VW should offer that too? Off by default, since it reduces battery life by 25%.


From: Steven Kelly

Thanks Andres. It looks like the new threadpool timers might not work as well on Windows 7. I've now tried on three Windows 7 machines with different hardware and OS histories, and all gave the same results as below. The microsecond clock works fine, not sure if that uses QueryPerformanceCounter().
 
On an old Vista laptop, the results were much better, around the documented ~1ms granularity and accuracy.
 
Since our Windows customers are on XP and Windows 7, I guess I either need to expect 15ms granularity, or then roll my own for now. It would be nice to have a timer that works on all three Windows versions with a 1ms granularity - Timer Queues seem to offer one: http://msdn.microsoft.com/en-us/library/ms686796(v=VS.85).aspx
 
Steve
 


From: [hidden email] on behalf of Andres Valloud
Sent: Sat 24/09/2011 09:34
To: [hidden email]
Subject: Re: [vwnc] [771] Delay and Timer granularity

Off the top of my head, I wonder what is the behavior of
QueryPerformanceCounter() on that machine.  We had an instance of a
customer for which (Delay forSeconds: 1) wait took ~20 seconds of wall
time on an XP machine.  As it turns out, MSDN states in various places
that, on XP, you might need the /usepmtimer boot.ini switch to work
around various bugs that have accumulated over the years.  I'd go take a
look at the QueryPerformanceCounter() MSDN documentation from a Vista
point of view.

On 9/23/2011 5:02 AM, Steven Kelly wrote:


> What is the expected duration of "(Delay forMilliseconds: 1) wait"? I
> was surprised to find that it actually takes 15ms, even with the new
> Timer mechanism enabled, and on Windows>=Vista with
> UseThreadpoolAPI=true. Interestingly, it's not just an overhead, it's a
> rounding up to the next 15ms. Delays from 1-15ms all take 15ms, and from
> 16-30ms all take 30ms. The same results are seen with "Timer after: 1
> milliseconds signal: sem".
>
> The documentation in TimerSystem says that I should see a granularity of
> ~1ms. Is that incorrect, or am I doing something wrong? I've attached my
> test code - run the first line, save and restart, then inspect the rest.
>
> Cheers,
> Steve
>
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [771] Delay and Timer granularity

Steven Kelly
Re: [vwnc] [771] Delay and Timer granularity

Hi Michael,

 

Fortunately I could watch the Youtube videos on my other computer, so my day wasn’t ruined ;). The test is a success, timeBeginPeriod works for both classic and native timers and delays. With the classic TimerSystem, timers and delays have an “overhead” of about 1ms; with the native TimerSystem, there is no noticeable overhead.

 

#classicTimer -> #(1896 2990 3988 4889 5981 6977 7977 8973 9970 10967 11964 12962 13958 14955 15851 16950 17944 18939 19941 20941)

#classicDelay -> #(1991 2892 3988 4986 5882 6977 7977 8973 9970 10965 11964 12962 13956 14955 15953 16949 17945 18943 19944 20933)

 

#nativeTimer -> #(1004 2000 4085 4208 4993 5993 6984 7984 8981 9973 10981 11975 12973 13964 14972 15964 16963 17961 18958 19961)

#nativeDelay -> #(1069 2007 3005 3989 5086 5992 6980 7986 8974 9988 10978 11976 12971 13969 14970 15966 16960 17963 18962 19957)

Windows 7 SP1 64-bit, Intel i5, VW 7.7.1 Version Id: #[68 47 69 160 77 1 0 0 68 47 69 160]

 

I’ve published WindowsTimerResolution in the public store repository. To improve the resolution, call #milliseconds:while:, e.g.

 

                             WindowsTimerResolution milliseconds: 1 while:

                                                          [Time microsecondsToRun: [1000 timesRepeat: [(Delay forMilliseconds: 1) wait]]]

 

Cheers,

Steve

 

From: Michael Lucas-Smith [mailto:[hidden email]]
Sent: 26. syyskuuta 2011 22:39
To: Steven Kelly
Cc: [hidden email]
Subject: Re: [vwnc] [771] Delay and Timer granularity

 

Hi Steve,

 

We use WaitForSingleObject in the "classic" timers (we manage our own sorted queue of timer alarms instead of having the operating system do it). However, we never call timeBeginPeriod(). If you'd be so kind as to stop watching youtube videos; could you please try calling timeBeginPeriod() from DLLCC in your image to see if it can affect your timer resolution?

 

timeBeginPeriod: resolution

    <C: unsigned int timeBeginPeriod(unsigned int resolution)>

    ^self externalAccessFailedWith: _errorCode

 

If the result is > 0 then it failed and you can see what kind of error here: http://pinvoke.net/default.aspx/winmm/MMRESULT.html

 

This could be a very interesting change, as timeBeginPeriod should be transparent to all other win32 calls we make from the VM.

 

Cheers,

Michael

 

 

On Sep 24, 2011, at 10:26 AM, Steven Kelly wrote:



And the solution is... (drum-roll)... open a Youtube video! If that's in a visible tab of my browser, on Win7 I get 1ms granularity. If it's in a non-visible tab, I get 10ms granularity.

 


From: Steven Kelly

Just tried again on the Vista machine after hibernate+wake, and now that too gives 15ms. Starting the same programs that were open during the previous test doesn't change this. I guess some other program had asked for 1ms timer granularity (with timeBeginPeriod?). Maybe VW should offer that too? Off by default, since it reduces battery life by 25%.

 


From: Steven Kelly

Thanks Andres. It looks like the new threadpool timers might not work as well on Windows 7. I've now tried on three Windows 7 machines with different hardware and OS histories, and all gave the same results as below. The microsecond clock works fine, not sure if that uses QueryPerformanceCounter().

 

On an old Vista laptop, the results were much better, around the documented ~1ms granularity and accuracy.

 

Since our Windows customers are on XP and Windows 7, I guess I either need to expect 15ms granularity, or then roll my own for now. It would be nice to have a timer that works on all three Windows versions with a 1ms granularity - Timer Queues seem to offer one: http://msdn.microsoft.com/en-us/library/ms686796(v=VS.85).aspx

 

Steve

 

 


From: [hidden email] on behalf of Andres Valloud
Sent: Sat 24/09/2011 09:34
To: [hidden email]
Subject: Re: [vwnc] [771] Delay and Timer granularity

Off the top of my head, I wonder what is the behavior of
QueryPerformanceCounter() on that machine.  We had an instance of a
customer for which (Delay forSeconds: 1) wait took ~20 seconds of wall
time on an XP machine.  As it turns out, MSDN states in various places
that, on XP, you might need the /usepmtimer boot.ini switch to work
around various bugs that have accumulated over the years.  I'd go take a
look at the QueryPerformanceCounter() MSDN documentation from a Vista
point of view.

On 9/23/2011 5:02 AM, Steven Kelly wrote:


> What is the expected duration of "(Delay forMilliseconds: 1) wait"? I
> was surprised to find that it actually takes 15ms, even with the new
> Timer mechanism enabled, and on Windows>=Vista with
> UseThreadpoolAPI=true. Interestingly, it's not just an overhead, it's a
> rounding up to the next 15ms. Delays from 1-15ms all take 15ms, and from
> 16-30ms all take 30ms. The same results are seen with "Timer after: 1
> milliseconds signal: sem".
>
> The documentation in TimerSystem says that I should see a granularity of
> ~1ms. Is that incorrect, or am I doing something wrong? I've attached my
> test code - run the first line, save and restart, then inspect the rest.
>
> Cheers,
> Steve
>
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc