[ntp:questions] Packet timestamps when using Windows-7/Vista

David J Taylor david-taylor at blueyonder.delete-this-bit.and-this-part.co.uk.invalid
Fri Dec 11 16:26:29 UTC 2009

"Martin Burnicki" <martin.burnicki at meinberg.de> wrote in message 
news:s9u9v6-gj3.ln1 at gateway.py.meinberg.de...
> David,
> David J Taylor wrote:
>> Folks,
>> [Posted to NTP Hackers, but no reaction there as yet]
>> I've written a small program which sends some SNTP packets to various 
>> NTP
>> servers on my LAN, and looks at the timestamps which the server adds as
>> its RX and TX times.  With Windows-7 and Vista I'm seeing some odd
>> results.  I'm measuring (server TX) - (server RX) time.
>> 1 - Bacchus - Windows 2000 Server - GPS/PPS ref. clock - older 
>> computer -
>> 550MHz Pentium III.  Most values around 70 us (microseconds) with a 
>> tail
>> up to about 120us.
> This looks like the clock interpolation works pretty good here. 70us 
> sound
> like the "normal" execution time to handle the packet, which may be
> extended to e.g 120 us (or even more) if e.g. an IRQ occurs during the
> processing.
>> 2 - Feenix - Windows XP Home - GPS/PPS ref. clock - 1.9GHz single core
>> Pentium 4.  Most values around 20-40us, tail to 100us.  Occasional 
>> values
>> out to 1000us or more.
>> 3 - Narvik - Windows XP Pro - LAN-synced - ~2.2GHz dual-core PC.  Most
>> values 6 - 11us.  Occasionally more.
> Similar as above. Please keep in mind timestamping is in user space 
> here, so
> there may not only be IRQs but also task switches etc. which expand the
> time between packet reception and transmission of a reply.
>> 4 - Gemini - Windows Vista - LAN synced - ~2.2GHz dual-core PC.  A
>> distribution ranging from about -1000us to +1000us, possibly triangular
>> (I'm looking on a log Y-axis).
>> 5 - Puffin - Windows Vista - wifi-LAN-synced - ~2+ GHz dual-core PC.
>> Similar results to Gemini.
>> 6 - Stamsund - Windows 7 - GPS/PPS ref. clock - 2.8GHz single core HT
>> Pentium 4.  Most results in the range 17-25us, but with some extremes.
>> 7 - Hydra - Windows 7 - LAN synced - single-core AMD 3200+. Similar
>> distribution to Gemini.
> For Gemini, Puffin, and Hydra:
> If you are running one of Dave Hart's 4.2.5 or 4.2.6 binaries then the 
> clock
> interpolation may be disabled, and the system time increases in 1 ms 
> steps.
> On the other hand, I've also seen systems where the interpolated time 
> steps
> back and forth by 1 ms, due to the time passed by Windows to the timer 
> callback steppingby 1 ms. I have *observed* this on XP, but I can 
> imagine
> this also happens on newer systems.
> Please note:
> Even if under Vista/Windows 7 the system time increments in 1 ms steps, 
> the
> nominal standard tick count is still ~15600 (15601 on a Vista machine
> here), i.e ~15.6 ms. Since this is not an integral multiple of 1 ms 
> there
> must be some math which converts from 1 ms steps to 15.6 ms steps, and 
> that
> math may suffer from rounding errors.
> AFAICS this is still the basic problem as under XP or earlier, when the 
> MM
> timer has been set: The MM timer ticks at 1 ms, but the system time 
> ticks
> at 15.625 ms, and there also needs to be a conversion from one tick rate 
> to
> the other.
> The difference in Vista/7 vs. 2000/XP seems to be that
> GetSystemTimeAsFiletime returns values from the 1 ms "tick domain" for 
> the
> newer systems whereas it returns values from the 15 ms "tick domain" on
> older systems.
>> So there are two things about these results which concern me:
>> A - if my program is correct, it seems that the timestamps on the
>> Windows-7/Vista systems are being set inconsistently, in that the 
>> server
>> transmit timestamp can be /before/ the receive timestamp!  From the
>> distribution it seems that one timestamp is "precise" and the other a
>> Windows value based on a one millisecond (approx) timer.
> As I tried to explain above, this looks to me like a +/- 1 LSB (i.e. 
> 1ms)
> problem. IIRC then Dave Hart has implemented some code in the clock
> interpolation routine which shall reduce the potential +/- 1 ms jitter 
> in
> general. However, I'm not sure whether this routine is in effect if 
> clock
> interpolation is disabled, eg. on Vista/7.
>> B - Why does the Windows-7 system with a GPS/PPS reference clock not
>> behave in the same way i.e. it doesn't give negative (TX-RX) times?
> Concerning the 1ms-to-15.6ms conversion mentioned above:
> A *possible* reason I can imagine is that this depends on whether the 
> clock
> runs too fast or too slow at its nominal tick rate (i.e. the on-board 
> xtal
> is below or above its nominal frequency). In one case the frequency 
> drift
> compensation has to *add* an offset to the standard tick rate, in the 
> other
> case an offset needs to be subtracted. Depending on the way how the
> conversion has been implemented in the Windows kernel, a positive offset
> may lead to rounding errors whereas a negative one may not, or 
> vice-versa.
> All the above are only assumptions.
>> What I don't know is whether these results are to be expected, whether
>> they may have any effect on the operation of NTP, and whether they 
>> might
>> even be the results of coding errors.  I'm wondering whether this
>> indicates that something could be done to improve NTP on 
>> Windows-7/Vista,
>> and whether it might even provide a further clue as to why 4.2.5 
>> performs
>> worse on Windows-7/Vista than on 2000/XP.
> IMO it will be very hard to improve things for NTP if you do not know 
> the
> exact details why this happens. The proper solution would be if the MS
> developers cared about the clock interpolation, and made the Windows 
> system
> time available at a higher resolution, especially since the available 
> calls already support higher resolution.
> Those guys know how the Windows timekeeping has been coded, they know 
> when
> CPU clock rates are switche to save power, etc., and they could handle 
> this
> in kernel space. So timekeeping apps like NTP would not need to care 
> about
> limitations of the underlying OS.
> Martin


[I would normally trimmed the material above, but left it this time]

Thank you very much for your detailed and considered reply.  With the 
Windows-2000 and Windows-XP systems I am happy with the performance.  I 
was able to add the kernel-mode PPS serial routine to all the GPS/PPS 
systems, which does reduce the jitter reported by NTP slightly.  As you 
say, though, this doesn't help the precision in timestamping the NTP 
network packets.

Yes, I am running Dave Hart's binaries with the interpolation disabled and 
the  high-resolution timer enabled, so it just relies on the ~1KHz clock. 
You make an interesting point about keeping the 1ms and 15.6ms timers in 
step - that had not occurred to me before!  It would be helpful to hear 
from Dave Hart how the two packet timestamps are derived, when 
interpolation is disabled.  I've made more measurements and it looks at if 
both the server-RX and the server-TX times have a 1ms jitter of an 
approximately uniform peak-to-peak value, and that when subtracted the 
difference has a triangular distribution centred on zero, and with a -1ms 
to +1ms range.

The Windows-7 with the reference clock interests me - it's as if the 
packet timestamps are being derived in a completely different way than on 
the LAN-synced system.  I struggle to read the source code in C, so 
perhaps someone who is more familiar could confirm that.

I note your comments on Windows and agree that a lot could be done if more 
information and better implementation of existing APIs were available, but 
I'm still left with the question - why does NTP 4.2.5 perform less well 
that 4.2.4 on Window-7, and what does the Windows-7 GPS/PPS system not 
show the same 2ms peak-to-peak jitter?

I'm quite happy to work with someone offline on this, and my test program 
is available.


More information about the questions mailing list