|
|
|
|
|
|
| Author |
Message |
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
 Posted: Mon Apr 15, 2002 3:14 pm Post subject:
get{bin,micro,nano}[up]time() - what precision ?
|
|
|
I'm soliciting input from users of the get*time() family of functions
in the kernel on what the minimal desirable precision is.
Currently they return a timestamp which is no more than 1/HZ out
of date. For contemporary values of HZ, that seems to be adequate.
As people increase HZ to above 10000, it starts to cost more to
update timecounters every tick, and the question naturally arises:
what is the target resolution for get*time() functions ?
Would anybody get in trouble if the precision never got better
than 10msec, even for higher HZ ?
If so, would 1msec be an acceptable limit ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Thierry Herbelot
*nix forums beginner
Joined: 15 Apr 2002
Posts: 19
|
| Posted: Mon Apr 15, 2002 3:46 pm Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
Poul-Henning Kamp wrote:
| Quote: |
I'm soliciting input from users of the get*time() family of functions
in the kernel on what the minimal desirable precision is.
Currently they return a timestamp which is no more than 1/HZ out
of date. For contemporary values of HZ, that seems to be adequate.
As people increase HZ to above 10000, it starts to cost more to
update timecounters every tick, and the question naturally arises:
what is the target resolution for get*time() functions ?
Would anybody get in trouble if the precision never got better
than 10msec, even for higher HZ ?
If so, would 1msec be an acceptable limit ?
|
Hello,
I am investigating a "centralized clock" appliance, where a number of
FreeBSD PCs would spit out a more or less precise date on the Ethernet.
The goal would be : all FreeBSD PCs will run NTP, with a local GPS
clock, and will peer with the other PCs in order to be hardened against
the loss of a GPS box.
The FreeBSD PCs only run some kind of endless loop, copying the local,
"precise relative to UTC" time on Ethernet packets, sent approximatively
once every msec.
Thus, I would like to be able to read the local time at 2000Hz to (max)
5000Hz, with the correlative precision. Thus, 1msec seems to be a little
short on precision.
Cheers
TfH
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Mon Apr 15, 2002 3:53 pm Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
In message <3CBB11F8.451D28AB@herbelot.com>, Thierry Herbelot writes:
| Quote: | Thus, I would like to be able to read the local time at 2000Hz to (max)
5000Hz, with the correlative precision. Thus, 1msec seems to be a little
short on precision.
|
You will still have the full precision functions {bin,nano,micro}[up]time(),
but they are a tad slower to access.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Thierry Herbelot
*nix forums beginner
Joined: 15 Apr 2002
Posts: 19
|
| Posted: Mon Apr 15, 2002 4:20 pm Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
Poul-Henning Kamp wrote:
| Quote: |
You will still have the full precision functions {bin,nano,micro}[up]time(),
but they are a tad slower to access.
fine, thanks |
TfH
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Mon Apr 15, 2002 9:29 pm Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
Poul-Henning Kamp wrote:
| Quote: | I'm soliciting input from users of the get*time() family of functions
in the kernel on what the minimal desirable precision is.
Currently they return a timestamp which is no more than 1/HZ out
of date. For contemporary values of HZ, that seems to be adequate.
As people increase HZ to above 10000, it starts to cost more to
update timecounters every tick, and the question naturally arises:
what is the target resolution for get*time() functions ?
Would anybody get in trouble if the precision never got better
than 10msec, even for higher HZ ?
If so, would 1msec be an acceptable limit ?
|
SPARC had a 4uS resolution in ~1990; it did this by having a
hardware clock of very high resolution, and a low update
frequency, from which a delta was maintained in software,
rather than by having an update requirement for a full
timecounter like structure.
I used this for a 100uS select(2) timeout for pacing in a game,
at one point in time.
It's probably worth considering Sun's SunOS 4.1.3 approach for
FreeBSD.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Tue Apr 16, 2002 3:13 am Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
In message <3CBB6252.6BAA4E90@mindspring.com>, Terry Lambert writes:
| Quote: | SPARC had a 4uS resolution in ~1990; it did this by having a
hardware clock of very high resolution, and a low update
frequency, from which a delta was maintained in software,
rather than by having an update requirement for a full
timecounter like structure.
|
As usual: Please don't pay attention to Terry, he is talking
without checking his facts and appearantly doesn't even know
that FreeBSD is way ahead of the pack when it comes to time
keeping code.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed Apr 17, 2002 5:18 am Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
Poul-Henning Kamp wrote:
| Quote: | In message <3CBB6252.6BAA4E90@mindspring.com>, Terry Lambert writes:
SPARC had a 4uS resolution in ~1990; it did this by having a
hardware clock of very high resolution, and a low update
frequency, from which a delta was maintained in software,
rather than by having an update requirement for a full
timecounter like structure.
As usual: Please don't pay attention to Terry, he is talking
without checking his facts and appearantly doesn't even know
that FreeBSD is way ahead of the pack when it comes to time
keeping code.
|
I dislike increased imprecision.
I understand wanting to limit the timecounter update frequency
to some upper bound, regardless of the actual hardware clock
frequency, since it would mean that the overhead would increase
linearly with the hardware clock frequency.
Getting the current time is a procedural operation, and so it
need not depend on a hardware interrupt operation, if a certain
resolution is required.
This leaves work which has to occur at the hard timer interrupt
frequency.
There's really no reason to lose clock granularity merely because
the timecounter state structure update frequency is lower than
the desired granularity.
Let me reemphasize that I do not think that 1uS accuracy for
clock granularity is unreasonable 100uS to 60uS were required
for smooth game flow in code I wrote, where the active number
of computer opponents at any given time was permitted to vary.
For statistical kernel profiling on multi-gigahertz processors,
where, when the timer interrupt fires, you record the timer
firing interval has being completely within the arc specified
by the symbol less than or equal to the current program counter,
I think that it's impossible to get accurate results without a
hardware clock interrupt frequency that is sufficiently close
to the real CPU clock frequency (e.g. in the range of 128
instructions is near the limit, I think, for small functions,
though for most profiling it's probably overkill).
Also let me point out again, that SunOS 4.1.3 decoupled the clock
granularity from the hardware interrupt granularity, using a soft
timer.
Now this won't work with high resolution timers, such as those
used with the SVR4 HRT facility (SVID III(RT)), or select(2)
timeouts (per my application from my previous posting).
If you are going to decouple the hardware clock interrupt
frequency from the timer granularity, without losing timer
granularity (timer firings *must* be coupled to events),
then you have to deal with the fact that the current FreeBSD
implementation of timecounter state update doesn't scale very
well as the frequency goes up, or the hardware clock frequency
nears the CPU frequency.
I understood that this was the motivation for your posting, in
the first place, though I do not understand the need to scale
the number of timecounter state buckets above two or three
instances (the current tuning on this to avoid console messages
seems excessive, to me).
By adopting the SunOS approach, clamping the timecounter state
update frequency to some divisor of the hardware clock interrupt
frequency *would not necessarily mean losing clock resolution*,
which you suggested might be an acceptable outcome of the clamping.
It is at least (1) statistically more accurate than a direct
reference to a timecounter which is guaranteed to be updated,
and (2) it is monotonically increasing, so there is an *average*
of a higher resolution. In fact, the TSC timecounter code uses
an apprach very similar to this already, and substitutes reading
the current cycle counter for a weighted average based calculation
derived from the number of times the time was the same in the
last set of interrupts.
So what does this leave us? It leaves us with timer problems
for timeouts, etc., which will also lose resolution. If they
don't lose resolution... well, the traversal of the timer
lists, which are arbitrarily long, is non-deterministic, and
will most likely take much more time than simply updating the
timecounter state -- an update whose slope is at least linear
and deterministic.
How do we avoid losing timer resolution at the same time, then?
I would suggest that we learn from Mohit Aron and Peter Druschel
of Rice University (I've suggested this before), and implement
Soft Timers:
http://citeseer.nj.nec.com/aron99soft.html
Note that these are only part of a whole solution.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Wed Apr 17, 2002 8:35 am Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
In message <3CBD21B1.2767EE59@mindspring.com>, Terry Lambert writes:
| Quote: | Poul-Henning Kamp wrote:
As usual: Please don't pay attention to Terry, he is talking
without checking his facts and appearantly doesn't even know
that FreeBSD is way ahead of the pack when it comes to time
keeping code.
I dislike increased imprecision.
I understand wanting to limit the timecounter update frequency
to some upper bound,
|
I hope everybody else who knows our kernel is having as good a
laugh as I am about Terry ?
Terry: Here is a clue for you: You manage to not even get close
to the topic at hand in your email. And no, I am not going to
explain it to you.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
John Hay
*nix forums beginner
Joined: 17 Apr 2002
Posts: 8
|
| Posted: Wed Apr 17, 2002 10:46 am Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
| Quote: | Poul-Henning Kamp wrote:
In message <3CBB6252.6BAA4E90@mindspring.com>, Terry Lambert writes:
SPARC had a 4uS resolution in ~1990; it did this by having a
hardware clock of very high resolution, and a low update
frequency, from which a delta was maintained in software,
rather than by having an update requirement for a full
timecounter like structure.
As usual: Please don't pay attention to Terry, he is talking
without checking his facts and appearantly doesn't even know
that FreeBSD is way ahead of the pack when it comes to time
keeping code.
I dislike increased imprecision.
.... |
Uhm Terry, aren't you mixing up get{bin,micro,nano}[up]time() with
{micro,nano}[up]time()? The last set gives you up to the machine's
capability precision. That can be 1ns or better depending on the
machine. Both sets are available for use in the kernel
John
--
John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Thu Apr 18, 2002 11:26 am Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
John Hay wrote:
| Quote: | Uhm Terry, aren't you mixing up get{bin,micro,nano}[up]time() with
{micro,nano}[up]time()? The last set gives you up to the machine's
capability precision. That can be 1ns or better depending on the
machine. Both sets are available for use in the kernel
|
Not really. The time resolution in the kernel is not really
relevent for the number one use in user space, which is logging.
I built a "zero system call" gettimeofday(2) and time(3) using
double mapped pages for the timecounter state for the 8254 and
the Pentium TSC, based on Poul's code.
Limiting the resolution on these limits the accounting granularity
to approximately one quantum, even when the operations per request
can be handled in significantly less than one quantum.
If you look at the TSC code, using the data from the last interrupt,
and using the timecounter "calibration" data, along with a current
reading of the cycle counter, the reading of the current cycle counter
is functionally equivalent to the SunOS 4.1.3 approach, except that
it has a real value, instead of a statistical value, to do the job.
Personally, I'm more concerned with the clamping as it relates to
things requiring timestamps in the kernel -- not intervals. The
proposed changes seem (to me) to be damaging to profiling.
The original complaint by Poul was:
] I'm soliciting input from users of the get*time() family of functions
] in the kernel on what the minimal desirable precision is.
]
] Currently they return a timestamp which is no more than 1/HZ out
] of date. For contemporary values of HZ, that seems to be adequate.
]
] As people increase HZ to above 10000, it starts to cost more to
] update timecounters every tick, and the question naturally arises:
] what is the target resolution for get*time() functions ?
This was not the question which naturally arose, for me. The
question which arose for me was "Why the limear relationship
between timecounter update frequency, cost, and resloution?".
I'm not complaining about the work Poul has done on the time
counter code in FreeBSD; if he hadn't perservered, we would
all still be seeing "timecounter moved backwards" console
messages. I'm sure we would all buy him a beer for fixing
that problem ( ). But I do question the assumption of a
linear relationship being impossible to overcome by any means
other than a decreased update resolution.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Thu Apr 18, 2002 11:36 am Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
You are so cute when you back-paddle Terry :-)
This is _still_ not what we are talking about.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Thu Apr 18, 2002 1:44 pm Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
Poul-Henning Kamp wrote:
| Quote: | You are so cute when you back-paddle Terry 
|
I'm not back-peddling; if you had not ripped out two of my
paragraphs in your initial "jump-in-Terry's-face", that
would be obvious to everyone.
| Quote: | This is _still_ not what we are talking about.
|
So instead of trying to be Mr. Myserioso, why don't you
say what you are talking about in plain English.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Thu Apr 18, 2002 1:46 pm Post subject:
Re: get{bin,micro,nano}[up]time() - what precision ?
|
|
|
In message <3CBEE9EF.80400659@mindspring.com>, Terry Lambert writes:
| Quote: | Poul-Henning Kamp wrote:
This is _still_ not what we are talking about.
So instead of trying to be Mr. Myserioso, why don't you
say what you are talking about in plain English.
|
Go back and read my initial email :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sat Jan 10, 2009 2:43 am | All times are GMT
|
|
Anime | Mortgage | Loans | Loans | Hotels in Rome
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
