Re: [ntp:questions] Trimble Resolution T
On Sun, 16 Oct 2011, Miguel Gonçalves wrote: On 16 October 2011 19:10, unruh un...@physics.ubc.ca wrote: In comp.protocols.time.ntp, you wrote: Hi! Anyone here used a Trimble Resolution T with NTP? From the pictures (all of the data sheets give a java error-- why in the world they couldn't just deliver a pdf file I do not know) it would seem that all it has is a PPS output on a coax cable. Thus you would want to hook that up to your parallel or serial port and use on the PPS devices to deliver the second mark to your computer. (gpsd, shmpps, kernel PPS) Thanks! I just opened the PDF data sheet in my safari browser in Mac OS X 10.7... I guess they had problems today. A short while later I got a page not available response instead of a java error. Anyway... PPS is easy... what about second numbering? From some of the other documentation I could read, it appears that it does deliver the seconds numbering over a usb connection. While usb is terrible for accurate timing, since the timing requirement of the seconds numbering is only about 1 second precision, usb should be fine. Now, I do not know what the format is. If it is nmea then something like gpsd should be fine, and be able to read both. If it is a proprietary protocol, then I have no idea. If you want to make use of the sawtooth correction (to get the time down to a few nsec) then that will almost certainly be proprietary. However, if you are feeding the timing into a computer, which you almost certainly are, it cannot handle anything near ns anyway, and for usec, the uncorrected pulse should be fine. Just remember to terminate the line to your input with the termination impedance of the cable you are using to get rid of ringing. While that ringing should not cause troubles better to be safe. Cheers, Miguel -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Trimble Resolution T
OK, can now get the datasheets, and it apparently does have a serial port The pulse is 3.3V so should be ok to run most serial port interrupts. It gets nmea but the control of the nmea seems to be via their proprietary language. So If you could switch the receiver into nmea befor it is grabbed by the program, like gpsd or shmpps, then using them to control ntp should be fine. Otherwise I have never used trimble proprietary language so have no idea what driver to use. On Sun, 16 Oct 2011, Miguel Gonçalves wrote: On 16 October 2011 19:10, unruh un...@physics.ubc.ca wrote: In comp.protocols.time.ntp, you wrote: Hi! Anyone here used a Trimble Resolution T with NTP? From the pictures (all of the data sheets give a java error-- why in the world they couldn't just deliver a pdf file I do not know) it would seem that all it has is a PPS output on a coax cable. Thus you would want to hook that up to your parallel or serial port and use on the PPS devices to deliver the second mark to your computer. (gpsd, shmpps, kernel PPS) Thanks! I just opened the PDF data sheet in my safari browser in Mac OS X 10.7... Anyway... PPS is easy... what about second numbering? Cheers, Miguel -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Wed, 7 Sep 2011, Miguel Gonçalves wrote: On 7 September 2011 05:07, unruh un...@physics.ubc.ca wrote: I've tried Garmin 18 LVC and Sure. Not want to start a war here but for the specifications and price Oncore beats both. :-) Beats them how? What measurements have you made of those two units in comparison with the oncore? I am not disputing but would like evidence rather than mystical feelings. I have no pretension to be a GPS expert. I am an IT guy and therefore I rely on others opinions/tests but 1. Oncore (as is Resolution T from Trimble) is a GPS specifically designed to do GPS time transfer and has features like position hold and TRAIM. This is a fact. I assume (and my rational thinking is usually right) that this must be better than a positional GPS receiver that has PPS like Garmin 18 and Sure. This is my belief... As lawyers in court would put this is MY opinion. Of course, if I don't back my statements with evidence and facts I expect people to take what I say with a grain of salt and judge themselves. And I looked at a paper from 2003 in which the encore was tested against a survey class/timing gps usnit and found to be 160ns later than tht unit. 2. I could buy a lot of gear, study a lot, and prove this, but in my line of work I get better things to spend my time on. And even then, Garmin and Sure could be as good as Oncore. But even then Oncore was cheaper. Did you really expect I would do this? That is fine, but why then are you saying that it is better? Cheaper, perhaps ( althoubh comparing aftermarket second hand antennaless unit price with a new price seems a bit disingenuous.) I have nothing against the encore. But I know of nothing for it either except an advertising bunff claim that its accuracy is far higher than anything I believe possible. 3. You could also prove I am wrong. I am not asking you to do this. :-) Oh come on. You are starting to sound like Fox news-- make any unsupported outrageous statement and tell others it is up to them to prove you wrong. I will stick to 1 and 2. Just my 2c. Is it worth that? It's actually worth much more. This is just a typical Internet used expression, that I've seen over the last 18 years, when people barge in discussions just to add their small contribution. I have not seen the evidence that, on this topic, it is worth that much. And when I ask for evidence I get the above. Additionally, please bear in mind that not everyone in this list is an English native speaker. Being Canadian, you most probably speak English and French. I speak them both and also Portuguese (native language). I believe that your Portuguese is not as good as my English or French. ?? What does english speaker have to do with anything? Yes, I know the overused phrase. I also know it is ironic (since the speaker almost always feels that his opinion just expressed is worth far more than that and it is an attempt at assuming an aw shucks, look at how humble I am. Which was the reason for my comment. Cheers, Miguel -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] garmin 18x and linux
On Wed, 7 Sep 2011, Chris Albertson wrote: 2011/9/7 Miguel Gonçalves m...@miguelgoncalves.com: On 7 September 2011 05:07, unruh un...@physics.ubc.ca wrote: I've tried Garmin 18 LVC and Sure. Not want to start a war here but for the specifications and price Oncore beats both. :-) Beats them how? What measurements have you made of those two units in comparison with the oncore? I am not disputing but would like evidence rather than mystical feelings. Simply read the manufacture's specifications.The most notable I do not believe manufacturer's specs, especially not when they seem to badly overstate the performance. difference is the one sigma error on the time of the PPS. The newest Oncore units (sold new by Synergy) are at the 2nS level while Garmin Yes, and I simply do not believe this. Note that Oncore has claimed this accuracy since at least 2003 ( ie old units). claims 1uS. That is a 500X difference. The older UT+ version on eBay I believe we were comparing Oncore to Sure, not Oncore to GPS18LVM typically com in at about 55nS (one sigma) and these sell for under $20. 55ns I might believe. In the specific case we have here the Garmin unit lacks any PPS at all. That is a HUGE difference. No argument. But there the argument was not the PPS timing but whether or not it met the OP's needs. It did. That is all that is required. The other huge difference is the ability of the Oncore units to self-survey their location, typically to within a third of a foot over a 2 hour period. They then use this known fixed location in their time solutions and greatly reduce uncertainty. That may, or may not, be an advantage, depending on how they do it. They use a binary protocol of the serial wire that dumps a lot of detailed information and the timing is good bt not measured One thing that comes over this bnary stream is the exact time relative to UTC of the last pulse. And an error estimate. Som for example it might say xxx.2314 plus minus 35nS This is functionality not present in any NMEA based GPS. Agreed, but also irrelevant. And I am confused. You were claiming that the pulses were within 2ns of utc, and your example here is 23us out from utc. That is 1 times different. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what happens when sys.peer turns stratum 16?
References: 4eea00b1-966a-4f39-a6cc-265ce959c...@s4g2000prh.googlegroups.com slrni06c22.l1a.un...@wormhole.physics.ubc.ca uo3cd7-9231@ntp.tmsw.no On 2010-05-31, Terje Mathisen terje.mathisen at tmsw.no wrote: unruh wrote: Note, that this is one of the reasons why your customers should never use 2 servers. You have no way to know which one is crazy. Use 3 or 5. (4 can be as bad as 2 if two of the servers go nuts in exactly the same way-- eg they are both tied to a single server which has gone nuts). This is simply wrong: The number of immediate peers don't matter, it is the number of _independent_ servers that you should count. Maybe. But that is not what you can count. Using multiple (say) S2 servers which all depend on a single S1 just means that you've (intentionally or not) outsmarted the ntpd voting algorithm. :-( Using the pool, you have no control over who the root servers are of the systems you get assigned and I am willing to bet that a large fraction of them use the same S0 at the end of the day. ( and if you count GPS, which could go haywire, I suspect that a very large fraction of the total use the same ultimate time source.) But even if you do not use servers with the same root, it is still possible that two servers could go out in thesame way, leaving to blocks with equal numbers. This is why committees have odd numbers of members. I agree that if the servers you use are realy independent then the probability of such equal blocks is verysmall. Unfortunately that independence is far from guarenteed. By the way, what was it you are saying is simply wrong? That ntp would be confused if there were two equal voting blocks? That four sources could produce two equal voting blocks? Terje -- ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Polling time backoff
On Sun, 29 Nov 2009, Richard B. Gilbert wrote: A much oversimplified explanation is that short poll intervals are used to correct large errors quickly and long intervals are to correct small errors very accurately. That is true if you are refering to rate errors, it is not for offset errors. For offset errors you are probably better off always with a short poll interval-- it catches all errors more rapidly. For rate errors there is the balance between white noise ( the independent errors from measuements of the offset due to delays, etc,) which become less as the baseline is increased, and fluctuations in the rate itself. But most people want their clock to minimize offset not to minimize rate errors, unless you expect there to be long periods of time in which the clock is offline. -- ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Stick to PPS, even if the prefer server fails
Harlan Stenn st...@ntp.org writes: In article 968zl.19988$ph1.19...@edtnps82, Unruh unruh-s...@physics.ubc.ca writes: Unruh That may be the logic, but it is seriously flawed. It also indicates Unruh that the decision to interpret PPS separately from the other drivers Unruh is flawed. atom should ONLY be used for a single separate PPS source Unruh decoupled from anything else. If you rPPS is combined with nmea then Unruh that nmea driver should be running the PPS since it is the Unruh combination that gives the time, and it is the combination that knows Unruh whether the PPS is good or not. Unruh Using some heuristic like is a prefer source available is a pretty Unruh poor substitute for knowing whether the PPS is good or not. I think I probably agree with you Bill. From one POV, it seems to me that each instance of a PPS source should come with health information about that PPS instance. This health information should include the current expected precision of the PPS signal. Not sure what the health info would be. The health of PPS is either great, (if the seconds is good) or attrocious (if the second is bad), and the driver presumably does not know this or it would have corrected the seconds (remember that this is like the date being a month out, if your accuracy was a second). Some PPS devices are stand-alone while others are combined with, say, a GPS signal. For the former case, it makes sense to treat them as separate sources of time. For the latter, it makes sense to treat the PPS signal as an adjunct device. Well, I would say that the GPS is the adjunct device since the PPS is far far more accurate (4 orders of magnitude). See http://support.ntp.org/bin/view/Dev/GettingNtpdItsConfiguration for more information. The bottom line is we need to figure out what else needs to be done to make the state of affairs with PPS sources even more generally useful. Clearly the PPS needs something auxilliary to determine the seconds. On the other hand, once that second lock is obtained it is hard to lose it. The system clock on most computers is not going to drift by 500,000 PPM (especially not most time servers). Now maybe I am not imaginative enough to think of what could go wrong. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Learnings: FC8 Linux ntpd syncs to NMEA message but not PPS
On Thu, 29 Jan 2009, phil.new...@wendysarbys.com wrote: - If you have NMEA output from the GPS in your ntp.conf file (127.127.20.0), expect it to have reach 0 reported when you finally get PPS (127.127.28.0) working. You can have NMEA or PPS from your serial input, you just can't have both at the same time from the same GPS on the same port. There is no reason why you could not have both, except that the programs (eg shmpps) has not been written to use both. It is as far as I can see, purely a software issue. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd syncs to NMEA message but not PPS
shmpps is a program which uses the shm refclock driver. It is referenced on time.qnan.org, and you can get the driver from there. In ntp, you set ntp to use the shm refclock Eg in my /etc/ntp.conf I have server 127.127.28.0 minpoll 4 prefer fudge 127.127.28.0 refid PPS flag3 1 This tells ntp to use the shm refclock driver ( it is lined to 127.127.28.0) Then you run the shmpps which checks to see if the ntp time is good to within a quarter second, and then runs shm_plc2 to start up the PPS program which writes to the shared memory for ntpd to read. You do need something else to set the clock to the nearest second. Now you could use the NMEA refclock driver WITHOUT the PPS to provide the initial time server 127.127.20.0 On Mon, 26 Jan 2009, phil.new...@wendysarbys.com wrote: Well, I've managed to wind myself completely up in my huggies I built a nice little 18x LVC setup this weekend, based on the circuit at time.qnan,org. I successfully get data from the GPS (9600 baud) and a PPS signal. I tried using the gpsd driver and am having no luck with it whatsoever. So, I have to ask at this point, what exactly did you mean just use the shmpps set of routines to set up pps using the shm refclock? I am running Fedora 8 Linux, for what that might be worth Thanks for any assistance you can provide! Phil Debug output from gpsd. Seems to be communicating OK, but loops with reconfiguring for garmin serial gpsd: = GPS: $GPRMC,192734,A,4006.0064,N,08306.3234,W,000.0,203.8,260109,006.5,W,D*19^M gpsd: GPRMC starts a reporting cycle. gpsd: GPRMC sets mode 2 gpsd: ntpshm_put: Clock: 1232998054 @ 1232998054.745896 gpsd: = GPS: $GPGGA,192734,4006.0064,N,08306.3234,W,2,07,2.4,345.2,M,-32.8,M,,*77^M gpsd: GPGGA sets status 2 and mode 3 (changed) gpsd: = GPS: $GPGSA,A,3,,,10,,15,,21,24,26,29,30,,4.7,2.4,4.1*3E^M, gpsd: GPGSA sets mode 3 gpsd: = GPS: $GPGSV,3,1,11,02,34,096,18,05,03,217,26,10,64,040,25,12,03,207,18*72^M gpsd: Partial satellite data (1 of 3). gpsd: = GPS: $GPGSV,3,2,11,15,36,171,40,18,02,239,33,21,16,293,21,24,58,314,24*7D^M gpsd: Partial satellite data (2 of 3). gpsd: = GPS: $GPGSV,3,3,11,26,45,149,30,29,60,287,25,30,12,238,32*4C^M gpsd: Satellite data OK (3 of 3)., gpsd: = GPS: $PGRMC,A,,100,,A,,1,2,1,30*4B^M gpsd: GPRMC sets mode 0, gpsd: found $PGRMC,. gpsd: switch_driver(Garmin Serial) called... gpsd: Reconfiguring for Garmin Serial... gpsd: = GPS: $PGRMC,A,,100,,A,,1,2,1,30*4B\x0d After running for about the last hour, this is what I continue to see on the [r...@splunk /root]# ntpq -p remote refid st t when poll reach delay offset jitter == xSHM(0) .GPS0. 0 l1 16 3770.000 -667.98 42.005 SHM(1) .PPS.0 l- 1600.0000.000 0.002 x10.255.213.232 128.4.40.12 3 u 31 64 3770.186 -1.647 0.429 [r...@splunk /root]# cat /etc/ntp.conf driftfile /var/lib/ntp/drift server 127.127.28.0 minpoll 4 fudge 127.127.28.0 time1 0.000 refid GPS0 server 127.127.28.1 minpoll 4 prefer fudge 127.127.28.1 refid PPS server ntp.wendysi.com iburst $GPRMC,193313,A,4006.0050,N,08306.3246,W,000.0,203.8,260109,006.5,W,D*1B $GPGGA,193313,4006.0050,N,08306.3246,W,2,05,2.2,344.7,M,-32.8,M,,*75 $GPGSA,A,3,,,10,15,,24,29,30,4.0,2.2,3.3*3D, $GPGSV,3,1,11,02,33,098,34,05,02,215,14,10,62,041,18,15,38,170,38*70 $GPGSV,3,2,11,18,04,241,36,24,60,317,28,29,62,282,27,30,11,236,26*7A $GPGSV,3,3,11,07,01,042,00,08,03,077,00,12,01,206,00*44, You can just use something like gpsd to use the shm hardware clock to run the pps. I would just use the shmpps set of routines to set up pps using the shm refclock. -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] My extra second ...
On Sat, 3 Jan 2009, Danny Mayer wrote: Unruh wrote: George R. Kasica geor...@netwrx1.com writes: On Fri, 02 Jan 2009 14:31:34 +0100, Rob van der Putten r...@sput.nl wrote: Hi there Steve Kostecke wrote: All my Linux systems had a fine time. None of them locked up / crashed / rebooted / etc. The kernels involved included: 2.6.24-etchnhalf.1-amd64 2.6.18-5-486 2.6.16-2-486 2.6.18-5-k7 2.6.18-4-powerpc 2.4.16-k7 What about the hardware (Intel /AMD)? Rob: Everything in my post above was Intel based, no AMD or otherwise. Why in the world would you then have an amd64 kerenl and two k7 kernels, and one powerpc kernel? None of those is intel. He *never* said that. Those are Steve's systems. The post even includes that fact. Ooops. My mistake-- not reading th properly Danny -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Leap Second
Unruh [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
Hi all,
Since yesterday I saw the leap second Flag set on some servers of
ntp.pool.org. I'am quite surprise because the leap second add to be
set the 31/12/2008 and not the 1/12/2008.
Is it normal
The leap is announced at the beginning of the month to make sure that all
ntp clients know about it. It always occurs at the end of the month ( I
think ntpd has it hard coded as the end of June or Dec, but in principle it
could be any month)
Here is a fragment from the ntp code (ntp_loopfilter.c) (4.2.4p4)
if ((tm-tm_mon + 1 == 6
tm-tm_mday == 30) || (tm-tm_mon +
1 == 12 tm-tm_mday == 31)) {
if (leap_next LEAP_ADDSECOND)
ntv.status |= STA_INS;
else if (leap_next
LEAP_DELSECOND)
ntv.status |= STA_DEL;
Ie, ntp pays attention to the leap second flag only if it is June 30 or Dec
31. Now, that is not correct since I believe that a leapsecond can occur on
any month, but the tradition is that if there is only one or two a year,
those are the dates chosen. In a century or two, when there are more than 2
per year, then ntpd will run into trouble. (Of course the definition of
time might have changed anyway, or the whole UTC kludge may be scrapped or
a new edition of ntpd not containing that assumption may be published.)
Note that the very existence of ntpd with its assumptions puts huge
pressure on the standards organisation to comply with the assumptions.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] broadcast client
On Sat, 22 Nov 2008, Danny Mayer wrote: Normally I would not respond to a 2 month old message but I need to correct some things here that were written. Unruh wrote: connected via 1 Gbps switch. The network is lightly loaded and I configured the clients as such server ntp minpoll 4 maxpoll 4 iburst Dave Mills, please note, yet another non-believer in the NTP algorithms. What this has to do with not believing in the algorithm I have no idea. If ntp runs from a refclock that is EXACTLY the default behaviour. This is NOT the default behavior. minpoll defaults to 4 and maxpoll minpoll defaults to 6 as far as I know. defaults to 10 and you should NOT change them unless you understand the discipline arguments and how these changes affect the discipline. Sure, and I gave my reasons below. Running on a local private network where you are referencing your own server, that behaviour is also fine. The reason for the backup to long poll intervals is a) to save the public servers from flooding, and b)to discipline the local clock's drift rate in case there are long periods of disconnection from the net. If you have constant connection and it is your own server, neither of those apply, and short polling is better. a) This is not correct. It has nothing to do with public servers. In addition I've conducted tests where I've fired 100's of packets per second and not even noticed any affect on other work on the target server. In the case of your own servers you won't notice the traffic in any event. This is simply untrue that the large public servers would not notice if everyone used minpoll 4. Many of the public servers get 10s of thousands of queries a second and would be even higher if poll intervals were shorter. Some were completely brought to their knees when the ntp on routers were set to poll interval of 0 ( once per second) Minimizing network traffic IS one of the considerations. b) is also incorrect. The purpose of the backup is in the algorithms and ^^ Not clear what this means. has to do with oversampling. In this case you are making your local clock less stable rather than more stable. More is not necessarily better and the sooner that people understand this the fewer problems that they will have. The allan minimum on a local network is far less than David assumes in his model. The frequency shits are dominated by temp variations which have hourly changes typically for a computer which actually does work other than ntp. This means that the long time intervals assumed by David are in fact inapporpriate for local networks. Ie, short intervals are better especially if you have constant and fast connectivity. I have no idea why you make the first claim. Yes, the rate will vary as the network rates vary, but who cares. The purpose is to discipline the TIME, not the rate. No. The purpose is to discipline both. No, the purpose of ntp is to discipline the time and it does this by disciplining the rate. The rate discipline is there to discipline the time. And short polls discipline the time better. It doesn't. Agrument by blatant assertion? Rate discipline is overrated because of the rate variations due to temperature changes during the day anyway. No, it is not overrated unless you are oversampling like you are recommending. Yes, I am advocating oversampling. You are claiming that it is not a good thing to do. Please defend that position with a bit of maths, not assertions. Oversampling as you call it will discipline the time better especially with the Markovian feedback filter ntp users. It will be worse at disciplining the clock rate which will fluctuate more when you oversample. Ie, oversampling will make int (t(T)-T)^2 dT smaller, where T is the true time and t(T) is the clock time at true time T. It will however make int (dt/dT-1)^2 dT larger. Now, for most people, it is the time that is important, not dt/dT. If it is the rate that is important to you ( ie you must know short intervals of time accurately -- ie to better than 1PPM-- eg you are timing things that last one second and you want to know them to 1usec) then use longer poll intervals with the ntp algorithm ( or use a different algorithm and different hardware). Danny -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Speed of ntp convergence
The key seems to be the lines: etemp = min(mu, (u_long)ULOGTOD(sys_poll)); dtemp = 4 * CLOCK_PLL * ULOGTOD(sys_poll); plladj = fp_offset * etemp / (dtemp * dtemp); Ie if we assume that the etemp is determined by the poll interval, we have plladj=fp_offset /(16*CLOCK_PLL^2*(Sys poll time) That is a huge time scale. Surely CLOCK_PLL should only come in there to the first power (at most), not squared. Unruh [EMAIL PROTECTED] writes: Just another data point on the behaviour of ntp. My ntp went down ( due to something removing the ntp user from the password file). When I brought it back up again, the time was out and I think the drift file was out. I have three sources-- a stratum 2 nearby server, a distant stratum 1 server and a gps refclock with a PPS. The PPS is setup to drive the refclock_shm driver. The refclock has a poll of 4 (pollinterval of 16), and both the other are default ( minref 6 maxref 10) I brought the system back up at 54770 78683.101 (the ntp log file date and time) The way the PPS works is that it waits about 5 min until it is sure that ntp has the time from the other servers to within 250ms. It then switches on the shm driver. The refclock started out with an offset of about 150ms , which increased to 280ms and was eventually (about 6 min later) reset to zero offset because I was running with the -g for ntp. This was also the point at which the PPS shm kicked in. However the drift rate was clearly off, because the offset then gradually increased until at 82555 (3878 sec after the start or about 1hr) it was 52ms off (the maximum offset) . By the end of the day ( 86400 or about 7700sec or 2 hrs) it was still 19ms offset from the PPS zero time. An hour later, it was still 7ms off, another hour, 2.6ms and another hour later, still 1.2 ms off. Ie, only after about 6 hours was it within a ms of the correct time. Now, usually this PPS controls the time to within about 2us (not ms, usec) but it is apparently going to take over 10 hours to get there. That is of course completely rediculous. The shm poll interval is 16 sec and even if ntp throws away 7/8 that would give a max time between data points of about 128sec or 2 min. Thus ntp should have a time constant of about 4 min. Instead the time constant is about an hour. It would seem that the time constant is selected as far longer than the longest poll inteval. ( the poll interval during this time on the other two source was 64 sec, or poll interval of 6). Within the first minute, I could by hand determine the offset and slope of the CPU clock to withing a few usec not msec or tens of msec. and the slope to better than 1PPM. But never mind my concern about the markovian system feedback system ntp uses. That argument I am sure everyone is tired of. What concerns me is the long (1hr) time constant of the feedback loop, about 200 times longer than the poll interval. Ie, it does not seem to me that ntp is fulfilling its design criteria. Here after 5.5 hours after startup is the ouput of ntpq -p string[root]ntpq -p remote refid st t when poll reach delay offset jitter == +tick.usask.ca .GPS.1 u 18 64 377 44.9251.455 4.252 +ntp.ubc.ca 140.142.16.342 u 44 64 3430.6720.260 0.767 *SHM(0) .PPS.0 l1 16 3770.0001.136 0.023 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd -q is slow compared to ntpdate
Harlan Stenn [EMAIL PROTECTED] writes: Nick's SNTP code is about to be replaced with completely new code, written by J. Max Kuehn as his GSoC project. Ah. OK. And this program will do what? Is it supposed to be a fully fledged sntp (ie, act as a client only ntp program, or a server only if there is a refclock source, and as a one shot program) or is it a one-shot replacement for ntpdate? And is it going to have the complete ntp filter/best source selection algorithm? And will it have ntp's Markovian adjustment algorithm or a regression algorithm (a la chrony an msntp), or...? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Finding out where ntpd gets its ntp.conf file
Joseph Gwinn [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Hal Murray) wrote: I'm not a sysadmin, but am digging into service. I don't recall that the service man page was that helpful, but will look again. service is mostly a shortcut to save typing. If you think it is getting in your way, run /etc/init.d/ntpd whatever by hand. (It also fixes up environment and cd-ed directory and whatever.) Yes. This is what we did to prove that NTP really could generate loopstats and peerstats. No I suspect you ran /usr/sbin/ntpd, not /etc/init.d/ntpd /etc/init.d/ntpd start should do EXACTLY the same thing as when the system runs it on bootup. The -x command to bash will print each line as it gets expanded and executed. So you might try something like: bash -x /etc/init.d/ntpd start to see what is really going on. Another good idea to try. It of course produces far more output but obviates the need to insert echo lines into /etc/init.d/ntpd Note, I am wondering what has happened to all these suggestions? Have youtried any of them yet? Have you discovered what it is actually using as its configuration file? You might want to post the config file here ( ntp.conf) here in case it is some error in that file which is causing your problems rather than that ntpd is using some other config file. Thanks, Joe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] What happens if ntp server unavailable at start up?
A question has arisen in another group-- What happens if, when ntp starts up, the remoter server is unavailable ( eg no DNS or no connection)? This is highly likely to be the case for a laptop for example, where the connection with the local network is only brought up by the user after a while, or on wakeup from a power outage when the net may be unstable or the router be out when ntp comes up. If a server disappears in a running ntp, ntp keeps trying, backing off on the poll interval after a while. But what does ntp do if on the first try to a server, there is no response, or if the dns is down. Does it forever scrub that server? (that seems to be what happnes-- if so why?) or does it do the same thing as if the server disappears after a while (keep trying with increasing poll intervals)? I notice that there is a keyword dynamic which is not yet implimented but which seems to imply the second option. Also what happens to ntpd if it has no servers whatsoever, not even a local one? Does it keep running, doing nothing, or does it exit? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Linux 11-minute mode (RTC update)
Uwe Klein [EMAIL PROTECTED] writes: Serge Bets wrote: Hello David, On Tuesday, July 22, 2008 at 7:45:06 +0100, David Woolley wrote: Serge Bets wrote: Hwclock 2.33 sets the RTC with typically a maximum error of 10 microseconds That would only be possible if the RTC's counter was updated on both phases of the 32kHz clock, which I rather doubt. Excellent example, Dave! The source 32K crystal period being 30 µs, you point the finger at a real issue. An issue that has been squashed some time ago by hwclock's feedback mechanism. Not a problem anymore. For simplification, I'll assume everything else is instant and perfect, and will neglect RTC restart delay. When we set the RTC, the last crystal pulse happened between 0 and 30 µs ago. Let's pick 18 µs for the example. This last pulse becomes the start of this RTC second, the next second will start 32768 pulses later, and so on. Result: the RTC is in advance by +18 microseconds. Problem. However the feedback mechanism measures this +18 µs offset, and corrects future readouts by -18. Final result: nothing less than perfection. :-) Serge. If you fix the RTC time in the ISR for the second tick you have a deterministic relation from edge to (update) action. It seems that things are even worse than I suspected with the Linux kernel and the machines which have HPET. Apparently the HPET disables the rtc interrupts and takes them over. But it operates on a 64 Hz clock and only interrupts on that clock tick. Ie, the interrupt from the rtc is likely to out by many msec from the true turnover of the rtc clock (This is according to Dave Burnel the rtc-cmos maintainer). But worse than that the HPET rtc can get itself into a totally horrible state, where the interrupts are way out ( 50-500ms) No amount of care in the hwclock program can get around this kind of nonesense. See kernel bug 11153. It seems that if you have any desire to have good time, use the nohpet option to the kernel. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift modeling question
shy author [EMAIL PROTECTED] writes: Has anyone thought about removing both the linear terms and quadratic terms in the drift, by utilizing the temperature sensor readings available on many of the latest motherboards? Crystal oscillators tend to have both a linear bias and a quadratic bias, determinate upon temperature, leaving a stochastic component, which I believe we're trying to compensate for all along by the operation of ntp. Integration of the temperature readings and knowledge of the current drift should suggest the appropriate coefficients for the corrections. Just a thought, but it seems a shame that we're not taking advantage of the thermal data available to us, when correcting for clock drift and simply using a linear correction. A Quadratic correction tends to run away pretty badly if you suddenly have a period of no ntp readings. But I am not at all sure that is what you mean. Rather you seem to mean that one use the temp to estimate what the linear drift is ( from the past readings of temp and drift.) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] question about DST
On Sat, 31 May 2008, Asrai khn wrote: Its mix of OS Linux, Unix (sun, freebsd) and yes we also have some hardware of Lucent (MaxTNT) that running thers OS TAOS, As i said we dont' have this DST before and its first time government is implementing it (coz of sever power crises) Which country? So you thinks its not good practice to change system clock with 'date' command? by forwarding it by one hour. You can do anything you want. BUt on a linux/Unix system it is all handled by the zoneinfo files. Just update your tzdata file and forget about it. I thinks to change it manually will also requires me to disable ntp sync otherwise machine will correct its time again. Yes. So why do it. Just download the file and install it and be happy. regards. On Sat, May 31, 2008 at 1:36 AM, Kevin Oberman [EMAIL PROTECTED] wrote: From: Unruh [EMAIL PROTECTED] Date: Fri, 30 May 2008 20:10:19 GMT Sender: [EMAIL PROTECTED] [EMAIL PROTECTED] (Asrai khn) writes: Note: please reply to me direct as i am not subscribe to mailing list. It is not a mailing list, it is a news group. Keep coming back for information. No. It is both a mailing list and a news group. A great many of us have abandoned usenet and read this via the mail list. I assume Asrai sent his question to the mail list. You read it via the news group. Since you ignored his request to copy him, he will never see your response of: 1. Is it possible to adjust only the ntp server for DST thing and let all other machines automatically get the new time from ntp server? No. NTP knows nothing about DST. It operates in UTC. 1.1. If not do I have to adjust all machine clocks manually? What operating system? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] question about DST
On Fri, 30 May 2008, Kevin Oberman wrote: From: Unruh [EMAIL PROTECTED] Date: Fri, 30 May 2008 20:10:19 GMT Sender: [EMAIL PROTECTED] [EMAIL PROTECTED] (Asrai khn) writes: Note: please reply to me direct as i am not subscribe to mailing list. It is not a mailing list, it is a news group. Keep coming back for information. No. It is both a mailing list and a news group. A great many of us have abandoned usenet and read this via the mail list. I assume Asrai sent his question to the mail list. You read it via the news group. Since you ignored his request to copy him, he will never see your response of: Ah, ok. But then he should subscribe to the mailing list while he is asking questions of the list or the newgroup. Ie, expecting people to privately email him answers to questions which he asks in public is not a good idea. It deprives others of the benefit of the answers ( or of the benefit of having the mistakes in the answers pointed out by other more knowledgeable people.) 1. Is it possible to adjust only the ntp server for DST thing and let all other machines automatically get the new time from ntp server? No. NTP knows nothing about DST. It operates in UTC. 1.1. If not do I have to adjust all machine clocks manually? What operating system? Just to amplify, Under Linux, BSD and others, the crucial file in something called tzdata. ftp://elsie.nci.nih.gov/pub/tzdata*.gz which can be downloaded from the web. In that file are listed all the known time regions together with their DST rules. They update it about 10 times a year, every time they become aware of some new time zone information from somewhere in the world. Compiling it with zic, installing it, and pointing your system to the appropriate file is all you need. That will handle all changes like DST automatically with no intervention needed. Under Windows, I do not believe any such structure exists, and you have to persuade Microsoft to publish a patch for your system which contains the info. But I may be wrong. Under Mac, I think that they also use the tzdata database to handle time, but again I could be wrong. Thus his telling us what OS he uses would enable more helpful answers to be given. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
David L. Mills [EMAIL PROTECTED] writes: Jan, A timer interrupt is required each second to update the clock frequency no matter what. In addition, a sweep is made through the associations to I thought that the ntp daemon runs the per second routine only if the kernel discipline is not available. And Linux I thought has the kernel discipline. Now of course I suspect that the kernel has to wake itself even more often than once a second (eg the timer interrupt) and if it did not, the effect on the time discipline would be pretty bad. see if a poll is pending. It would be in principle posssible to implement a system of queues to avopid sweeping the associations each second, but that would save very few cycles, add some more cycles and additional complexity. My advice is to avoid the patch; however, be advised if used it might not work in future as the code is further refined. Dave Jan Ceuleers wrote: I came across the following page: http://www.lesswatts.org/projects/powertop/known.php which says the following on ntpd: By default, the ntp time synchronization daemon will wake up once per second, and will make the kernel do work on it's behalf even more. Red Hat has created a patch to ntp to fix this issue and ships it in their rawhide and FC7 ntp packages. You can download this patch from the Fedora cvs server. Has anyone here looked at that patch? Does it compromise correctness of the algorithms? Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
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
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 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 -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
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 occasional 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. 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. LRD? 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). 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. -Original Message- From: Bill Unruh [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 3:21 PM To: Greg Dowd Cc: questions@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
Re: [ntp:questions] high precision tracking: trying to understand sudden jumps
On Sun, 30 Mar 2008, [EMAIL PROTECTED] wrote: At 04:51 PM 3/30/2008 -0700, Bill Unruh wrote: Are those on the same day? Yes, same day. Uncorrelated to anything I can identify or each other. Same story on all the boxes. Running a hefty multi-system compile with heavy NFS and Samba traffic does not produce these events, though it disturbs the Windows boxes slightly when CPU goes to 100%. Which linux and which windows are those graphs since you have 2 linux and 2 windows clients. That's the dual-core AMD 2.4GHz Athlon Tyan mobo whitebox runing Centos 4.5 SMP kernel. Similar results on the Dell Dimension 2400 2.4GHz Intel P4 running Centos 4.5 mono-processor kernel. Windows is a dual-core 3.4GHz Pentium D Tyan mobo whitebox running 2003 R2 SP2 standard server. As I said, seeing the peerstats files would be helpful (offset and roundtrip) Might try them later, but I can't belive a high-quality SMC switch is causing multi-millisecond delays. Just not possible. Pings are all about 400 microseconds, consistent but slightly different on each system. Round trip is 800 microseconds. Attaching the output from a bulk 'ntpq -p' 'ntptrace' script I have below. Note that's 'ntptrace' version 4.1 since the 4.2 script has useless offset info. I have had weird latencies on some switches here. And since all your machines are experiencing this, that switch is the only commonality (or the ntp server). Do you have the peerstats on the server as well to make sure that there are not some weird delays there. Also these graphs seem to have cut off the spikes. Are the spikes actaully higher or is that an illusion? Higher. Sometimes 1ms, sometimes 5-6ms. (Note the spikes are hundreds of usec, not many msec) That would be the ~1ms example, check out the other one. I am also really really really disturbed that you have so many servers. You are trying to test out one specific server. The others are simply liable to confuse everything. For example ntp could for some bizarre reason, suddenly decide to use one of those other sites as the preferred server and give a glitch. And what are all those CDMA servers? Set your system up with one single source, the one you want to test. remote refid st t when poll reach delay offset jitter == Endrun CDMA LOCAL(0)LOCAL(0)10 l 18 64 3770.0000.000 0.015 *HOPF_S(0) .CDMA. 0 l6 16 3770.0000.000 0.015 Centos 32 *eachna .CDMA. 1 u3 16 3770.683 -0.004 0.009 -tock.usno.navy. .USNO. 1 u 452 1024 377 20.6781.432 2.822 +navobs1.wustl.e .GPS.1 u 479 1024 377 50.136 -1.513 0.164 +time.nist.gov .ACTS. 1 u 471 1024 377 66.528 -1.708 0.156 -tick.ucla.edu .GPS.1 u 432 1024 377 87.3723.296 0.085 Ultra 10 *172.29.87.3 .CDMA. 1 u 11 16 3770.869 -0.016 0.042 172.29.87.15: stratum 2, offset -0.07, synch distance 0.00783 172.29.87.3: stratum 1, offset -0.18, synch distance 0.00038, refid 'CDMA' Ultra 80 *172.29.87.3 .CDMA. 1 u4 16 3770.942 -0.012 0.012 172.29.87.17: stratum 2, offset -0.38, synch distance 0.00685 172.29.87.3: stratum 1, offset -0.17, synch distance 0.00038, refid 'CDMA' 44p *172.29.87.3 .CDMA. 1 u 13 16 3770.809 -0.001 0.016 172.29.87.13: stratum 2, offset -0.14, synch distance 0.00627 172.29.87.3: stratum 1, offset -0.18, synch distance 0.00038, refid 'CDMA' Centos 64 *172.29.87.3 .CDMA. 1 u 12 16 3770.6640.003 0.487 172.29.87.19: stratum 2, offset -0.09, synch distance 0.00720 172.29.87.3: stratum 1, offset -0.18, synch distance 0.00038, refid 'CDMA' W2K3 64 *172.29.87.3 .CDMA. 1 u4 16 3770.7340.053 0.014 172.29.87.20: stratum 2, offset -0.60, synch distance 0.00650 172.29.87.3: stratum 1, offset -0.19, synch distance 0.00038, refid 'CDMA' XP 32 laptop *172.29.87.3 .CDMA. 1 u7 16 3770.8190.468 0.256 172.29.87.12: stratum 2, offset -0.000173, synch distance 0.00655 172.29.87.3: stratum 1, offset -0.17, synch distance 0.00038, refid 'CDMA' -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP server + ntpd 4.2.4 client
[EMAIL PROTECTED] (Andy Helten) writes: I use PoE every day -- it powers the outdoor antennae that connects to my wireless ISP (distance of about 5 miles). I have gotten up to 3000kb/s over this link (which is slightly higher than what I'm paying for). So, whatever you are debating here, PoE is almost certainly *not* the problem. OK, learn something new every day! I do agree that it is weird that they would have put SNTP on that thing rather than NTP. How much did it cost? David Woolley wrote: Unruh wrote: Just looked it up. A bit bizarre-- power over the ethernet? The ethernet has no power supply capability. Do you mean that you have to supply the device with 60V running on one of the unused ethernet cable lines? Sounds noisy to me. I believe it is a relatively new, but very real, standard. The power is transmitted as a phantom between two pairs. In one variation, they are the pairs used for normal, 10baseT. I gather one reason is that there are exemptions in electrical codes for ELV power feeds as part of datacommunication systems, whereas a normal feed would require a formally qualified (not just competent) electrician. The feed is 48V DC. I'm not 100% sure that counts as ELV, but it is the same as most analogue telephone systems. The apparent source specification is IEE 802.3-2005, although I haven't gone to source. As the power is common mode with respect to the signals, the noise should not be excessive. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] chrony and ntp comparison-- ADSL hookup
Bill Unruh [EMAIL PROTECTED] writes: I have now run some absolute time discipline tests using chrony and ntp The server is a GPS PPM disciplined clock using ntp. The client is a machine on an ADSL line. The round trip between server and client is about 16ms, which is about 100 times longer than the round trip times used earlier in the previous tests I posted. In each case I run the GPS PPM to measure the offset of the computer clock vs the GPS (It is a parallel port interrupt routine which on each interrupt reads the system clock and saves it in a buffer readable from /dev/gpsint. Ie, I measure the system time each time it receives a pulse from the GPS Garmin 18LVC receiver. Since this has an mean accuracy of about 2usec, its noise is negligible. The mean in both cases is about -.3ms. Ie the adsl trip is assymetric as to outgoing and return but about .6ms. In the case of ntp the variance in the readings is about .32ms. For chrony, the variance is about .11 msec, 1/3 of the variance of ntp. This is in confomity with what I found for the client on the same subnet as the clock. Now, chrony is much more aggresive in decreasing the poll interval when the statistics gets bad, so the mean poll time for chrony was 36sec while for ntp it was 127 sec (in both cases minpoll was 4 and maxpoll was 7). Since the noise is dominated by the random transmission times, and not the frequency drift of the osillator in the computer, this should not make any difference. (the variations in the drift are about 1ppm, and in 128 sec, that is only .1ms ) However, I will alter chrony to make it less agressive in decreasing the poll interval, and I hope increasing its mean poll time. If that does not work I will set minpoll to 6 for chrony. However the indications are that chrony is again more accurate than is ntp in disciplining the clock. Note that seems a reasonably stringent test of the two programs in a situation in which the transmission noise dominates the error budget, rather than the frequency drift noise as in the test on the same subnet. One more data point. I altered chrony not to be so ready to decrease the poll interval when the jitter grows. In my current run of .6 days, chrony has an average poll interval of 80 sec (minpoll 4 maxpoll 7) rather than the 36 with the original version. (Note that the time averaged poll interval-- ie if you took the poll interval at each second and averaged those-- is 108 sec. Ie most of the time is at maxpoll of 128s) In this case the variance of the chrony readings decreased slightly to 98usec from about 112usec. As I expected increasing the number of readings ( which decreases chrony's timebase over which it estimates the offset and slope) actually makes things slightly worse, rather than better. To summarize, chrony has a factor of slightly less than 4 better variance than ntp in the offset of the computer clock as compared with true time ( A GPS PPS receiver on the client machine). Both ntp and chrony are using as their server a GPS PPS controlled system whose error is about 3usec, two orders of magnitude less than than the variance produced by the ADSL delays. Note that the local GPS on teh client is NOT used to discipline the clock in any way. It is purely a measurement tool. The GPS on the server and client are identical (both Garmin GPS 18LVC running into the parallel port and triggering timed interrupts). They are separated by 6km. horizontally and about 80 meters vertically. It is interesting that both ntp and chrony agree that ADSL introduces about a .3ms bias into the time. (Both agree that the computer clock disciplined by both ntp and chrony via the adsl connection is about .3ms slow of true time.) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
David Woolley [EMAIL PROTECTED] writes: Unruh wrote: Under ... is the line dst[i]=peer-filter_delay[j] Apologies, I missed that detail. I guess dst has changed its meaning over time. (It doesn't really look right to me though, as there is a sudden discontinuity as you cross the Allan Intercept.) However, that doesn't change the fact that the sample used is ord[0], i.e. the sample with the lowest dst value, subject to it also being newer than the last one used. That is not necessarily the most recent. It looks like you are right that it does not only select it if it is the latest. Comparing the peerstats output ( augmented by the most recent p_offset and p_del) and the loopstats, there is a loop output whenever the min changes, not only if it is the latest as well. I must have misread the code. Sorry. But that still can result in 8 measurements without any being used. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
On Wed, 30 Jan 2008, Danny Mayer wrote: Unruh wrote: David L. Mills [EMAIL PROTECTED] writes: David, We can argue about the Hurst parameter, which can't be truly random-walk as I have assumed, but the approximation is valid up to lag times of at least a week. However, as I have been cautioned, these plots are really sensitive to spectral lines due to nonuniform sampling. I was very careful to avoid such things. But the lines I am refering to are not artifacts, they are there because of the way the computer is used. -- the temp fluctuations caused by people running the machine daily, except on weekends. These are not part of any random walk process. They are real jumps in the drift rate of the machine, large jumps, and definitely not random. Well of course. You are running Linux and losing interrupts. FreeBSD and friends don't suffer from that problem. I seem to remember setting HZ=100 mostly eliminates that problem, at the price of rebuilding the kernel. Danny No they are not lost interrupts. They are NOT jumps in the offset, they are jumps in the frequency, which will last for a few hours and then jump back. Lost interrupts do not act like that-- they would jump the offset by 10ms (or 4ms) which is definitely not happening. Andit is hard to gain interrupts. -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
What was the problem? On Mon, 28 Jan 2008, Danny Mayer wrote: Unruh wrote: [EMAIL PROTECTED] (Danny Mayer) writes: David L. Mills wrote: Danny, It doesn't stop working; it just clamps whatever it gets to +-500 PPM as appropriate. If the intrinsic error is greater than 500 PPM, the loop will do what it can with the residual it can't correct showing as a systematic time ofset. Dave I didn't mean to suggest that ntpd stopped running. It was that the clock was drifting steadily off into the sunset. I realize that if the problem corrected itself ntpd would bring things back to normal. But that suggests that the drift rate of your chip became bigger than 500PPM, which is huge. Maybe something altered the tick size inappropriately. ntp should have hauled the offset back to zero -- just taking a longer time ( 100msec at 500PPM takes about 200 sec to eliminate-- which is not that long.) No, it was something else entirely and not something that ntpd, chrony or any other application could do anything about. It's fixed now. Danny -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [EMAIL PROTECTED] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
On Mon, 21 Jan 2008, Danny Mayer wrote: Unruh wrote: All I say is that the experiments I have carried out show that ntp is slow to converge if it starts of badly, and leaves the offset scatter larger than chrony does. It does have a smaller scatter in the rate. But you are using an extremely old version of ntp and things have radically changed since that version was released. Try rerunning you experiments with ntp 4.2.4 and see what you get then. You also need to fix your calculations if you are going to get good results as I mentioned in a previous message. I did. The calculations I presented were with 4.2.4, except for the convergence on initial transient. I have not retried that experiment ( It takes too long) Most of the results regarding the scattering of the offset are for 4.2.4. It is a factor of a little over two worse than chrony in regulating the offset. In a few weeks I will probably try the initial transient stuff again. (I am out of town next week) However, do you believe that the bechaviour of 4.2.4 under intial conditions is better than 4.2.0 (eg either no drift file or a bad drift file)? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
Having run NTP stably now for three days on a machine I previously ran chrony on , I compared the control of the clock on that machine with chrony and with ntp (the comparison is obviously sequential, since both cannot run on the same machine at the same time.) The chrony run was from Jan 13.5 to jan 18.3 while ntp was from Jan 20.0 to 21.7 during which time ntp was stable and the intial aquisition of lock was completed. Offset error: NTP: Mean=-3.1usec, Std Dev=63.1usec Chrony: Mean=-1.5 usec, Std Dev=20.1usec Rate fluctuation: NTP:Mean=25.32 Std Dev=.078 (PPM) Chrony: Mean=25.26 Std Dev=.091 (PPM) Ie, while the rate might be better controlled by NTP ( although the fact that the time interval was smaller may mean that this is just a measure of the natural variation of the clock itself-- since the ntp measurements were over the weekend, and chrony encompassed the weekdays when the grad students use the computer) the offset control by chrony was a factor of 3 better than by ntp. Note that in each case the server was the same Linux machine on the same subnet controlled by a Garmin 18LVC with offset fluctuation of the order of 2usec controlled by NTP, a modified shm refclock driver and a special purpose written parallel interrupt driver. The roundtrip time is about .18msec between the two machines. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] oscillations in ntp clock synchronization
I have been keeping track of the clocks on my various systems. One is synced using ntp from a GPS 18LVM pps source. The others are synced from that machine using chrony. Almost all of the systems have a very strange oscillation in them, with a time scale of about 1.5 hours. On the ntp system, this oscillation in the offset has an amplitude of about 2-3 usec., while on the others, which use chrony, the oscillation is about 20 usec. The periods are roughly the same ( within about 10%) on all the systems. These are especially obvious in the clock rates which are set by chrony, such that the rates have oscillation of about .5 PPM . To add to the bizareness, the real time clocks, which chrony also monitors, also has oscillations in the rate chrony derives for the rtc. On some of the machines the rtc oscillations are in phase with the rate oscillations of the system, and on some they are out of phase. Now, if the rtc were itself a perfect clock, and if the rate oscillations in the system clock were due to some instability in the chrony or ntp algorithm, then you would expect to see the rtc oscillation be exactly the same size as the system oscillation, out of phase and the same amplitude. But most are in phase and all have amplitudes 2-10 times larger than the oscillation in the system. (To see the data, see www.theory.physics.ubc.ca/chrony/chrony.html) Does anyone have the ghost of a clue as to what could be going on here? Note that exactly the same kind of oscillations can be seen in the ntp offset on the string computer, but with a period about 10-20% smaller than on the others, and an amplitude about 10 times smaller. What it looks like is that both the chrony and the ntp algorithms are acting like amplifiers, with a huge peak Q peak at around a frequency of 1.5hr. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
