[ntp:questions] Multiple Offset Values

Daniel Cordes daniel.cordes at pipelinefinancial.com
Mon Jul 16 18:38:43 UTC 2007


To Whom It May Concern:

My company is using Redhat 3/4 Linux servers that sync using NTP to
local switches as NTP peers, the switches themselves sync to pairs of
NIST servers.  These servers receive data over the course of the
workday, and as the day progresses they see increasing latency on the
incoming data in the range of +40-100ms, usually.  The data provider
claims the problem is that NTP gets increasingly off, thus the latency;
we suspect the problem is with latency in the actual data from the
provider.

I am new to NTP and am trying to decide which of these possibilities is
the case.  I have begun to log a large number of NTP state values on our
servers, and am trying to assess what they tell me.  I have looked at a
lot of documentation, but still have some questions.

1) First, I can see three different offset values in these three
commands.  Which would tell me the most helpful information in terms of
whether NTP is becoming increasingly out of sync during the day?
	a) ntpdc -c loopinfo
	b) ntpq -p (the offset value on the sys.peer line)
	c) ntpdate -q localhost

2) Here some of the values I have been logging on one of these servers
with the problem (from 6:00 AM to about 2:20 PM).  Does anything stand
out?  For each of these values I give the mean/average, following by the
standard deviation:
	a) localhost offset (ntpdc -c loopinfo): 0.0050s, 0.0078s
	b) localhost frequency (ntpdc -c loopinfo): 178.9794 PPM, .2007
PPM
	c) localhost jitter (ntpq -c rl): 0.0158s, 0.0107s
	d) localhost stability (ntpq -c rl): 26.5930, 21.3560 (seems
highly variable; but I don't know what this refers to)
	e) sys.peer delay (ntpq -p): 0.0024s, 0.0024s
	f) sys.peer offset (ntpq -p): 0.0081s, 0.0109s
	g) sys.peer jitter (ntpq -p): 0.1218s, 0.0000s

Does anything stand out?  Thanks!

- dp


Disclaimer: Any references to Pipeline performance contained herein are based on historic performance levels which Pipeline expects to maintain or exceed but nevertheless does not guarantee. Congested networks, price volatility, or other extraordinary events may impede future trading activities and degrade performance statistics.



More information about the questions mailing list