Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
Dennis Hilberg, Jr. wrote: [] The GPS time is not very accurate anyway, and can vary wildly, probably depending on the device, so don't expect perfect offsets. On my Garmin GPS 18 LVC, I use 0.190 which gets it in the ballpark, but can randomly jump +16ms to -10ms at any time. With a good view of the sky, the GPS time should be within a microsecond. The fact that you have a 0.2s offset suggests you are synching to the trailing edge of the PPS signal and not the leading edge. Is that possible? Have you checked the polarity, and the flag2 setting? Cheers, David ___ 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)
David L. Mills wrote: 5. This flap about the speed of convergence has become silly. Most of us are less concerned about squeezing to the low microseconds in four Have you done the market surveys to confirm this? I don't have the resources or time to do that, but my impression from the sort of questions that appear on this newsgroup is that most IT managers and turnkey system developers who want better than 100ms clock accuracy want one or both of: - fast convergence (small compared with overall bootup time) - a a common case, these days, is that they are not allowed to process financial transactions until convergence is complete; - strict monotonicity. It may well be that most users don't need better than 100ms, but those users don't care about long term stability, and their long term may be an 8 hour shift. (My interest in NTP is more theoretical, as I work in an industry sector that, whilst it deals with timestamped data, those timestamps are often a minute or two out (and are added by equipment that is out of our control), but I do notice the sorts of questions that keep coming up time and time again.) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
Dennis Hilberg, Jr. [EMAIL PROTECTED] writes: Jason wrote: All, I could be wrong here, but it seems to me that your ntpd is having a hard time finding out the actual time, as your only source of time is nearly 2 seconds off and varies wildly (GPS time does that, although not usually by No GPS NMEA should not do that. The length of the sentence is almost fixed length, so the timing on it should vary by perhaps a few msec, as you found, certainly not by seconds. It sounds like you have troubles. You could try using minicom ( assuming you are on Linux) to look at the output on the serial port. that much), and you have nothing else to go by. The PPS is probably not any good unless it's within a second as ntpd would have no idea which second the PPS is ticking, which might be why you mention the PPS's reach value will increase when the GPS time offset gets under one second. The GPS sentence should certainly be able to pull you into the second range very easily. Anyway use some serial port terminal program to read what the gps is sending and how often. (Remember at 4800Bd, it takes about 2 msec to send each character. The GPS time is not very accurate anyway, and can vary wildly, probably depending on the device, so don't expect perfect offsets. On my Garmin GPS 18 LVC, I use 0.190 which gets it in the ballpark, but can randomly jump +16ms to -10ms at any time. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Unruh wrote: David L. Mills [EMAIL PROTECTED] writes: You might not have noticed a couple of crucial issues in the clock filter code. I did notice them all. Thus my caveate. However throwing away 80% of the precious data you have seems excessive. But it isn't really. It would be if there were no correlation between the delay and the error, but there is a correlation. If the sampling were completely random, then you would want to use all of the samples to determine the correct offset, by averaging or some such method. But since the error in the sample is correlated to the size of the delay, using samples with greater delay and thus greater error just increases the error of the final result, not lessens it. Since the clocks involved also slew between samples, we want to use the newest sample with the smallest delay. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
David L. Mills [EMAIL PROTECTED] writes: Root, You could have saved a lot of time sweating the code if you looked at the briefings. See especially the before and after time series and note the 10 dB improvement in S/N. I am sorry, but looking at the code is far simpler than trying to find something in the documentation. Code I can use grep on, your documents I cannot. You might not have noticed a couple of crucial issues in the clock filter code. I did notice them all. Thus my caveate. However throwing away 80% of the precious data you have seems excessive. 1. The basic principle is to select the samples that have not been delayed in queues, leaving hopefully the ones delayed only by propagation. It's better to discard the others that can only result in less accurate measurements. 2. The filter samples are correlated only if the total span of the filter is less than the Allan intercept, generally assumed in the order of 2000 s. For poll intervals above that, the samples become uncorrelated, so fewer samples are used. 3. Never use an old sample, only new onese. It often happens that the last used minimum delay sample is older than the most recent sample. The result is that the filter can toss out up to seven samples before finding a new candidate. The clock discipline loop is specifically designed to deal with that, which is one reason the time constant is larger than you might like. Dave root wrote: OK, having looked at the code, I see what it is doing. It essentially takes the measurement with the shortest delay in the past 8 measurements. If that measurement happens to be the current one, it is actually used in the clock loop. (Yes, I know this characterisation of the clock filter is cruder than reality). This makes the smaller variance of chrony even more impressive, since in my tests, evey single measurement of offset was used to calculate the variance in the case of chrony, while for ntp, only those smallest values as reported in peerstats were used. This also explains why the roundtrip variance in ntp was so much better than chrony's. snip ___ 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)
Root, Right; 5 microseconds per timer interrupt at 100 Hz is 0.5 ms/s. That was the original Unix kernel value. Dave root wrote: David L. Mills [EMAIL PROTECTED] writes: snip ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Q: Disabling 11 minute mode
On Tuesday, January 22, 2008 at 23:13:22 +, Dean S. Messing wrote: do adjtimex -p and look at the status: value. If it's odd, (LSB==1) then your kernel is in 11 minute mode. Not exactly: bit #0 set means your kernel is in PLL mode. That's bit #6 unset that means eleven-minutes mode. The kernel does not always enter in both modes together. Serge. -- Serge point Bets arobase laposte point net ___ 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)
Petri Kaukasoina wrote: Basically, it stepped time with ntpdate, slept 100 seconds and stepped time again with ntpdate. From the time adjustment, the script calculated the drift value and put that to the drift file. Again, the time offset always stays below 1 ms. That has quite a lot of similarity with what ntpd itself does if it is cold started with iburst. The only big difference is that it uses 900, rather than 100 seconds. I don't know if that is the same 900 as controlled by tinker stepout, but, even if it is, the side effect on stepout's would probably be undesirable. To cold start you need to delete the drift file, or not configure it. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Q: Disabling 11 minute mode
Serge Bets wrote: On Tuesday, January 22, 2008 at 19:02:23 +, Dean S. Messing wrote: Is it possible to disable 11 minute mode from ntp.conf? No. You have to tweak the kernel. If you have the PPSkit: | $ echo 0 /proc/sys/kernel/time/rtc_update Otherwise you have to patch time.c in the kernel. Dead easy, just a matter of commenting out a line or two. I'm so patching all my kernels, reading and writing the RTC exclusively with hwclock 2.31, and am getting a far better accuracy. The main purpose of an RTC is to initialise the system time at powerup, isn't it? Most people startup in the morning at around half a second of the true time, and later ntpd has to step this to UTC. I routinely startup at some low milliseconds of the true time, offset quickly slewed. My last step event was years ago. Thanks Serge. I looked up PPSkit. Looks good, but I'm going to have to learn how to patch the Fedora kernel to install PPSkit. But I'm discovering that I have rather deeper problems on my machine (a Dell 490 Precision). Using adjtimex --compare to track the drift between system and cmos clock (ntpd not running), I see that the RTC is behaving _very_ strangely. It will begin to return screwy values after several hours of doing adjtimex --compare and then get to the point where hwclcok --show hangs. So my desire to turn off 11 minute mode is mute when ntp is running is mute. For your amusement, here's a snippet of the output of adjtime --compare with an interval of 60 seconds: 1200982902 0.001784 -2.0 10001 3929312 10001 4060301 1200982962 0.0017920.1 10001 3929312 10001 3920719 1200983022 0.0020514.3 10001 3929312 10001 3646240 1200983082 0.001828 -3.7 10001 3929312 10001 4173062 1200983142 0.001756 -1.2 10001 3929312 10001 4007957 1200983202 0.0020254.5 10001 3926656 10001 3632906 1200983261 0.500370 8305.8 10001 39262889918 3549307 120098328140.001689 658355.3 10001 39262883418301130 120098334140.0019314.0 10001 3926288 10001 3661966 120098340734.001894 -10.6 10001 3926288 11001 3966652 120098346140.0016465.9 10001 39262889001 4197121 120098352140.0018904.1 10001 3926288 10001 3659882 120098360912.001763 -48.8 10001 3924640 14668 1878649 120098364140.001606 44.0 10001 39246405334 6280787 1200983741 0.001726 -64.7 10001 3924640 16668 1609118 120098376140.001911 69.8 10001 39246403334 5907090 120098382140.001553 -6.0 10001 3924640 10001 4315525 1200983921 0.001748 -63.4 10001 3924640 16668 1527086 120098394140.001894 69.1 10001 39246403334 5949798 120098400140.001554 -5.7 10001 3924640 10001 4295994 1200984101 0.001700 -64.2 10001 3921488 16668 1577580 1200984161 0.001291 -6.8 10001 3921104 10001 4367718 1200984221 0.0015324.0 10001 3921104 10001 3657823 1200984275 6.001806 14.6 10001 39211049001 3621886 120098430140.001722 55.3 10001 39203684334 6196568 120098436140.0019744.2 10001 3920368 10001 3645108 120098442734.001868 -11.8 10001 3920368 11001 4036253 120098448140.0016796.8 10001 39203689001 4126878 Things got so bad that the output eventually became: 199345540 1001658696.064552 1592732.9 10001 3879376 -5926 1725431 199345717 1001658600.500585 -1592732.8 10001 3879376 25928 6027853 199345718 1001658696.023830 1592054.1 10001 3879376 -5919335126 199345896 1001658600.500586 -1592054.1 10001 3879376 25922868985 199345897 1001658696.045414 1592413.8 10001 3879376 -5923 2975047 Before it went crazy, it had run smoothly for 5 or 6 hours. When I rebooted into the BIOS and looked at the RTC it was off by several years. This has now happened thrice, but only when adjtimex is running in the compare mode for long periods. I have no idea what this means. The cmos battery does not appear to be the problem since, after a reboot, the RTC remains at proper time indefinitely (modulo drift), unless and until I run adjtimex --compare for several hours. Anyway, thanks for the info. on 11 minute mode. Wish I could fix my RTC problem Dean ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Brian Utterback [EMAIL PROTECTED] writes: Unruh wrote: David L. Mills [EMAIL PROTECTED] writes: You might not have noticed a couple of crucial issues in the clock filter code. I did notice them all. Thus my caveate. However throwing away 80% of the precious data you have seems excessive. But it isn't really. It would be if there were no correlation between the delay and the error, but there is a correlation. If the sampling were completely random, then you would want to use all of the samples to determine the correct offset, by averaging or some such method. But since the error in the sample is correlated to the size of the delay, using samples with greater delay and thus greater error just increases the error of the final result, not lessens it. Since the clocks involved also slew between samples, we want to use the newest sample with the smallest delay. I understand the reason for the decision, I am just very uncomfortable with it. Since part of the design goals of ntp are not to overload the net ( by which it seems to mean one packet ever minute is too much) it seems pretty cavalier to then throw away something like 80% of the data you get. While I certainly understant the design decision, It is not at all clear that your model is correct. One model is that the the excess delay is always on the outgoing leg. Another is that it is random-- sometimes out, sometimes in, sometimes both. This latter case IS statistical, and a very very brief test with ntp ( in which I printed out p_offset and p_del as well as what ntp does, so I can directly compare what happens) seems to indicate that the noise introduced by delay on the one system I happen to have tested this on is statistical, not biased. Clearly a longer delay data point is worth less, but it is surely not worthless as ntp assumes. This becomes especially critical if the clock drift jumps around, because it is obviously impossible to see that if you are not looking. Note that the situation can arise that the one can wait many more than 8 samples for another one. Say sample i is a good one. and remains the best for the next 7 tries. Sample i+7 is slightly worse than sample i and thus it is not picked as it comes in. But the next i samples are all worse than it. Thus it remains the filtered one, but is never used because it was not the best when it came in. This situation could keep going for a long time, meaning that ntp suddenly has no data to do anything with for many many poll intervals. Surely using sample i+7 is far better than not using any data for that length of time. And this could happen again. Now, since the delays are presumably random variables, the chances of this happening are not great ( although under a condition of gradually worsening network the chances are not that small), but since one is running ntp for millions or billions of samples, the chances of this happening sometime becomes large. Another question, why was clock_phi chosen as 15PPM? Is this a crude attempt to disable this filtering once the time period becomes comparable to the Allan time? (ie, with a poll interval of 6s, the current sample will always be the one chosen.) Is there some theory behind this choice of 15PPM and for the way in which the metric is aged, or was it just a guess. I would expect that the correct figure would depend on the actual delay spectrum of the connection. ___ 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)
David Woolley wrote: David L. Mills wrote: 5. This flap about the speed of convergence has become silly. Most of us are less concerned about squeezing to the low microseconds in four Have you done the market surveys to confirm this? I don't have the resources or time to do that, but my impression from the sort of questions that appear on this newsgroup is that most IT managers and turnkey system developers who want better than 100ms clock accuracy want one or both of: - fast convergence (small compared with overall bootup time) - a a common case, these days, is that they are not allowed to process financial transactions until convergence is complete; - strict monotonicity. snip ISTR that time stamps on financial transactions are required to be within two seconds of the correct time. With NTP that standard is not too difficult to meet. Other applications might be far more demanding. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] strange behaviour of ntp peerstats entries.
Root, You could have saved a lot of time sweating the code if you looked at the briefings. See especially the before and after time series and note the 10 dB improvement in S/N. You might not have noticed a couple of crucial issues in the clock filter code. 1. The basic principle is to select the samples that have not been delayed in queues, leaving hopefully the ones delayed only by propagation. It's better to discard the others that can only result in less accurate measurements. 2. The filter samples are correlated only if the total span of the filter is less than the Allan intercept, generally assumed in the order of 2000 s. For poll intervals above that, the samples become uncorrelated, so fewer samples are used. 3. Never use an old sample, only new onese. It often happens that the last used minimum delay sample is older than the most recent sample. The result is that the filter can toss out up to seven samples before finding a new candidate. The clock discipline loop is specifically designed to deal with that, which is one reason the time constant is larger than you might like. Dave root wrote: OK, having looked at the code, I see what it is doing. It essentially takes the measurement with the shortest delay in the past 8 measurements. If that measurement happens to be the current one, it is actually used in the clock loop. (Yes, I know this characterisation of the clock filter is cruder than reality). This makes the smaller variance of chrony even more impressive, since in my tests, evey single measurement of offset was used to calculate the variance in the case of chrony, while for ntp, only those smallest values as reported in peerstats were used. This also explains why the roundtrip variance in ntp was so much better than chrony's. snip ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
How do you have your wiring done up? I found that when I just twisted the wire
together and wrapped them in electrical tape for testing, I had very bad serial
port behaviour. Doing a cat /dev/gps1 I saw a lot of garbarge in stream and
I was sometimes only seeing every third or fourth NMEA sentence. Soldering
everything together snapped everything together.
Erik.
Date: Thu, 24 Jan 2008 10:23:18 -0500
From: [EMAIL PROTECTED]
To: questions@lists.ntp.org
Subject: [ntp:questions] First attempt GPSD/PPS -NTP time server
All,
This is my first attempt to build an 'accurate' GPS-based time server.
There is no Internet connectivity, so the GPS (and it's PPS) are the
only sources of timing data.
I'm using a San Jose Navigation FV-M8 [1]. As a GPS, it works great. I
piped the PPS signal to the CTS line (gpsd-2.36 supports this) and with
a minor tweak to gpsd (until I can find the sentence to change the pulse
length), gpsd finds the pulse and hands everything off to ntpd as per
the gpsd man page [2].
Watching ntpd from 'ntpq -p' appears to work as expected. When the
offset (SHM(0), average gps) is less than 1 second, gpsd sends the
appropriate info to SHM(1) (gps pps), which ntpd uses ('ntpq -p' SHM(1)
reach changes from 0 to positive values).
Basically, I think I have the hardware set up right. However, I left it
running over night because I kept seeing the following:
# watch -n3 ntpq -p
remote refid st t when poll reach delay offset
jitter
==
*SHM(0) .GPS.0 l- 16 3770.000 1831.01
771.100
SHM(1) .GPS1. 0 l 86 16 400.0000.000
0.004
Sorry if it's line wrapped. The offset of SHM(0) will wander from less
than a second ( 1000.00) to around 8 seconds. Each time it gets close
( 1000.00) the numbers for SHM(1) start changing, which tells me it's
trying to use the PPS to pull it in tight. But, then SHM(0) will wander
off again.
What is normal? How long should it take a stand alone GPS time server
to lock in? What should I tweak to fix this? Any insight would be
appreciated.
/etc/ntp.conf appended.
Note: I tried deleting the drift file, and changing the time1 value, to
no avail. (I'm shooting in the dark with that one ;-) )
thx,
Jason.
[1] - http://www.sanav.com/gps_engine_board/FV-M8.htm
[2] - http://gpsd.berlios.de/gpsd.html
Section: Use with NTP
/etc/ntp.conf ###
[snipped commented out stuff]
# Added 20080122 to sync to GPS
server 127.127.28.0 minpoll 4 maxpoll 4
#fudge 127.127.28.0 time1 0.420 refid GPS
fudge 127.127.28.0 time1 0.320 refid GPS
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid GPS1
[snipped out more comments]
# you should not need to modify the following paths
driftfile /var/lib/ntp/ntp.drift
[snip]
# To deny other machines from changing the
# configuration but allow localhost:
restrict default nomodify nopeer
restrict 127.0.0.1
##
___
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
Re: [ntp:questions] NTP vs chrony comparison (Was: oscillations in ntp clock synchronization)
Daivd, Well, I have done a market survey of sorts, if you can count my consulting clients. There seems general agreement that 1 ms is a good target, but there is a wide range of expecttions on how quickly that must be achieved. Actually, if the TOY chip is within 1 PPM and the downtime is less than 1000 s, convergence is essentially instantaneous. My advice to the Aegis crew was to isolate the NTP puppies on the fire control Ethernet and allow only a couple of other computers on the wire. Crony would work just fine. Here's another contribution to the market survey. There is a seismic network on the sea floor off the Washington state coast. They need a millisecond for experiments lasting months, not just 8-hour shifts, and that when the experiment boxes get rather warm. Crony might work here as well, but it would have to track large swings in temperature. Here's another one. National Public Radio (NTP) distributes almost all program media via IP and digital satellite. They don't need 1 ms, but they do need good stability in the face of highly variable transmission delays that could drive crony nuts. And another one. A transatlantic link used by Ford Motor was once a statistical multilexor that interleaved terminal keystrokes on a demand-assigned basis. Toss NTP packets in that mess and watch the huge jitter. That not only drove NTP nuts, it drove the TCP retransmission algorithm nuts, too. Seems like the market is highly fragmented. I hear you say 100 ms which I interpret as 100 milliseconds. Even 25 year old fuzzballs could to much better than that on the congested ARPAnet. Did you mean 100 microseconds? Dave David Woolley wrote: David L. Mills wrote: 5. This flap about the speed of convergence has become silly. Most of us are less concerned about squeezing to the low microseconds in four Have you done the market surveys to confirm this? I don't have the resources or time to do that, but my impression from the sort of questions that appear on this newsgroup is that most IT managers and turnkey system developers who want better than 100ms clock accuracy want one or both of: - fast convergence (small compared with overall bootup time) - a a common case, these days, is that they are not allowed to process financial transactions until convergence is complete; - strict monotonicity. It may well be that most users don't need better than 100ms, but those users don't care about long term stability, and their long term may be an 8 hour shift. (My interest in NTP is more theoretical, as I work in an industry sector that, whilst it deals with timestamped data, those timestamps are often a minute or two out (and are added by equipment that is out of our control), but I do notice the sorts of questions that keep coming up time and time again.) ___ 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)
Danny, I agree with everything you said except: Danny Mayer wrote: I agree. I don't see how it can be a specification violation. The biggest factor is how well it keeps time. A caesium clock keeps good time but you wouldn't say that it violates the specification. When we first started looking at the V4 spec for the ntp-wg, my first thought was the same as yours, namely that what happens inside a system shouldn't matter, the algorithms don't matter, only what it chimes matters. And strictly speaking, this is true. However, after reading Dave's book (Das Buch as he calls it), I realized that an important factor to the stability of the NTP network is the actual speed at which the clocks slew, i.e. the 500 PPM limit. This is largely ignored in the spec. I sent in some comments about how I thought it should be addressed but alas, my changes didn't make it in the latest versions. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
Dennis Hilberg, Jr. wrote: [] I was actually referring to the time emitted in the NMEA data (GPS time), not the PPS signal. Sorry, I should have specified that. The PPS is accurate to a microsecond, but not the GPS time. I happen to use a fudge factor of 0.190 to get the GPS time close to zero, but the PPS is of course very accurate and doesn't require any fudging. He's not using the GPS_NMEA (type 20) driver, so he has to deal with the PPS and GPS time seperately, hence SHM(0) and SHM(1). The type 20 driver uses both the PPS (if the OS supports it) and GPS time, but the offset you see in 'ntpq -p' is the PPS offset. Thanks for that clarification, Dennis. I appreciate what you mean by the GPS time. David ___ 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)
David Woolley [EMAIL PROTECTED] writes: David L. Mills wrote: The NTP discipline is basically a type-II feedback control system. Your training should recall exactly how such a loop works and how it responds to a 50-ms step. Eleven seconds after NTP comes up the mitigation You both have problems here. Dave Mills: your problem is that you haven't explained why one should continue to use a long time constant linear feedback system when a human observer can easily tell you how to get within 10 microseconds of the correct time after no more than about 3 samples. Bill Unruh: you haven't explained what real world situation this test is simulating; it is a standard doctrine that ntpd is not a substitute for good hardware and system software (e.g. you shouldn't use ntpd to get round lost clock interrupts). The real world situation that the test is run on (not simulating) is having a computer on a lan with another computer running ntp from a Garmin PPS acting as the server. It is a best case scenario, I will completely agee. I still get round trip times of msec rather than 150usec at times, the oscillators on the machines have glitches in which teh clock rate changes by 1-2PPS suddenly ( over less than 1/2 hr) and then long periods of quiescense. I have NOT tested the two in situations where there are longer paths, through many routers. I have not tested it on the road to Mandalay, or Indonesia. I have been looking at the real world response in a working system but where the network delays are minimal. Is my testing complete? Heavens no. It is one data point. Do I expect chrony to fall over on the road to Mandalay? Looking at its design, no, but experiments are the answer. algorithms present that transient to the loop and what happens afterwards conforms to the equations of control theory. Discussion about what happens at any time after that is a matter of mathematics and ntpd does conform to the mathematics as confirmed by observation and simulation. That's an indication that the equations are inappropriate in that context. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] First attempt GPSD/PPS -NTP time server
Nero Imhard [EMAIL PROTECTED] writes: David J Taylor schreef: The fact that you have a 0.2s offset suggests you are synching to the trailing edge of the PPS signal and not the leading edge. The NMEA output would be my prime suspect. It is not surprising to have an offset there. The time in an NMEA sentence doesn't tell you what time it is now, but instead it specifies the point in time that the rest of the data (e.g. position) refers to. Also, NMEA sentences lack proper time markers. It's always tricky business to get clock synchronization from NMEA alone. I would say it is impossible. The Garmin GPS 18 LVC manual explicitly mentions that emitted NMEA sentence describe the when and where of the *previous* rising edge of the PPS signal. It does not specify how long after that edge it will give you the NMEA, or even that this time will be constant. It cannot tell you since that depends completely on how you have set it up-- ie how many sentences it delivers. As mentioned if it is only the one sentence, then 180msec is not a bad estimate at 4800bd. Ie, the unit just sends out the sentences as soon as the second has occured. N ___ 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)
Brian, The 500 PPM limit in the reference implementation was originally set to match the adjtime() slew of that value, but so many kernels have been hacked adjtime that this might not even be appropriate now. The bottom line is that an update given to adjtime() should be completed before the next update. Even if it's not, the leftover is carried over to the next update. However, in order to avoid disturbing application programs that compute intervals, the slew rate should be no more than necessary. Dave Brian Utterback wrote: Danny, I agree with everything you said except: Danny Mayer wrote: I agree. I don't see how it can be a specification violation. The biggest factor is how well it keeps time. A caesium clock keeps good time but you wouldn't say that it violates the specification. When we first started looking at the V4 spec for the ntp-wg, my first thought was the same as yours, namely that what happens inside a system shouldn't matter, the algorithms don't matter, only what it chimes matters. And strictly speaking, this is true. However, after reading Dave's book (Das Buch as he calls it), I realized that an important factor to the stability of the NTP network is the actual speed at which the clocks slew, i.e. the 500 PPM limit. This is largely ignored in the spec. I sent in some comments about how I thought it should be addressed but alas, my changes didn't make it in the latest versions. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
