[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 18:31:28 UTC 2009


"Dave Hart" <davehart at gmail.com> wrote in message 
news:fef13ab0-a7ca-479b-9f8f-5281fdaf7fa0 at m7g2000prd.googlegroups.com...
> On Dec 11, 16:26 UTC, "David J Taylor" wrote:
>> 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'm curious about that difference too.  I can tell you that assuming
> all the systems are using the -M option (so that interpolation is
> disabled on all the Vista and Win7 systems) there is no difference in
> the timestamping code used in the RX and TX paths, nor any difference
> I can imagine in the network RX timestamp path with a network vs. PPS
> refclock time source.
>
> To answer a question that came up on hackers@, Windows does not offer
> SO_TIMESTAMP or similar functionality in any release.  ntpd uses its
> get_systime() routine in ntp_iocompletionport.c's OnSocketRecv(), the
> same routine used to fetch the TX timestamp.  With interpolation
> disabled, get_systime() simply calls GetSystemTimeAsFileTime() which
> reads the 64-bit system time from shared memory and converts it to NTP
> format.  My interpretation is the differences you're seeing are likely
> tied to the particular hardware and HAL being used.  I suspect if you
> shuffle which boxes have reference clocks, the system clock stepping
> back up to a millisecond issue will affect the same systems.
>
> Cheers,
> Dave Hart

Dave,

Thanks for your reply.  It's not convenient to shuffle boxes at the 
moment, unfortunately, but there is a different between Stamsund (P4 
2.8GHz HT, ASUS P4P800) and Gemini (AMD dual-core 64 X2 4400, ASUS A8N 
SLI).  I just checked, and both have the -M on the startup parameters in 
the Services manager.  Here's what I see from NTP on the two systems:

PC Gemini:
Level,Date and Time,Source,Event ID,Task Category
Information,11/12/2009 07:16:00,NTP,3,None,Listen normally on 7 IPv6 2 
fe80::44b7:ae39:8f1:1aef UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,Listen normally on 6 IPv6 1 
fe80::1d76:410f:c600:725 UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,Listen normally on 5 v6loop 0 
::1 UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,Listen normally on 4 IPv4 3 
192.168.0.5 UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,Listen normally on 3 IPv4 2 
192.168.238.238 UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,Listen normally on 2 v4loop 1 
127.0.0.1 UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,Listen and drop on 1 v6wildcard 
:: UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,Listen and drop on 0 v4wildcard 
0.0.0.0 UDP 123
Information,11/12/2009 07:16:00,NTP,3,None,proto: precision = 976.500 usec
Information,11/12/2009 07:16:00,NTP,3,None,using Windows clock directly
Information,11/12/2009 07:16:00,NTP,3,None,"Windows clock precision 0.977 
msec, min. slew 6.400 ppm/s   "
Information,11/12/2009 07:16:00,NTP,3,None,Clock interrupt period 15.625 
msec
Information,11/12/2009 07:16:00,NTP,3,None,Performance counter frequency 
3.580 MHz
Information,11/12/2009 07:16:00,NTP,3,None,"MM timer resolution: 
1..1000000 msec, set to 1 msec   "
Information,11/12/2009 07:16:00,NTP,3,None,Raised to realtime priority 
class
Information,11/12/2009 07:16:00,NTP,3,None,ntpd 4.2.6-o Dec 09 11:48:30.27 
(UTC-00:00) 2009  (1)


PC Stamsund:
Level,Date and Time,Source,Event ID,Task Category
Warning,09/12/2009 20:32:31,NTP,2,None,"clock would have gone backward 3 
times, max 97.5 usec "
Information,09/12/2009 14:14:36,NTP,3,None,Using user-mode PPS timestamp 
for GPS_NMEA(1)
Information,09/12/2009 14:14:35,NTP,3,None,GPS_NMEA(1) serial /dev/gps1 
open at 4800 bps
Information,09/12/2009 14:14:35,NTP,3,None,Listen normally on 6 IPv6 1 
fe80::5dbb:3fda:3db5:b6be UDP 123
Information,09/12/2009 14:14:35,NTP,3,None,Listen normally on 5 v6loop 0 
::1 UDP 123
Information,09/12/2009 14:14:35,NTP,3,None,Listen normally on 4 IPv4 3 
192.168.238.238 UDP 123
Information,09/12/2009 14:14:35,NTP,3,None,Listen normally on 3 IPv4 2 
192.168.0.7 UDP 123
Information,09/12/2009 14:14:35,NTP,3,None,Listen normally on 2 v4loop 1 
127.0.0.1 UDP 123
Information,09/12/2009 14:14:35,NTP,3,None,Listen and drop on 1 v6wildcard 
:: UDP 123
Information,09/12/2009 14:14:34,NTP,3,None,Listen and drop on 0 v4wildcard 
0.0.0.0 UDP 123
Information,09/12/2009 14:14:34,NTP,3,None,proto: precision = 1.700 usec
Information,09/12/2009 14:14:32,NTP,3,None,HZ 64.000 using 43 msec timer 
23.256 Hz 64 deep
Information,09/12/2009 14:14:32,NTP,3,None,"Windows clock precision 0.977 
msec, min. slew 6.400 ppm/s   "
Information,09/12/2009 14:14:32,NTP,3,None,Clock interrupt period 15.625 
msec (startup slew 0.1 usec/period)
Information,09/12/2009 14:14:32,NTP,3,None,Performance counter frequency 
3.580 MHz
Information,09/12/2009 14:14:32,NTP,3,None,"MM timer resolution: 
1..1000000 msec, set to 1 msec   "
Information,09/12/2009 14:14:32,NTP,3,None,Raised to realtime priority 
class
Information,09/12/2009 14:14:32,NTP,3,None,ntpd 4.2.6-o Dec 09 11:48:30.27 
(UTC-00:00) 2009  (1)


I note that the line:  "using Windows clock directly"  appears in Gemini 
and not Stamsund, and that "HZ 64.000 using 43 msec timer 23.256 Hz 64 
deep" appears in Stamsund and not Gemini.  Stamsund also has 
"NTP_USER_INTERP_DANGEROUS=1" which must have been a hangover from our 
earlier experiments.

Perhaps this means I'm running Stamsund in a non-standard mode, without 
having remembered I was, and what is the significance that it appears to 
work well as a reference server (although nothing like as well as on 
Windows XP)?

Cheers,
David 




More information about the questions mailing list