Dennis Ferguson wrote:
On 15 Feb, 2012, at 22:53 , Terje Mathisen wrote:
I do like your approach. :-)
Thanks. This was arrived at when I acquired hardware which allowed the
system clock to be measured against an external reference with an
accuracy in the very low 10's of nanoseconds and found the clocks in
the kernels I had were jittering by many 100's of nanoseconds all by
themselves.
You might be interested to know that around 1994 or so, while visiting
friends at Novell, in Provo Utah, I fixed a bug in their (net yet
released at the time) new NetWare version, in the low-level
high-precision timing code (used among many other things to throttle
network transmission rates to exactly what the connection would handle).
While running on a (brand new at the time) Pentium, the code naturally
used the RDTSC instruction, which they then scaled to give the same ~us
resolution ticks as the original 386/486 code.
They had a DIV in the broken code, where if the server ran for a long
enough period, on a fast enough PC, the division could overflow.
My replacement code, which was maybe 20-30 lines total (including the
setup code) of asm, took the raw count, multiplied by a reciprocal and
did a double-wide shift of the result.
What does this remind you of?
:-)
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
