[ntp:questions] Detecting bufferbloat via ntp?

unruh unruh at wormhole.physics.ubc.ca
Tue Feb 8 21:43:17 UTC 2011


On 2011-02-08, Chuck Swiger <cswiger at mac.com> wrote:
> On Feb 8, 2011, at 12:05 PM, Richard B. Gilbert wrote:
>>>> What would wild swings in latency on the order of seconds from a ntp client register on a ntp server as?
>>> 
>>> High latency ("delay" column in "ntpq -p" output), high jitter.
>>> 
>>> Regards,
>> 
>> Why would the server even notice what the client is doing?  The server does not monitor clients, it simply responds with the correct time whenever it is asked for the correct time.
>> 
>> Now ntpq -p on the *client* would show "High latency", etc.
>
> I agree that "ntpq -p" on the client should show this; that was what I'd meant to suggest.  :-)
>
> This being said, a NTP client does indeed provide it's time to the server when making an NTP request, in a field called the "Transmit Timestamp".  A typical NTP exchange looks like the following:

Yes, but all the server does is to copy that  timestamp into the
outgoing packet, puts its received timestamp into the
appropriate box and when it is ready to send the packet pack, put in its
own transmit timestamp
Ie, it does not care or even read that incoming timestamp. It just
copies it to the new transmitted packet and puts in its own timestamps
(after checking to see if this client location has been sending too many
requests, or needs authentication or whatever.)


>
> # tcpdump -n -s 0 -v -v port ntp
> tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 12:19:18.509538 IP (tos 0x0, ttl 64, id 36710, offset 0, flags [none], proto UDP (17), length 76)
>     17.209.4.71.59710 > 17.254.0.28.123: NTPv4, length 48
> 	Client, Leap indicator: clock unsynchronized (192), Stratum 0, poll 4s, precision -6
> 	Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
> 	  Reference Timestamp:  0.000000000
> 	  Originator Timestamp: 0.000000000
> 	  Receive Timestamp:    0.000000000
> 	  Transmit Timestamp:   3506185158.509455978 (2011/02/08 12:19:18)
> 	    Originator - Receive Timestamp:  0.000000000
> 	    Originator - Transmit Timestamp: 3506185158.509455978 (2011/02/08 12:19:18)
>
> 12:19:18.512758 IP (tos 0x0, ttl 54, id 20819, offset 0, flags [none], proto UDP (17), length 76)
>     17.254.0.28.123 > 17.209.4.71.59710: NTPv4, length 48
> 	Server, Leap indicator:  (0), Stratum 2, poll 4s, precision -18
> 	Root Delay: 0.155578, Root dispersion: 0.010467, Reference-ID: 17.72.133.55
> 	  Reference Timestamp:  3506185149.914425015 (2011/02/08 12:19:09)
> 	  Originator Timestamp: 3506185158.509455978 (2011/02/08 12:19:18)
> 	  Receive Timestamp:    3506185158.512185990 (2011/02/08 12:19:18)
> 	  Transmit Timestamp:   3506185158.512228012 (2011/02/08 12:19:18)
> 	    Originator - Receive Timestamp:  +0.002730000
> 	    Originator - Transmit Timestamp: +0.002772000
>
> [ The server would see higher latency and variable jitter in these timestamps, although the server probably doesn't care about them, unless that client also happens to be configured as a peer of the server.... ]
>
It will not care. And if that client is also a peer, you have a timing
loop which is detected since then that peer will have too high a
stratum.
And anyway, when it responds to a request, it does not care. It just
responds (unless it decides a Kiss of Death if more appropriate)


> Regards,




More information about the questions mailing list