[ntp:questions] frequency adjusting only
GDowd at symmetricom.com
Wed Apr 30 21:49:49 UTC 2008
I'll stop top posting as the thread is getting long. Can you tell I'm
sitting in a conference and my attention is wandering :-)
gdowd at symmetricom dot com (antispam format)
"Everything should be made as simple as possible, but no simpler" Albert
> -----Original Message-----
> From: Bill Unruh [mailto:unruh at physics.ubc.ca]
> Sent: Wednesday, April 30, 2008 5:18 PM
> To: Greg Dowd
> Cc: questions at lists.ntp.org
> Subject: RE: [ntp:questions] frequency adjusting only
> On Wed, 30 Apr 2008, Greg Dowd wrote:
> > PTP default profile operation is 1 way sync transmissions from the
> > grandmaster to all slaves (via multicast) with an implicit
> > delay request/response for ranging from each slave. The
> work we are
> > doing in the telecom space (through ITU and IETF) defines a new
> > application profile for PTP which is unicast based and has a 1:1
> > correspondence between sync and delay request/response. It also
> > allows higher sync and delay request rates.
> > So, while NTP and PTP essentially have a like set of timestamps and
> > fundamental assumptions, I wouldn't say they do the same
> thing. The
> > small LAN is where PTP default profile is optimized for operation.
> > While everything from a single LAN segment to the big, hairy, scary
> > Internet is the target for NTP (along with lousy oscillators).
> > On a small LAN, with light traffic, it is likely all moot.
> > I'm not sure we agree on the effectiveness of the clock
> servo in ntp.
> We probably do.
> > First, there is no protocol requirement to only use 8 taps,
> it could
> > be
> It is not 8 taps. The clock filter is a "smallest delay
> amongst the last 8 samples" filter, whic throws away about
> 85% of the samples, which I find a profligate use of data.
I think this is intentional. The selection algorithm is designed to
find those packets experiencing the least delay in the network. If you
find that an entry is lower than the others, the others have experienced
greater delay and are assumed to be less accurate. Why include them?
Having said that, it runs on every update and could use all the packets
as long as the lowest delay is the oldest at each pass.
> > changed. I've checked :-) IIRC, there are 20 taps in the ACTS
> > reference clock driver. However, since the network client
> filter is 8
> > entries deep, and the poll interval can climb to 1024 seconds, I
> > wonder if you feel like the frequency stability of a pc is
> useful out
> > at observation intervals in the 10k seconds range? My
> guess would be
> > that
> I agree. This is what makes ntp so bad on most computers (ie
> much worse response than optimal given the data collected)
> and so slow to respond to changes.
> > environmentals would stomp on those samples. Also, wander can be
> > introduced by the LRD characteristics of network traffic.
A self-similar phenomenon behaves the same when viewed at different
degrees of magnification, or different scales on a dimension (space or
time). Self-similar processes can be described using heavy-tailed
distributions, also known as long-tailed distributions. Example of such
processes include traffic processes such as packet inter-arrival times
and burst lengths. Self-similar processes are said to exhibit long-range
dependency. (from Wikipedia)
> > However, moving closer in, I still think the higher update rate has
> > value. If you start using higher quality oscillators and hardware
> > timestamping, the dominant noise source becomes the delay
> variation in
> > the network. Since the remote clock can't average this (it's not
> > uniform or Gaussian), it needs to use some intelligent filtering.
> > Higher packet rates mean that there are more samples to pick from.
> Sure, but one of the goals of ntp is to minimize the impact
> on the servers.
> > Also, one thing a lot of these discussions miss is the natural
> > tradeoff between trying to be the most accurate vs trying
> to be the most stable.
> Of course. If you average over a month, you will be very
> stable. But probably very inaccurate. If you try to respond
> to each and every fluctuation, the opposite will occur.
> Somewhere in there is the optimum, and that optimum depends
> on the exact character of the noise, both phase and
> frequency. NTPs assumption that there is an alan optimum
> point, fixed for all situations is a poor approximation, both
> because that point varies greatly with the exact network
> connectivity and the frequency fluctuations are not 1/f
> noise, but dominantly environmental, which has strong periods
> ( day night).
But you won't be stable, right? While you were averaging, your
oscillator headed for the hills. The crossover point for your pc
oscillator is likely between 100-1000s.
> > These tradeoffs, as well as differences in noise processes,
> mean there
> > is no one "correct" servo. Having spent some time
> studying networks
> > with multiple network load generators connected through and across
> > network where sync is transferred (mostly for wireless
> backhaul), I've
> > developed a healthy respect for many of the various sampling and
> > filtering functions in ntp.
> > Greg Dowd
> > gdowd at symmetricom dot com (antispam format) Symmetricom, Inc.
> > www.symmetricom.com
> > "Everything should be made as simple as possible, but no simpler"
> > Albert Einstein
> And I think ntp is too simple.
That's hilarious. I usually argue that it is too complex.
> > -----Original Message-----
> > From: Bill Unruh [mailto:unruh at physics.ubc.ca]
> > Sent: Wednesday, April 30, 2008 3:21 PM
> > To: Greg Dowd
> > Cc: questions at lists.ntp.org
> > Subject: RE: [ntp:questions] frequency adjusting only
> > On Wed, 30 Apr 2008, Greg Dowd wrote:
> >> As noted, these are really stability measurements of the difference
> >> between two clocks. The absolute accuracies, particularly once you
> >> reach the submillisecond domain, are impacted by the sum
> of all biases
> >> in the measurement system, os, stack, driver, dma controller, bus,
> >> mac, phy, physical layer, switching/routing matrix and protocols
> >> (ARP/STP/QoS) and phy,mac,bus,driver,stack,os,app on the other end.
> >> Not just jitter and delay variation, but biases. Sometimes
> the biases
> >> are complentary and cancel and sometimes they don't.
> > Agreed. However, ntp and PTP is software do almost the same thing
> > (unless ptp really uses broadcast in which case it is much
> worse than
> > ntp-- broadcast is horrible since it cannot see those
> sudden increases
> > in delays due to congestion, etc. NTP is far to aggressive
> in throwing
> > away packets-- keeping only about 1/8 of the packets due to
> the clock
> > filter algorithm But ptp is if what you say is correct, much worst,
> > since broadcast mode is really only good to ms due to those variable
> > delays.
> >> There is a real difference available which is the followup message.
> >> It is possible to have the system record the timestamp of actual
> >> transmission and send it in a followup in ptp. I did some testing
> >> with this a few years ago and achieved the same results in
> >> transmission with both protocols. Having said that, I presume that
> >> one REAL benefit for time transfer is that PTP can, and
> does, run at a
> >> higher sync rate than ntp. It is also synchronizing to a single
> > clock.
> > The higher sync rate can be a benefit. It can also be bad
> because the
> > Markovian clock discipline means that no use can be made of
> long time
> > baselines to get better clock frequency accuracy (one of the great
> > advantages of chrony in situations where the phase noise dominates).
> > ntp's handling is a kludge.
> >> Also, the default ptp app is using multicast "broadcasts"
> with ttl 1
> >> and the client uses a slightly funky "point to point" multicast
> >> transmission as a ranging request to calculate propagation
> delay. The
> >> delay is then added to sync to arrive at value for local clock
> >> comparison. However, I don't think that there is a multi
> tap filter.
> >> In fact, in the open source ptp, I think the servo is just
> pretty much
> >> a jam hack. The point was to show the protocol.
> > It looked like it. But both ntp and ptp use simply
> markovian response
> > filters. They preserve no memory, which is silly.
> >> All of this is good dialogue but it is VERY important to note that
> >> what you test in a small LAN has very little bearing on the
> >> performance possible in various types of real networks of greater
> > scale..
> > Agreed.
> > But the OP wanted to use it in a small lan.
> >> Greg Dowd
> >> gdowd at symmetricom dot com (antispam format) Symmetricom, Inc.
> >> www.symmetricom.com
> >> "Everything should be made as simple as possible, but no simpler"
> >> Albert Einstein
> >> -----Original Message-----
> >> From: questions-bounces+gdowd=symmetricom.com at lists.ntp.org
> >> [mailto:questions-bounces+gdowd=symmetricom.com at lists.ntp.org] On
> >> Behalf Of Bill Unruh
> >> Sent: Wednesday, April 30, 2008 1:20 PM
> >> To: questions at lists.ntp.org
> >> Subject: Re: [ntp:questions] frequency adjusting only
> >> m.louvel at gmail.com (maxime louvel) writes:
> >>> On Tue, Apr 29, 2008 at 6:27 PM, Unruh <unruh-spam at physics.ubc.ca>
> >> wrote:
> >>>> m.louvel at gmail.com (maxime louvel) writes:
> >>>>> Hi,
> >>>>> I have know run a lot of tests.
> >>>>> Just to let you know what I've got so far.
> >>>>> I have tried NTP, and NTP + PTP (Precision Time Protocol).
> >>>>> I haven't tried Chrony nor TSClock.
> >>>>> I have used the software only implementation of PTP (ptpd).
> >>>>> With NTP only I have got an accuracy around 1ms,
> >> Actually, I have no idea what the difference is between
> the "software
> >> implimentation" of PTP and standard NTP is. The advantage of PTP is
> >> the HARDWARE timestamping of the packets as they come into the
> >> ethernet card (special purpose ethernet cards with clocks on board)
> >> and possibly PTP aware switches which race through the PTP packets
> > without delay.
> >> Software only means
> >> that PTP uses exactly the same kernel routines, etc. to read the
> >> computer clock as does ntp I assume. I cannot see how it
> can be better
> >> unless there are some severe bugs in NTP.
> >> What version of NTP are you running?
> >> _______________________________________________
> >> questions mailing list
> >> questions at lists.ntp.org
> >> https://lists.ntp.org/mailman/listinfo/questions
> William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
> Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
> UBC, Vancouver,BC | Program in Cosmology | unruh at physics.ubc.ca
> Canada V6T 1Z1 | and Gravity |
More information about the questions