Re: frequency tolerance: 500
> HPET should be OK, but if you can figure out why the TSC doesn't work that > would be better. Check what clocksources are available, there might actually > multiple TSC to chose from. If I was going to chase this, I'd look at the kernel sources to see what changed. I haven't seen similar problems, but I don't have any gear with AMD chips. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: >> Again no direct experience, but TSC should be stable these days unless >> something is very much wrong with the drivers. ALso, I've seen reports >> that Ryzen TSC is unstable when certain overclocking options are >> activated. > > I am not overclocking this CPU. The TSC on Ryzen works with the nominal frequency. On certain systems that frequency is modulated, but the kernel doesn't know that until it's controlling those changes. So, while this can be used for overclocking, you can still suffer from this even when you don't overclock (or think you don't do it, but the BIOS decides it's going to switch on the "performance" preset anyway). > Why would tsc be better? Already answered in my other mail. >> Check what clocksources are available, there >> might actually multiple TSC to chose from. > > # cat /sys/devices/system/clocksource/clocksource0/available_clocksource > tsc hpet acpi_pm OK, so only one TSC. Try one of the Linux kernel mailing lists to see if there's something known about this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > udev. So, with ldattach? > rc.local Use an udev rule again, much easier and more reliable, too. >> I haven't seen one of these in person, but I believe the serial port >> for Ryzen systems is part of the SuperIO, not the chipset itself. > > We have an RS232 PCIe card. Thanks again for not mentioning which actual model. > ASRock QC5000M-ITX/PH with same gps connected very similarly. > Just not on an RS232 card but one of the serial ports of the ITX. …which ties directly into the chipset and hence has very low latency into the interrupt system. >> versions is responsible). I suspect you've been relying on some >> defaults which have changed, but that's just a guess. > > Sounds reasonable given that the situation is currently normalising > after switchign the clocksource to hpet. (from tsc) You should still figure out why TSC is not working correctly. HPET is seriously slow on any modern system and Spectre/Meltdown mitigations have only added to that. > 4800 works very well when you set it up like this: > $PGRMO,,2*75 > $PGRMO,GPRMC,1*3D > $PGRMO,GPGGA,1*20 > $PGRMC,A,42.9,100,,A,3,1,2,9,30*61 That doesn't tell me anything, I don't have that unit or something else using the same command set. But again, you really only want a single message from the GPS since ntpd doesn't look at anything but the first. And since it times with the end of the message, configuring messages that have wildly different sizes is another no-no. PPS will hide that as long as it's available. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 15:13, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >> But it was runnning on clocksource tsc. > > Again no direct experience, but TSC should be stable these days unless > something is very much wrong with the drivers. ALso, I've seen reports > that Ryzen TSC is unstable when certain overclocking options are > activated. I am not overclocking this CPU. > >> We manually switched to hpet and things started stabilising slowly. > > HPET should be OK, but if you can figure out why the TSC doesn't work > that would be better. Why would tsc be better? > Check what clocksources are available, there > might actually multiple TSC to chose from. # cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > But it was runnning on clocksource tsc. Again no direct experience, but TSC should be stable these days unless something is very much wrong with the drivers. ALso, I've seen reports that Ryzen TSC is unstable when certain overclocking options are activated. > We manually switched to hpet and things started stabilising slowly. HPET should be OK, but if you can figure out why the TSC doesn't work that would be better. Check what clocksources are available, there might actually multiple TSC to chose from. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 14:43, Achim Gratz via devel wrote: >> Same as it ever was: > > How are we supposed to know that if you don't say it? Because I was happy and documented stuff on linuxpps.org. Because no backups were made there the documentation went missing. >> Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. > > So is this a USB serial or is it an LVC model and you use a "true" > RS232C port? Pover is from USB. The rest is over RS232. Yes, we use an LVC model. > How do you create the necessary PPS device? udev. If you use a > serial device, have you set it to low_latency? rc.local > I haven't seen one of > these in person, but I believe the serial port for Ryzen systems is part > of the SuperIO, not the chipset itself. We have an RS232 PCIe card. >> When I switch the GPSses (I have two) the GPS works fine in the other >> box. So something on this box is hosed and I ruled out wiring, I guess. >> I reset the GPS configuration, I changed PPS pulse length, etc. > > What's that second system you talk about that seems to work? The firewall. ASRock QC5000M-ITX/PH with same gps connected very similarly. Just not on an RS232 card but one of the serial ports of the ITX. > versions is responsible). I suspect you've been relying on some > defaults which have changed, but that's just a guess. Sounds reasonable given that the situation is currently normalising after switchign the clocksource to hpet. (from tsc) >> refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 >> 0.260 baud 4800 > > If you left the default message configuration on, then 4800 baud is way > too slow. 4800 works very well when you set it up like this: $PGRMO,,2*75 $PGRMO,GPRMC,1*3D $PGRMO,GPGGA,1*20 $PGRMC,A,42.9,100,,A,3,1,2,9,30*61 Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: >> How is the GPS connected and how do you get the PPS in? > > Same as it ever was: How are we supposed to know that if you don't say it? > Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. So is this a USB serial or is it an LVC model and you use a "true" RS232C port? How do you create the necessary PPS device? If you use a serial device, have you set it to low_latency? I haven't seen one of these in person, but I believe the serial port for Ryzen systems is part of the SuperIO, not the chipset itself. There might be some BIOS settings you need to tweak to get optimal performance. > When I switch the GPSses (I have two) the GPS works fine in the other > box. So something on this box is hosed and I ruled out wiring, I guess. > I reset the GPS configuration, I changed PPS pulse length, etc. What's that second system you talk about that seems to work? > And I did not change anythign when this started, I simply rebooted into > a different kernel. Well, forget about the kernel for a moment unless you can actually name the exact version transition that broke things for you (in which case you would need to figure out which of the changes between those two versions is responsible). I suspect you've been relying on some defaults which have changed, but that's just a guess. > refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 > 0.260 baud 4800 If you left the default message configuration on, then 4800 baud is way too slow. I don't think that particular model has any problems with the highest configurable baud rate (should be 38400 I think). Also, just configure the one message you want ntpd to accept (most likely $GPRMC as the Garmin doesn't have $GPZDA) and tell ntpd to only use that (mode 1 or, if you increased the baudrate to 38.4k, mode 49). Reading multiple messages into ntpd is useless, it only ever looks at the first one anyway. Your time1 configuration corresponds to 60ns, so it is almost certainly useless at this point. I would expect around 500µs to 1ms for this parameter. The time2 value is likely way too low for your current setup, but could be correct for a higher baudrate. Last but not least if you get the PPS in via a serial line, you need to configure ntpd to look for the "clear" edge (flag2 1). If you are unsure, install the pps-utils package or whatever your distribution calls it and use ppstest to see which edge is closer to the second. Play around with the PPS width to see if it moves in the right direction to be sure. Now, sometimes the clear edge has a lot more jitter than assert if the hardware has to poll for that edge instead of using interrupts. If so, you can try to reduce the PPS pulse width to the minimum that still registers correctly, switch to the other edge and then adjust the time1 value by the PPS pulse width. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 13:37, Udo van den Heuvel via devel wrote: >> As long as the time is that much off, yes it'll do that. > > Time is not that much off. > It also happens when I sync the clock manually and then start ntpd. > >> Does anything in the boot log complain about unstable clock sources and >> or switching between different ones? > > It switches only during bootup. > Nothing unstable (?) to be seen. But it was runnning on clocksource tsc. We manually switched to hpet and things started stabilising slowly. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 13:16, Achim Gratz via devel wrote: >> 186 is not sensible. >> When I set it to 0.000 it still goes way up. > > As long as the time is that much off, yes it'll do that. Time is not that much off. It also happens when I sync the clock manually and then start ntpd. > Does anything in the boot log complain about unstable clock sources and > or switching between different ones? It switches only during bootup. Nothing unstable (?) to be seen. > How is the GPS connected and how do you get the PPS in? Same as it ever was: Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. >> Or we get this absurd PLL frequency. (4.19.23). > > Same thing most likely. Same thing as what? >> Of course this might just be timing, depending on how soon after bootup, >> at what spot in the PPS cycle ntpd came online. > > No. It's a problem with how you set up your GPS. It's registers with a > too large offset. When I switch the GPSses (I have two) the GPS works fine in the other box. So something on this box is hosed and I ruled out wiring, I guess. I reset the GPS configuration, I changed PPS pulse length, etc. And I did not change anythign when this started, I simply rebooted into a different kernel. >> But I am not yet convinced of that. >> Restarting leads to same results. > > Yes, as long as you don't correct the setup What is not correct? > over and over. Care to show your ntp.conf next time? # grep -v ^# /etc/ntp.conf |grep -v ^$ driftfile /var/lib/ntp/drift restrict default nomodify nopeer noquery restrict -6 default nomodify nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict 192.168.10.0 mask 255.255.255.0 nomodify refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 0.260 baud 4800 disable monitor server 192.168.10.98 minpoll 4 iburst server fd01:c1a8:a01:2::1 server ntp.xs4all.nl server ntp2.xs4all.nl server ntp0.nl.net server ntp2.nl.net server keetweej.vanheusden.com server ntp.nmi.nl includefile /etc/ntp/crypto/pw keys /etc/ntp/keys statsdir /var/log/ntp/ Not so complex Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > On 31-03-19 12:34, Achim Gratz via devel wrote: >>> This behaviour is not normal. >> >> Uh, that is reporting from an ntpd that has just started and hasn't > > One that starts counting again after being up for a little while. > >> collected many statistics. So the only way it can get a PLL frequency >> of 186ppm will be if that value is stored in the drift file. Do you >> have one (usually found somewhere in /var/lib/ntp/), does it contain a >> sensible value? > > 186 is not sensible. > When I set it to 0.000 it still goes way up. As long as the time is that much off, yes it'll do that. >> If so, this doesn't seem to be a rasPi, what is it? > > No, x86_64 with AMD Ryzen. Does anything in the boot log complain about unstable clock sources and or switching between different ones? >> Also, just mumbling about "different behaviour" without showing at >> least one difference isn#t really going to get you much help. > > We either get a pps that is ~250ms off (4.19.30 etc) with ntpd going > backa nd forth between the gps and remote clocks. Well, then set the GPS to "noselect" sync the box to some NTP server that has good time and fix up the time1 (without PPS) and time2 (with PPS) values. The time offset reported by ntpq in both cases (w/ and w/o PPS) should be below the reported jitter and close to zero. How is the GPS connected and how do you get the PPS in? > Or we get this absurd PLL frequency. (4.19.23). Same thing most likely. > Of course this might just be timing, depending on how soon after bootup, > at what spot in the PPS cycle ntpd came online. No. It's a problem with how you set up your GPS. It's registers with a too large offset. > But I am not yet convinced of that. > Restarting leads to same results. Yes, as long as you don't correct the setup it's gonna do the same thing over and over. Care to show your ntp.conf next time? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 12:34, Achim Gratz via devel wrote: >> This behaviour is not normal. > > Uh, that is reporting from an ntpd that has just started and hasn't One that starts counting again after being up for a little while. > collected many statistics. So the only way it can get a PLL frequency > of 186ppm will be if that value is stored in the drift file. Do you > have one (usually found somewhere in /var/lib/ntp/), does it contain a > sensible value? 186 is not sensible. When I set it to 0.000 it still goes way up. >> is it software? >> >> rebooted again to 4.19.23 which shows different behaviour than 4.19.30 >> and 32. > > What are these version numbers, Linux kernel? Of course. > If so, this doesn't seem > to be a rasPi, what is it? No, x86_64 with AMD Ryzen. > Also, just mumbling about "different > behaviour" without showing at least one difference isn#t really going to > get you much help. We either get a pps that is ~250ms off (4.19.30 etc) with ntpd going backa nd forth between the gps and remote clocks. Or we get this absurd PLL frequency. (4.19.23). Of course this might just be timing, depending on how soon after bootup, at what spot in the PPS cycle ntpd came online. But I am not yet convinced of that. Restarting leads to same results. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > When simply rebooting? Again, the normally the clock is either set from RTC and then ntpdate or ntpd with that allowed to step it. > # ntpq -c kerninfo -pn > associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, > pll offset:25.623 > pll frequency: 186.259 > maximum error: 0.10146 > estimated error: 0.00972 > kernel status: pll nano > pll time constant: 6 > precision: 1e-06 > frequency tolerance: 500 > pps frequency: 0 > pps stability: 0 > pps jitter:0 > calibration interval 0 > calibration cycles:0 > jitter exceeded: 0 > stability exceeded:0 > calibration errors:0 > remote refid st t when poll > reach delay offset jitter > === > xNMEA(0) .GPS.0 l- 641 > 0. 48.1256 0. > x192.168.10.98 .GPS.1 u 35 643 > 0.2999 27.4933 4.5941 > fd00:c0a8:a00:1::1 .GPS.1 u7 641 > 0.3935 55.0019 0. > 2001:888:0:7::2 193.67.79.2022 u5 641 > 14.9598 60.2632 0. > 2001:888:0:7::22193.67.79.2022 u 60 641 > 15.5002 23.9193 0. > 193.67.79.202 .STEP. 16 u- 1280 > 0. 0. 0.0002 > 193.79.237.14 .STEP. 16 u- 1280 > 0. 0. 0.0002 > 185.31.230.94 .STEP. 16 u- 1280 > 0. 0. 0.0002 > 134.221.205.12 .STEP. 16 u- 1280 > 0. 0. 0.0002 > > > This behaviour is not normal. Uh, that is reporting from an ntpd that has just started and hasn't collected many statistics. So the only way it can get a PLL frequency of 186ppm will be if that value is stored in the drift file. Do you have one (usually found somewhere in /var/lib/ntp/), does it contain a sensible value? > is it software? > > rebooted again to 4.19.23 which shows different behaviour than 4.19.30 > and 32. What are these version numbers, Linux kernel? If so, this doesn't seem to be a rasPi, what is it? Also, just mumbling about "different behaviour" without showing at least one difference isn#t really going to get you much help. So what does your ntp.conf look like, how is the GPS connected, have you actually provided correct time1 (and perhaps time2 if you're using PPS) values for it? Etc.pp. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 11:21, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >>> How close are you to "true" time when you start the ntpd? >> >> Within 100's of ms if not better. > > If you are really that far off when you start ntpd, When simply rebooting? # ntpq -c kerninfo -pn associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, pll offset:25.623 pll frequency: 186.259 maximum error: 0.10146 estimated error: 0.00972 kernel status: pll nano pll time constant: 6 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter:0 calibration interval 0 calibration cycles:0 jitter exceeded: 0 stability exceeded:0 calibration errors:0 remote refid st t when poll reach delay offset jitter === xNMEA(0) .GPS.0 l- 64 1 0. 48.1256 0. x192.168.10.98 .GPS.1 u 35 64 3 0.2999 27.4933 4.5941 fd00:c0a8:a00:1::1 .GPS.1 u7 64 1 0.3935 55.0019 0. 2001:888:0:7::2 193.67.79.2022 u5 64 1 14.9598 60.2632 0. 2001:888:0:7::22193.67.79.2022 u 60 64 1 15.5002 23.9193 0. 193.67.79.202 .STEP. 16 u- 128 0 0. 0. 0.0002 193.79.237.14 .STEP. 16 u- 128 0 0. 0. 0.0002 185.31.230.94 .STEP. 16 u- 128 0 0. 0. 0.0002 134.221.205.12 .STEP. 16 u- 128 0 0. 0. 0.0002 This behaviour is not normal. is it software? rebooted again to 4.19.23 which shows different behaviour than 4.19.30 and 32. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: >> How close are you to "true" time when you start the ntpd? > > Within 100's of ms if not better. If you are really that far off when you start ntpd, it can very easily peg at the 500ppm mark. That 500ppm limit means the clock will drift no more than 0.5ms/s, so to correct for 100ms you'd need 200s for the correction to take place and then you are still left with finding the correct clock drift, which can easily take another hour after such a large disturbance. That's why ntpd usually steps the clock when it starts up the first time, which should bring it into the low single-digit ms range. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 28-03-19 20:45, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >> On 27-03-19 17:39, Udo van den Heuvel wrote: >>> Why would ntpsec after a reboot move the pll to values at the edge of >>> what I am graphing using mrtg? >>> Before the reboot the pll values were closer to 0. > > Are you manipulating the time while ntpd is already started up? No. Only ntpd might. > How > close are you to "true" time when you start the ntpd? Within 100's of ms if not better. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > On 27-03-19 17:39, Udo van den Heuvel wrote: >> Why would ntpsec after a reboot move the pll to values at the edge of >> what I am graphing using mrtg? >> Before the reboot the pll values were closer to 0. Are you manipulating the time while ntpd is already started up? How close are you to "true" time when you start the ntpd? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
>> Try deleting your drift file and restarting ntpd. > Already tried that. Humm. Would you please try again and send me the log file. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 28-03-19 09:05, Hal Murray wrote: >> How to proceed to normalize the offset? > > Try deleting your drift file and restarting ntpd. Already tried that. > There is an old bug in this area. Nobody has any ideas on what is going > wrong. Hmm. :-/ Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
> pll frequency: 500 > frequency tolerance: 500 > How to proceed to normalize the offset? Try deleting your drift file and restarting ntpd. There is an old bug in this area. Nobody has any ideas on what is going wrong. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 27-03-19 17:39, Udo van den Heuvel wrote: > Why would ntpsec after a reboot move the pll to values at the edge of > what I am graphing using mrtg? > Before the reboot the pll values were closer to 0. After updating to latest git: # ntpq -c kerninfo associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, pll offset:96.4811 pll frequency: 500 maximum error: 0.121677 estimated error: 2.2e-05 kernel status: pll nano pll time constant: 6 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter:0 calibration interval 0 calibration cycles:0 jitter exceeded: 0 stability exceeded:0 calibration errors:0 How to proceed to normalize the offset? Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Yo Udo! On Wed, 27 Mar 2019 17:39:10 +0100 Udo van den Heuvel via devel wrote: > Why would ntpsec after a reboot move the pll to values at the edge of > what I am graphing using mrtg? I'd love to have someone take a hard look at ntpd startup behavior. Lot's of odd things going on then. > Before the reboot the pll values were closer to 0. Before the reboot the PLL in ntpd and the PLL in the kernel are nicely settled out and converged. After a reboot all state is lost (except the drift in the drift file). Plus the RTC was probably not accurate, so the system time is now off. ntpd has to pull the system time to the correct value, causing the ntpd and kernel PLLs to get pulled off center. When the system time is about back to the right place, then the PLLs need to be adjusted back to the right place. Then add in that the jitter computation in ntpd sprays noise all over. So it takes a while to get back to stable. The problem is that the optimal process to do the initial convergence is not the same as the process to hold the system steady. But ntpd only has the one, hold steady, as its algorithm. Plus the -g thing. This problem comes up all the time with oscillators run by time-nuts. Their solution is simple: keep everything stable (temp, humidity, voltage) and never reboot. Maybe ntpd could save more state before a reboot. Maybe ntpd could use a different algorithm on reboot. Maybe ntpd could calculate jitter better. Maybe ntpd could... ? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgp_XTtSk9ldh.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
frequency tolerance: 500
Hello, Why would ntpsec after a reboot move the pll to values at the edge of what I am graphing using mrtg? Before the reboot the pll values were closer to 0. ntpq> kerninfo associd=0 status=0428 leap_none, sync_uhf_radio, 2 events, no_sys_peer, pll offset:92.1357 pll frequency: 500 maximum error: 0.127775 estimated error: 7e-06 kernel status: pll nano pll time constant: 6 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter:0 calibration interval 0 calibration cycles:0 jitter exceeded: 0 stability exceeded:0 calibration errors:0 ntpq> Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
