Bill, As a physicist you know about the sampling theorem and Nyquist rate. The feedbacl loop bandwith and poll interval have been carefully chosen so that, even using only one of eight samples, the net sampling rate is twice the Nyquist rate. Oversampling doesn't improve the timekeeping accuracy and can even contribute spurioud high-frequency noise.
Dave Bill Unruh wrote: > 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 timestamp >>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: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf >>Of Bill Unruh >>Sent: Wednesday, April 30, 2008 1:20 PM >>To: questions@lists.ntp.org >>Subject: Re: [ntp:questions] frequency adjusting only >> >>[EMAIL PROTECTED] (maxime louvel) writes: >> >> >>>On Tue, Apr 29, 2008 at 6:27 PM, Unruh <[EMAIL PROTECTED]> >> >>wrote: >> >> >>>>[EMAIL PROTECTED] (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@lists.ntp.org >>https://lists.ntp.org/mailman/listinfo/questions >> > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
