What is a tick?
lair...@gmail.com
curious as to the origin of this . It seems to have something to do
with the tick cycle which dictates timing in the cpu. How does a tick
occur? Is it the transition of voltage in and out of some sort of
"thing" that signals a tick? (i'm obviously far from an electrical
engineer here) Is Tick and Clock Cycle interchangeable terminology? I
appreciate any references or input to further clarify how this works
and why it causes this accuracy issue in Windows. Thanks.
Del Cecchi
processor a time reference at 3.3ms intervals. The 3.3 ms doesn't
dictate timing in the cpu, but is provided by or to the cpu.
So if you use the tick to time something, there is a granularity issue.
--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”
George Neuner
>I came across the 3.3 millisecond accuracy issue in Windows
What 3.3ms issue? AFAIK, there is only a 10ms (read) and 2s (write)
issue with file time stamps and a 1us issue with process times on
chips without cycle counters.
At least since NT4 (and I think before that as well), Windows has run
the system heartbeat timer at 1MHz, giving 1us accuracy for timing.
On newer chips with cycle counters, the system time is kept in 100ns
intervals, figured from the cycle count at each heartbeat interrupt.
You can easily get single microsecond accuracy on a fast (1Ghz) P3 or
on any P4 (I haven't played much with AMD chips, but I suspect
comparable chips will behave the same).
> Is Tick and Clock Cycle interchangeable terminology?
No. "Tick" is Microsoft terminology for the system heartbeat
interrupt. It dates back to DOS and Windows cooperative multitasking
days. Forget about C/C++ time calls and don't use any of the Windows
time functions that have "tick" in the name ... they are all
deprecated as of the Win32 API. Instead get familiar with
GetSystemTimeAsFileTime() and use it as your basic timing function.
If you need more accuracy, you can read the CPU cycle counters (if the
chip has them) directly using QueryPerformanceCounter() and
QueryPerformanceFrequency().
George
--
for email reply remove "/" from address
Rick Jones
> Instead get familiar with GetSystemTimeAsFileTime() and use it as
> your basic timing function.
IIRC that is one that only increments 10 ms at a time right? But gives
"wall clock" time.
> If you need more accuracy, you can read the CPU cycle counters (if
> the chip has them) directly using QueryPerformanceCounter() and
> QueryPerformanceFrequency().
And those will give _relative_ time.
Is there a way to get "wall clock" time more "accurate" (or should
that be precise? I'm always confusing the two) than
GetSystemTimeAsFileTime() ?
rick jones
might want to use the answer in netperf2/netperf4
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
Terje Mathisen
> George Neuner <gneuner2/@comcast.net> wrote:
>> Instead get familiar with GetSystemTimeAsFileTime() and use it as
>> your basic timing function.
>
> IIRC that is one that only increments 10 ms at a time right? But gives
> "wall clock" time.
>
>> If you need more accuracy, you can read the CPU cycle counters (if
>> the chip has them) directly using QueryPerformanceCounter() and
>> QueryPerformanceFrequency().
>
> And those will give _relative_ time.
>
> Is there a way to get "wall clock" time more "accurate" (or should
> that be precise? I'm always confusing the two) than
> GetSystemTimeAsFileTime() ?
Yes, by using the same kludge as the Win* port of NTPD:
Start a realtime thread that wakes up on every timer tick: Since it has
maximum priority it will always be at or very near the top of the
priority list when the timer interrupt starts the scheduler.
This thread will then sample both the PerformanceCounter and the system
time, so that these two values can then be used to interpolate any
timestamps taken between two system ticks.
Afaik, _every_ single current/modern OS will do this interpolation as
part of the kernel clock interrupt, _except_ Windows. To add insult to
injury, the low-level clock handler is part of the HAL (Hardware
Abstraction Layer), which presumable means that even a kernel mode
driver can't fix the problem. :-(
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Rick Jones
> Yes, by using the same kludge as the Win* port of NTPD:
> Start a realtime thread that wakes up on every timer tick: Since it has
> maximum priority it will always be at or very near the top of the
> priority list when the timer interrupt starts the scheduler.
> This thread will then sample both the PerformanceCounter and the system
> time, so that these two values can then be used to interpolate any
> timestamps taken between two system ticks.
I was afraid it might be a kludge like that. Never ceases to amaze me
that the time is returned in units of nanoseconds or somesuch but only
increments 10 ms at a time.
thanks,
rick jones
--
Process shall set you free from the need for rational thought.
George Neuner
wrote:
>George Neuner <gneuner2/@comcast.net> wrote:
>> Instead get familiar with GetSystemTimeAsFileTime() and use it as
>> your basic timing function.
>
>IIRC that is one that only increments 10 ms at a time right? But gives
>"wall clock" time.
I believe you are thinking of GetTickCount() - it has been deprecated
in Win32.
You're correct that all the "SystemTime" functions return wall time.
You can use GetThreadTimes() and GetProcessTimes() to retrieve elapsed
run times.
The accuracy depends on the particular call and on the OS version. NT
did not use the CPU cycle counters to correct clock drift due to
disabled interrupts, that functionality was introduced in 2K. I don't
know whether ME implements it ... 95/98 do not.
On NT/2K/XP, the Get*Times calls are accurate to 1ms (ala Un*x) and
System time is [theoretically] accurate to 1us because the heartbeat
interrupt frequency on all these systems is 1Mhz.
I have measured clock accuracy - using a digital scope and toggling
I/O ports - on fast (1Ghz) P3s and on P4s running NT4 at ą6us. On
2K/XP systems, the System time *should* be accurate to 1us because
interrupt drift is corrected using the cycle counters.
The system I worked on was a HRT multi-role industrial vision
application with many different hard timing constraints ranging from
500us up to 600ms - with judicious design NT4 proved more than
adequate to handle it all reliably. The RT imaging code I wrote is
currently running unchanged on 2K (with a slightly different GUI) but
I am not involved with it any more and I have not had other reasons to
check the clock accuracy on that platform.
>Is there a way to get "wall clock" time more "accurate" (or should
>that be precise? I'm always confusing the two) than
>GetSystemTimeAsFileTime() ?
"Accuracy" - more precision in the answer won't help because the extra
bits are not significant. Unfortunately, GetSystemTimeAsFileTime() is
the best you can do.
The real question is whether the event duration is below the accuracy
of the clock. When you are talking about "wall" time, you generally
are dealing with long duration events ... the human visual perception
threshold is ~45ms and stimulus response time rarely is below 100ms.
The SystemTime calls are plenty accurate for things like that.
If I may ask ... what is it that are you trying to time so accurately?
Rick Jones
> in Win32.
I'm thinking of GetSystemTimeAsFileTime().
> On NT/2K/XP, the Get*Times calls are accurate to 1ms (ala Un*x) and
So, I'm probably about to mix-up accuracy vs precision, but for some
time now I've been getting gettimeofday() measuring things much
smaller than 1ms.
> System time is [theoretically] accurate to 1us because the heartbeat
> interrupt frequency on all these systems is 1Mhz.
Hmm, perhaps I slipped some digits in looking at the output, but the
little test program I wrote on an XP Pro PentiumM laptop suggested that
GetSystemTimeAsFileTime() was only incrementing in units of 10 ms.
> The system I worked on was a HRT multi-role industrial vision
> application with many different hard timing constraints ranging from
> 500us up to 600ms - with judicious design NT4 proved more than
> adequate to handle it all reliably. The RT imaging code I wrote is
> currently running unchanged on 2K (with a slightly different GUI)
> but I am not involved with it any more and I have not had other
> reasons to check the clock accuracy on that platform.
> If I may ask ... what is it that are you trying to time so accurately?
Individual transaction times in a netperf TCP_RR test. Although for
that I don't need wall-clock time.
I'm also asking about it because the glib-2.0 stuff implements their
"gettimeofday-like" g_get_current_time() by calling
GetSystemTimeAsFileTime() and I'm concerned about folks used to using
gettimeofday() to measure things much shorter than 10 ms getting bogus
results. Similar problems affected SPECweb96 back when one of the
platforms on which it was run got individual op times below 10 ms and
suddenly they started taking "0" time.
rick jones
--
a wide gulf separates "what if" from "if only"
David Hopwood
> On Fri, 05 May 2006 16:45:00 GMT, Rick Jones <rick....@hp.com> wrote:
>>George Neuner <gneuner2/@comcast.net> wrote:
>>
>>>Instead get familiar with GetSystemTimeAsFileTime() and use it as
>>>your basic timing function.
>>
>>IIRC that is one that only increments 10 ms at a time right? But gives
>>"wall clock" time.
>
> I believe you are thinking of GetTickCount() - it has been deprecated
> in Win32.
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp>
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecoreos5/html/wce50lrfGetTickCount.asp>
Doesn't look deprecated to me.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
George Neuner
<david.nosp...@blueyonder.co.uk> wrote:
>George Neuner wrote:
>> I believe you are thinking of GetTickCount() - it has been deprecated
>> in Win32.
>
><http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp>
><http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecoreos5/html/wce50lrfGetTickCount.asp>
>
>Doesn't look deprecated to me.
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/windows_time.asp
Which says:
Windows Time
Windows time is the number of milliseconds elapsed since the system
started running. This format exists primarily for backward
compatibility with 16-bit Windows. To ensure that applications
designed for 16-bit Windows continue to run successfully, the
GetTickCount function returns the current Windows time.
You typically use GetTickCount to compare the current Windows time
with the time returned by the GetMessageTime function. GetMessageTime
returns the Windows time when the specified message was created.
GetTickCount is limited to the resolution of the system timer.
The system timer runs at approximately 10ms.
Windows Me/98/95: The system timer runs at approximately 55ms.
:
:
GetTickCount has been entirely superceded by the SystemTime group of
functions. MS has retained it and even increased its usefulness a bit
by providing GetSystemTimeAdjustment which will tell you the tick
granularity, but I still wouldn't use it in place of the standard
Win32 time functions.
George Neuner
<gneuner2/@comcast.net> wrote:
>At least since NT4 (and I think before that as well), Windows has run
>the system heartbeat timer at 1MHz, giving 1us accuracy for timing.
>On newer chips with cycle counters, the system time is kept in 100ns
>intervals, figured from the cycle count at each heartbeat interrupt.
>
>You can easily get single microsecond accuracy on a fast (1Ghz) P3 or
>on any P4 (I haven't played much with AMD chips, but I suspect
>comparable chips will behave the same).
Okay. I just returned from some experiments and it seems that XP does
things very differently from NT4 and 2K.
It appears that the default clock period for XP *is* at least 10ms ...
on my machine it actually appears to be 10ms on XPhome and 15ms on
XPpro ... and this granularity affects all the standard Win32 time
functions. To get higher resolution timing you now *must* use the
multimedia time functions or the performance counters.
I find this quite disappointing as I had alway been impressed with
Windows SRT abilities despite not being designed as a "real" RTOS.
NT4 was more than good enough to use as a base for industrial vision
systems with <1ms interrupt response deadlines and 50..500ms HRT
processing deadlines. I developed several vision systems in the mid
90's that all initially ran on top of NT4 desktop [for GUI support]
and are now running on 2Kpro. Each system produces timing logs (using
GetSystemTimeAsFileTime) during operation which show when events are
received, when various processing steps begin and how long each step
takes. I have old run logs which clearly show consecutive event time
stamps with millisecond and sub-millisecond spacing between.
I have gotten away from real time coding in recent years so I was
unaware of the time related changes MS made to XP. I apologize to
everyone for giving out of date information.
Niels Jørgen Kruse
> It appears that the default clock period for XP *is* at least 10ms ...
> on my machine it actually appears to be 10ms on XPhome and 15ms on
> XPpro ... and this granularity affects all the standard Win32 time
> functions. To get higher resolution timing you now *must* use the
> multimedia time functions or the performance counters.
The higher the resolution, the more trouble with clock drift in big
SMPs. Perhaps that is the reason for the reduction in resolution.
Windows has been moving into bigger systems.
How well does these multimedia time functions work? I suppose they don't
give wall clock time?
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
David Hopwood
> On Sat, 06 May 2006 00:40:13 GMT, David Hopwood
> <david.nosp...@blueyonder.co.uk> wrote:
>>George Neuner wrote:
>>
>>>I believe you are thinking of GetTickCount() - it has been deprecated
>>>in Win32.
>>
>><http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp>
>><http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecoreos5/html/wce50lrfGetTickCount.asp>
>>
>>Doesn't look deprecated to me.
>
> See
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/windows_time.asp
Nothing there that implies deprecation, either.
"This format exists primarily for backward compatibility with 16-bit Windows."
does not imply that. An API that is really deprecated looks like this one:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/extract.asp>.
Furthermore, there's no obvious replacement for the functionality of
GetTickCount that is equally simple and portable to recent Windows platforms:
- GetTickCount64 is non-portable, and not yet a stable API.
- QueryPerformanceCounter (which does not necessarily query the CPU performance
counter; that depends on the Windows version and boot options) counts at a
frequency that is known only at run-time, not compile time. This makes it
unnecessarily complicated if all you want is a low-resolution duration in
milliseconds.
(If you want a high-resolution duration, there are several different problems
that can cause QueryPerformanceCounter to be broken for that:
<http://www.google.com/search?q=cache:www.veritest.com/bi/cont2000/200012/perfcnt.asp>
<http://channel9.msdn.com/ShowPost.aspx?PostID=156175>
<http://support.microsoft.com/?id=896256>
<http://support.microsoft.com/?id=895980>.)
- timeGetTime and timeGetSystemTime have the same resolution and range
limitations as GetTickCount, so there is no reason to use them in preference
to it.
- the rest of the multimedia timer API and the "hi-res" timer API provide
event timers, which require a callback and are inconvenient for measuring
duration.
- various other APIs return the wall clock *time*, which is very different
from the elapsed *duration* since the system started running. A time API
cannot correctly be used to measure duration, since it will be thrown off
by clock changes.
- clock() is misimplemented by the VC++ runtime: it should return a duration,
but it is affected by wall clock changes, unlike GetTickCount.
- POSIX with the 'Monotonic Clock' option provides suitable APIs, but they
are not implemented on Windows.
Many Win32 programs use GetTickCount correctly to measure durations, despite
its resolution and range limitations.
> GetTickCount has been entirely superceded by the SystemTime group of
> functions.
Those measure wall clock time, not duration.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
George Neuner
Jørgen Kruse) wrote:
>How well does these multimedia time functions work? I suppose they don't
>give wall clock time?
The multimedia functions give elapsed ms since boot.
George Neuner
<david.nosp...@blueyonder.co.uk> wrote:
None of the time functions measure duration ... they measure elapsed
time relative to some epoch. The major difference is that
SystemTime's epoch is a defined calendar date whereas GetTickCount and
timeGetTime use the last boot or counter rollover.
George
Jan Vorbrüggen
> or somesuch but only increments 10 ms at a time.
VMS legacy, I suppose. The unit of measure is 100 ns.
Jan
David Hopwood
> On Mon, 08 May 2006 00:45:50 GMT, David Hopwood
> <david.nosp...@blueyonder.co.uk> wrote:
>>George Neuner wrote:
>>
>>>GetTickCount has been entirely superceded by the SystemTime group of
>>>functions.
>>
>>Those measure wall clock time, not duration.
>
> None of the time functions measure duration ... they measure elapsed
> time relative to some epoch.
The difference of two times measured by a uniform monotonic clock is a
duration. The epoch in this case does not matter, as long as it is the
same for both measurements.
Wall clock APIs attempt to track an external time standard such as UTC,
*at the expense of* uniformity and monotonicity, and therefore at the
expense of accuracy in measuring duration.
> The major difference is that
> SystemTime's epoch is a defined calendar date whereas GetTickCount and
> timeGetTime use the last boot or counter rollover.
No, the major difference is that SystemTime can be changed at any point
by the user, or by an NTP client such as Windows Time Service. That makes
it unsuitable for measuring durations.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
Terje Mathisen
> George Neuner wrote:
>> The major difference is that
>> SystemTime's epoch is a defined calendar date whereas GetTickCount and
>> timeGetTime use the last boot or counter rollover.
>
> No, the major difference is that SystemTime can be changed at any point
> by the user, or by an NTP client such as Windows Time Service. That makes
> it unsuitable for measuring durations.
This is the main reason that the real/canonical NTP implementation tries
very hard to follow 'the principle of least astonishment' which in this
case means affecting the system clock frequency as little as possible,
so as to maintain timing consistency for those people who subtract two
system time values and expect to get the real time interval.
Running stock NTPD the maximum adjustment rate is +/- 500 ppm, which
means that this is also the maximum possible frequency offset.
In reality, a working NTPD deamon, with proper upstream reference
clocks, will almost always keep time offsets within a few milliseconds
or less, and frequency/phase adjustments will stay at the single-digit
ppm level.
There are two serious caveats to this however:
a) In case of a leap second, with an OS kernel that doesn't implement
this properly, there's no way to avoid a one-second glitch for an
interval timed in UTC which crosses the epoch.
b) If you have _very_ long poll intervals, manually fixed at too high a
level, and you suddenly expose the system to some kind of thermal shock,
the crystal frequency can change so much that the system clock will
drift outside the +/- 128 ms maximum adjustment interval. In that case
ntpd will fall back to directly setting the clock, throw away all
historic data and effectively reset itself. The same thing can more
easily happen when all your timing sources are on the other end of a
long-latency wire, which is periodically severely asymmetrically
overloaded. I.e. if the one-way transmission time is more than 256 ms
then you get the same results as from a real 128 ms offset.
David Hopwood
> David Hopwood wrote:
>> George Neuner wrote:
>>
>>> The major difference is that
>>> SystemTime's epoch is a defined calendar date whereas GetTickCount and
>>> timeGetTime use the last boot or counter rollover.
>>
>> No, the major difference is that SystemTime can be changed at any point
>> by the user, or by an NTP client such as Windows Time Service. That makes
>> it unsuitable for measuring durations.
>
> This is the main reason that the real/canonical NTP implementation tries
> very hard to follow 'the principle of least astonishment' which in this
> case means affecting the system clock frequency as little as possible,
> so as to maintain timing consistency for those people who subtract two
> system time values and expect to get the real time interval.
True, but Windows Time Service is not a "real" NTP implementation in this
sense.
# When the local clock offset has been determined, the following adjustments
# are made to the time:
#
# - If the local clock time of the client is behind the current time received
# from the server, Windows Time Service will change the local clock time
# immediately.
#
# - If the local clock time of the client is more than three minutes ahead
# of the time on the server, the service will change the local clock time
# immediately.
#
# - If the local clock time of the client is less than three minutes ahead
# of the time on the server, the service will quarter or halve the clock
# frequency for long enough to synchronize the clocks.
#
# - If the client is less than 15 seconds ahead, it will halve the frequency;
# otherwise, it will quarter the frequency. The amount of time the clock
# spends running at an unusual frequency depends on the size of the offset
# that is being corrected.
So that's an adjustment rate of +/- 500000 ppm in the best case. I hadn't
realised it was quite this bad, actually :-)
> Running stock NTPD the maximum adjustment rate is +/- 500 ppm, which
> means that this is also the maximum possible frequency offset.
>
> In reality, a working NTPD deamon, with proper upstream reference
> clocks, will almost always keep time offsets within a few milliseconds
> or less, and frequency/phase adjustments will stay at the single-digit
> ppm level.
The reality is that getting most Windows users -- or even atypically diligent
users -- to run a "working NTPD" is a non-starter.
> There are two serious caveats to this however:
>
> a) In case of a leap second, with an OS kernel that doesn't implement
> this properly, there's no way to avoid a one-second glitch for an
> interval timed in UTC which crosses the epoch. [...]
Yes, that's another reason why a UTC wall clock is fundamentally broken for
measuring duration. The problem here is that UTC isn't really a time measured
from an epoch; it is a discontinuous approximation of the *angle* through
which the earth has rotated since the epoch. This can't be compensated for
in any way that would make a simple subtraction of UTC values work. It's not
a matter of whether a kernel implements leap seconds properly.
--
David Hopwood <david.nosp...@blueyonder.co.uk>
Terje Mathisen
> Terje Mathisen wrote:
>> This is the main reason that the real/canonical NTP implementation tries
>> very hard to follow 'the principle of least astonishment' which in this
>> case means affecting the system clock frequency as little as possible,
>> so as to maintain timing consistency for those people who subtract two
>> system time values and expect to get the real time interval.
>
> True, but Windows Time Service is not a "real" NTP implementation in this
> sense.
Oh, I'm painfully aware of that. :-(
> # - If the local clock time of the client is behind the current time received
> # from the server, Windows Time Service will change the local clock time
> # immediately.
[snip]
> # - If the client is less than 15 seconds ahead, it will halve the frequency;
> # otherwise, it will quarter the frequency. The amount of time the clock
> # spends running at an unusual frequency depends on the size of the offset
> # that is being corrected.
>
> So that's an adjustment rate of +/- 500000 ppm in the best case. I hadn't
> realised it was quite this bad, actually :-)
Check again: It is infinity (a step function) for _any_ clock that is
behind, no matter how little! I.e. no attempt at all to adjust the
frequency.
For a fast clock, the adjustment rate is either 50% or 75% of the
nominal frequency, i.e. effectively another step function for anyone
trying to time anything.
>> In reality, a working NTPD deamon, with proper upstream reference
>> clocks, will almost always keep time offsets within a few milliseconds
>> or less, and frequency/phase adjustments will stay at the single-digit
>> ppm level.
>
> The reality is that getting most Windows users -- or even atypically diligent
> users -- to run a "working NTPD" is a non-starter.
Again, I'm painfully aware of it: Even inside the corporation I work
for, only the top-level Active Domain controllers run the NTPD binaries
(which I've maintained at my personal web site for a number of years),
all the rest (~1000 Win* servers) run the MS sawtooth code.
>> There are two serious caveats to this however:
>>
>> a) In case of a leap second, with an OS kernel that doesn't implement
>> this properly, there's no way to avoid a one-second glitch for an
>> interval timed in UTC which crosses the epoch. [...]
>
> Yes, that's another reason why a UTC wall clock is fundamentally broken for
> measuring duration. The problem here is that UTC isn't really a time measured
> from an epoch; it is a discontinuous approximation of the *angle* through
> which the earth has rotated since the epoch. This can't be compensated for
> in any way that would make a simple subtraction of UTC values work. It's not
> a matter of whether a kernel implements leap seconds properly.
A good kernel supports both UTC and TAI timestamps, along with
information about the offset between them. This does at least allow
diligent programmers to do the right thing. On an OS without such
support there's pretty much nothing you _can_ do.
Anyway, IMHO the real fallacy is the unix idea that calendar style
information can be handled with a single number: seconds_since_1970.
Intervals should use monotonically increasing seconds (i.e. TAI), while
calendar timestamps needs ISO: 2006-05-11 09:04:40 UTC