Re: [time-nuts] x86 CPU Timekeeping and clock generation
On Wed, 6 Jan 2021 12:06:35 -0800, you wrote: >14.31818 MHz is 4x the NTSC colorburst frequency (~3.58 MHz). It is also >3x the original PC CPU clock frequency (~4.77 MHz). And many years ago, when Never Twice the Same Color was new, a radio ham in Manhatten wass working 80-meter CW* running a kilowatt nor far from a poorly-shielded video encoder and caused coast-to-coast TVI! Fortunately there were enough Techs who could read his callsign in the interference... *3580? -- Gary Woods O- K2AHC Public keys at home.earthlink.net/~garygarlic, or get 0x1D64A93D via keyserver fingerprint = E2 6F 50 93 7B C7 F3 CA 1F 8B 3C C0 B0 28 68 -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Tom, Consider that the RTC clock will be operating of a battery when no power is applied. For the power used, it's actually quite impressively good. Then, the other clocks is selected for various other properties, but even with quality brands, we would consider them very cheap and of dubious quality. This remains a fact of life. It is actually despite that which things like NTP works fairly well. There is additional hurdles in scheduling, operating systems, and stuff of of that sort which creates additional challenges. Improving clock to "Stratum 3" / SEC quality 4.6 ppm clocks (typically a TCXO today) would not offset price too much for quality gear, but be a significant step better. I will however not hold my breath to see TCXO and OCXO options to computer clocks. I would be very happy if it would take 5 MHz or 10 MHz external reference. Toss in a PPS input and it's fantastic. We end up to frankenstein that, or build dedicated hardware. For the commercial side, we do build our hardware. It's fun work. Cheers, Magnus On 2021-01-07 01:06, Tom Holmes wrote: > Thanks to Chris, Magnus, and Trent for clearing > things up. Never would have expected going to the > effort of putting in a cheap clock, only to use it > very little. > > Who knows what evil lurks in the minds of > engineers? And I am one! > > Tom Holmes, N8ZM > > -Original Message- > From: time-nuts > On Behalf Of Trent Piepho > Sent: Wednesday, January 06, 2021 6:36 PM > To: Discussion of precise time and frequency > measurement > Subject: Re: [time-nuts] x86 CPU Timekeeping and > clock generation > > On Wed, Jan 6, 2021 at 6:26 AM Tom Holmes > wrote: >> Am I missing something or maybe I don't > understand >> the situation , but I am under the impression > that >> the RTC has it's own battery and crystal > unrelated >> to the processor clock. Seems like in that case, >> the 24 MHz won't have any effect on the >> timekeeping drift. > It was like that, but the days of external RTC > chips, e.g. from > Dallas, are largely over. PC now have it > integrated into the chipset. > Though it still has a power source and 32.768kHz > xtal of its own. > > In the embedded SoC world of phones, Raspberry > PIs, and the OP's > Tinkerboard, there would virtually always be an > RTC available in the > SoC with the CPU, or in the PMIC, or in both. > This would usually have > its own 32.768kHz xtal, but often there is an > option to reduce the BoM > and use an internal RC oscillator instead of an > external xtal or clock > signal, at greatly reduced accuracy. > > The 32k xtal isn't for timekeeping accuracy, but > for power savings. > In the lowest power modes the main PLLs will be > shut down. Certain > parts of the SoC will still be able to run using > the 32kHz clock > domain and a low power output from the PMIC. > > Linux doesn't use the RTC as the system clock. > During boot, the > kernel will usually set the system time from the > RTC, and then the RTC > doesn't get used much, if at all. There is a mode > where the system > time is periodically copied back into the RTC, > which can be enabled > with NTP. And software like chrony has the > ability to manage the RTC > and keep it in sync more intelligently, though I > don't think any > distro uses this by default. > > There are a number of sources that Linux can use > as the system clock. > An on x86 system, it would usually be tsc, hpet, > and acpi_pm. On an > ARM board, arch_sys_counter. The kernel > subsystems for RTCs and for > clocksources are totally separate and the RTC, > e.g. rtc-cmos, isn't a > clocksource. > > Using adjtimex, it's possible to see what the > current kernel > parameters are for clock adjustment. The > frequency adjustment would > need to be zero. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_l > ists.febo.com > and follow the instructions there. > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
thol...@woh.rr.com said: > Thanks to Chris, Magnus, and Trent for clearing things up. Never would have > expected going to the effort of putting in a cheap clock, only to use it very > little. The frequency of your clock determines the granularity of a simple/quick read-the-clock operation. If you have a TSC and use it for timekeeping, you can easily get ns level results quickly and cleanly. With something like a RTC/TOY/CMOS clock you get much reduced granularity. The basic clock is only good to a second. Most of them had some mechanism to generate an interrupt every N ms. That was long used by the scheduler and for timekeeping. Then somebody used the TSC to interpolate between scheduler ticks. Then somebody did all the timekeeping from the TSC. Many years ago, I was graphing ntpd's drift vs temperature. I thought the kernel was using the TSC for timekeeping. My graphs got much cleaner when I moved the temperature probe from the CPU crystal over to the CMOS clock crystal. Many years ago. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Thanks to Chris, Magnus, and Trent for clearing things up. Never would have expected going to the effort of putting in a cheap clock, only to use it very little. Who knows what evil lurks in the minds of engineers? And I am one! Tom Holmes, N8ZM -Original Message- From: time-nuts On Behalf Of Trent Piepho Sent: Wednesday, January 06, 2021 6:36 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] x86 CPU Timekeeping and clock generation On Wed, Jan 6, 2021 at 6:26 AM Tom Holmes wrote: > > Am I missing something or maybe I don't understand > the situation , but I am under the impression that > the RTC has it's own battery and crystal unrelated > to the processor clock. Seems like in that case, > the 24 MHz won't have any effect on the > timekeeping drift. It was like that, but the days of external RTC chips, e.g. from Dallas, are largely over. PC now have it integrated into the chipset. Though it still has a power source and 32.768kHz xtal of its own. In the embedded SoC world of phones, Raspberry PIs, and the OP's Tinkerboard, there would virtually always be an RTC available in the SoC with the CPU, or in the PMIC, or in both. This would usually have its own 32.768kHz xtal, but often there is an option to reduce the BoM and use an internal RC oscillator instead of an external xtal or clock signal, at greatly reduced accuracy. The 32k xtal isn't for timekeeping accuracy, but for power savings. In the lowest power modes the main PLLs will be shut down. Certain parts of the SoC will still be able to run using the 32kHz clock domain and a low power output from the PMIC. Linux doesn't use the RTC as the system clock. During boot, the kernel will usually set the system time from the RTC, and then the RTC doesn't get used much, if at all. There is a mode where the system time is periodically copied back into the RTC, which can be enabled with NTP. And software like chrony has the ability to manage the RTC and keep it in sync more intelligently, though I don't think any distro uses this by default. There are a number of sources that Linux can use as the system clock. An on x86 system, it would usually be tsc, hpet, and acpi_pm. On an ARM board, arch_sys_counter. The kernel subsystems for RTCs and for clocksources are totally separate and the RTC, e.g. rtc-cmos, isn't a clocksource. Using adjtimex, it's possible to see what the current kernel parameters are for clock adjustment. The frequency adjustment would need to be zero. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_l ists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
On Wed, Jan 6, 2021 at 6:26 AM Tom Holmes wrote: > > Am I missing something or maybe I don't understand > the situation , but I am under the impression that > the RTC has it's own battery and crystal unrelated > to the processor clock. Seems like in that case, > the 24 MHz won't have any effect on the > timekeeping drift. It was like that, but the days of external RTC chips, e.g. from Dallas, are largely over. PC now have it integrated into the chipset. Though it still has a power source and 32.768kHz xtal of its own. In the embedded SoC world of phones, Raspberry PIs, and the OP's Tinkerboard, there would virtually always be an RTC available in the SoC with the CPU, or in the PMIC, or in both. This would usually have its own 32.768kHz xtal, but often there is an option to reduce the BoM and use an internal RC oscillator instead of an external xtal or clock signal, at greatly reduced accuracy. The 32k xtal isn't for timekeeping accuracy, but for power savings. In the lowest power modes the main PLLs will be shut down. Certain parts of the SoC will still be able to run using the 32kHz clock domain and a low power output from the PMIC. Linux doesn't use the RTC as the system clock. During boot, the kernel will usually set the system time from the RTC, and then the RTC doesn't get used much, if at all. There is a mode where the system time is periodically copied back into the RTC, which can be enabled with NTP. And software like chrony has the ability to manage the RTC and keep it in sync more intelligently, though I don't think any distro uses this by default. There are a number of sources that Linux can use as the system clock. An on x86 system, it would usually be tsc, hpet, and acpi_pm. On an ARM board, arch_sys_counter. The kernel subsystems for RTCs and for clocksources are totally separate and the RTC, e.g. rtc-cmos, isn't a clocksource. Using adjtimex, it's possible to see what the current kernel parameters are for clock adjustment. The frequency adjustment would need to be zero. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
> I have the same thought of you, but when I tried in an ARM Single Board > Computer (Asus Tinkerboard) with the same scenario (external clock and no > syncing in NTP) the same results were achieved. Not the same drift rate, but > the same behavior. This SBC dont uses TSC for timekeeping, but that you said > makes sense. Concerning this line of thought, when CPU clock varies (by > changing it because of power management) the drift should changes too, dont? > Direction and rate. I think ARM boards typically don't fuzz the CPU clock. They don't have a TSC, but there is a register that is locked to the CPU clock. [0.003076] arch_timer: cp15 timer(s) running at 19.20MHz (phys). I'd expect you could work out the integer arithmetic to translate from whatever you put into the chip to something very close to that number. If you find the right place in the kernel sources, you can see how they translate that into ns-per-tick. There will probably be some loss of precision in that area. Bottom line is that with enough work, I think you should be able to predict what will happen as accurately as you want. PCs have the clock fuzzing that will, well, fuzz any attempts at accurate clock analysis. I think typical numbers are 1/2 % round down on CPU frequency. There is also the clock measurement step. The kernel measures the TSC speed relative to some other clock rather than doing simple arithmetic to calculate it. That is another source for small errors. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Tom Van Baak writes: >If you do your kernel timekeeping in integers and modulus arithmetic you >are essentially doing cycle counting and the kernel will keep perfect >time relative to the external oscillator. So that should be the goal. >Not e-6, not e-9, not e-10, but perfect cycle counting. Consider this a >strong plea for someone in both BSD- and Linux- land to pull that off. But not all of us have masers Tom :-) Problem is, you still need fractions when NTP tells you that the X-tal is 7.1PPM off frequency. When I did timecounters, I tried a couple of things of the sort you suggest, but when I benchmarked it, a single brutal 64 bit multiply with a 32bit shift invariably ran faster, had more predictable latency, worked with any frequency the hardware happened to have and did NTP's bidding: http://phk.freebsd.dk/pubs/timecounter.pdf -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Tom, The RTC typically has a wristwatch type 32,768 kHz resonator. This is independent to the oscillator setting bus and processor speed. They have common factors in temperature and other environment, but nothing steering them together. You can have more independent oscillators, so things can drift away in "interesting" ways. A fun exercise is to take timestamps of different timestampers and locking one oscillators in reference to another. Then one can follow the variations in frequency error in easy form. Otherwise just plot the phase-difference and toss into TimeLab. Cheers, Magnus On 2021-01-06 14:16, Tom Holmes wrote: > Am I missing something or maybe I don't understand > the situation , but I am under the impression that > the RTC has it's own battery and crystal unrelated > to the processor clock. Seems like in that case, > the 24 MHz won't have any effect on the > timekeeping drift. > > Tom Holmes, N8ZM > > -Original Message- > From: time-nuts > On Behalf Of Trent Piepho > Sent: Wednesday, January 06, 2021 6:03 AM > To: Discussion of precise time and frequency > measurement > Subject: Re: [time-nuts] x86 CPU Timekeeping and > clock generation > > On Tue, Jan 5, 2021 at 9:42 PM Luiz Paulo Damaceno > wrote: >> The 24 MHz comes from an synthesizer that is > locked to an atomic clock, the >> clock of NTP server (also 24 MHz, but an > embedded board (Tinkerboard)) also >> comes from the same Atomic clock that is feeding > other synthesizer for >> generates 24 MHz to this board. > The RK3288 has some PWM generators. These are of > course also fed from > PLLs derived from the same 24 MHz input. > > So, why not produce a signal on the PWM that can > be compared to your > reference? This would tell you if the error is in > the clock > generation on the SoC or something in software > that happens afterward. > Or at least as far as the PWM clock tree overlaps > the kernel > timesource clock tree, which could be the CPU > clock but it can be > other things too. > >> The experiment is the following: 1- synchronize > the computer's clock to NTP >> server then leave it running free (no periodic > synchronization), 2 - > > NTP will set the frequency skew too, so even if it > is not doing > periodic synchronization, there may still be a > programmed frequency > skew. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_l > ists.febo.com > and follow the instructions there. > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Kasper,
> A short run here using the latest kernel gives an error of < ± 2e-10
> on 14.31818MHz hpet, and 0.5ppm on tsc.
Ah, we know that frequency well
14.31818 MHz is 4x the NTSC colorburst frequency (~3.58 MHz). It is also
3x the original PC CPU clock frequency (~4.77 MHz). And 12x an ISA bus
frequency (~1.19318 MHz). The IBM PC had clock division by 3 and 4 to
generate those frequencies. Even the laptop I'm using to type this has a
high-res timer resolution of 3.579545 MHz. [1] These magic numbers are
everywhere.
Time for a short story. About 30 years ago I was involved with the
development of the Windows NT kernel on a 64-bit machine. NT timekeeping
is pretty much like any OS timekeeping, with ticks and counters and
epochs and stuff. One of the machines had a HAL clock rate of 1.193181
MHz. So how do you set an accurate periodic interrupt timer for that
weird number?
One way is with divisions and shifts and approximations. And I see that
in your Linux code. The guiding principle is usually "close enough" is
good enough. One semi-valid excuse is "the crystal isn't accuracy enough
anyway". Another valid excuse is "NTP will take care of it", so don't worry.
This attitude is enough to make any time nut cringe. It
institutionalizes small errors, excuses rounding and truncation issues.
It's "time abuse" at the nanosecond level. And it means if you do happen
to have a perfect external clock, the OS still cannot keep correct time.
As you and OP now know well.
Anyway, the solution for the NTSC-based HAL was to use pure integers. No
shifts, no rounding, no truncation, ever. Instead modulus arithmetic was
used. You know, the N/M or N/M+R stuff that you see in a phase correct DDS.
Part of the trick was to realize that the 1.19 MHz number was 1/3rd of
the NTSC colorburst frequency. At that is not 3.579 MHz, nor 3.579545
MHz, but instead 315 / 88 MHz. The math (and history) behind NTSC is
really cool. Fun for math- and time-nuts. [2] It always boils down to
integers, vacuum tube friendly small prime factors like 2, 3, 5, 7, 11,
and 13.
If you do your kernel timekeeping in integers and modulus arithmetic you
are essentially doing cycle counting and the kernel will keep perfect
time relative to the external oscillator. So that should be the goal.
Not e-6, not e-9, not e-10, but perfect cycle counting. Consider this a
strong plea for someone in both BSD- and Linux- land to pull that off.
Ironically the first UNIX I worked on was a PDP-11 and it had "cycle
accurate" timekeeping. It was based on a 60 Hz mains interrupt and the
kernel code to increment time used modulus arithmetic. The code was
essentially: if(++lbolt >= HZ) { ... lbolt =- HZ; ... } where HZ is 60.
/tvb
[1] C:\tvb\> qpc
frequency: 0x_00369E99 3579545
3.5795450e+006 3.579545000 MHz
counter: 0x0091_338B6739 623635031865
6.23635031865e+011 174221.872295222 s
[2] How to become a bit banging, cycle counting, PIC loving, embedded
programming, time nut.
On 1/6/2021 10:39 AM, Kasper Pedersen wrote:
On 06.01.2021 06.35, Luiz Paulo Damaceno wrote:
Hi all,
I'm studying computer's timekeeping and i'm on level of remove the base
crystal that feeds the entire PLL logic of the motherboard (24 MHz on
motherboard that i'm using) and compare system's time with an NTP server.
(After reading your posts, and your plot, and guessing at PCish
motherboard and Linux for the board under test)
I did the same thing many moons ago now, and back then it was much
worse. It turned out to be a painful rounding error in the kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a386b5af8edda1c742ce9f77891e112eefffc005
After that quick-fix there was 5e-9 left, about what your plot shows.
After later cleanup that should now be be less than 3e-10.
What clocksource are you using? see
/sys/devices/system/clocksource/clocksource0/current_clocksource
and
/sys/devices/system/clocksource/clocksource0/available_clocksource
You should pick the one that has the least unpredictable
(rounding-error-prone in hardware) PLL ratios between the crystal
oscillator and the clocksource. On most PCs that is hpet, which is
typically driven directly from the crystal, though in your case this may
be a synthesized 14.31818 MHz (the most common hpet frequency).
A short run here using the latest kernel gives an error of < +/- 2e-10
on 14.31818MHz hpet, and 0.5ppm on tsc.
/Kasper Pedersen
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Hi, On 2021-01-06 14:18, Poul-Henning Kamp wrote: > > Magnus Danielson writes: > >> If the actual clock is more than 15 ppm off from the value in the drift >> file, it will never track in the frequency error. This is due to >> algorithm error in the NTPD. I have pointed out this problem, but there >> have been very little interest in fixing it. > You're thinking of the integrator-windup issue ? Integrator windup is not really an issue. That the phase wraps around is not an issue, it's a solution. If you do not want it to be an issue, open up bandwidth initially and you will lock-in quickly, then reduce bandwidth in steps the right way and you are set. This is essentially what a Kalman filter will do anyway. > > Yeah, that's very old news. I think I first documented it to Dave > Mills in 1994, but I never managed to convince him to take my fix > (Clamp I-term until D-term has the correct sign for the resiudal). > > That's when I started writing my own PLLs. Yeah, I did not manage to convince him either. > In general, the driftfile should never be used if NTP has a network > connection, it's raison-d'être was primarily the machines syncing > time via telephone twice per day. > > > PS: The drift file also soak up rounding/truncation errors in the > kernels timekeeping code. > Yeah, well, if fault handing for it would work better than it does, then it would not be an issue. If the heuristics it has would be brought out and replaced, then the drift file could be made to work well. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
On 06.01.2021 06.35, Luiz Paulo Damaceno wrote: > Hi all, > > I'm studying computer's timekeeping and i'm on level of remove the base > crystal that feeds the entire PLL logic of the motherboard (24 MHz on > motherboard that i'm using) and compare system's time with an NTP server. > (After reading your posts, and your plot, and guessing at PCish motherboard and Linux for the board under test) I did the same thing many moons ago now, and back then it was much worse. It turned out to be a painful rounding error in the kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a386b5af8edda1c742ce9f77891e112eefffc005 After that quick-fix there was 5e-9 left, about what your plot shows. After later cleanup that should now be be less than 3e-10. What clocksource are you using? see /sys/devices/system/clocksource/clocksource0/current_clocksource and /sys/devices/system/clocksource/clocksource0/available_clocksource You should pick the one that has the least unpredictable (rounding-error-prone in hardware) PLL ratios between the crystal oscillator and the clocksource. On most PCs that is hpet, which is typically driven directly from the crystal, though in your case this may be a synthesized 14.31818 MHz (the most common hpet frequency). A short run here using the latest kernel gives an error of < +/- 2e-10 on 14.31818MHz hpet, and 0.5ppm on tsc. /Kasper Pedersen ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Wow! Thank you for all the answers! I'm really happy... D. Rasor, Thank you for the file, i will take a look closer on it. Hal Murray, I have the same thought of you, but when I tried in an ARM Single Board Computer (Asus Tinkerboard) with the same scenario (external clock and no syncing in NTP) the same results were achieved. Not the same drift rate, but the same behavior. This SBC dont uses TSC for timekeeping, but that you said makes sense. Concerning this line of thought, when CPU clock varies (by changing it because of power management) the drift should changes too, dont? Direction and rate. Marek Dorsic, I've not looked for this file because what i'm doeing is: stop ntp daemon syincing and then start only computing the offset. Trent Piepho, If I generate clock with PWM outputs I can confirm that drift is zero and we have just some noises when compare it to the reference frequency. The error is not in the clock generation on the SoC. This takes us a step more closer to kernel related things... Tom Holmes, In this case, the timestamp comparisons are not made by using RTC data. But the timestamps generated by kernel using the machine clock frequency or something near this. As mentioned before, some hardwares has TSC (Time Stamp Counter). Guys... I'm attaching a picture of the drift of this x86 computer. First case is without an external clock (running with the motherboard's ordinary crystal oscillator), running free and then synchronized by chrony. The second case is that the computer gets synchronized and them running free, but with external clock replacing the ordinary crystal oscillator. Case 1: [image: image.png] Case 2: [image: image.png] Best regards, and again: thank you for all answers! Luiz Em qua., 6 de jan. de 2021 às 11:26, Poul-Henning Kamp escreveu: > > Magnus Danielson writes: > > > If the actual clock is more than 15 ppm off from the value in the drift > > file, it will never track in the frequency error. This is due to > > algorithm error in the NTPD. I have pointed out this problem, but there > > have been very little interest in fixing it. > > You're thinking of the integrator-windup issue ? > > Yeah, that's very old news. I think I first documented it to Dave > Mills in 1994, but I never managed to convince him to take my fix > (Clamp I-term until D-term has the correct sign for the resiudal). > > That's when I started writing my own PLLs. > > In general, the driftfile should never be used if NTP has a network > connection, it's raison-d'être was primarily the machines syncing > time via telephone twice per day. > > > PS: The drift file also soak up rounding/truncation errors in the > kernels timekeeping code. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Am I missing something or maybe I don't understand the situation , but I am under the impression that the RTC has it's own battery and crystal unrelated to the processor clock. Seems like in that case, the 24 MHz won't have any effect on the timekeeping drift. Tom Holmes, N8ZM -Original Message- From: time-nuts On Behalf Of Trent Piepho Sent: Wednesday, January 06, 2021 6:03 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] x86 CPU Timekeeping and clock generation On Tue, Jan 5, 2021 at 9:42 PM Luiz Paulo Damaceno wrote: > The 24 MHz comes from an synthesizer that is locked to an atomic clock, the > clock of NTP server (also 24 MHz, but an embedded board (Tinkerboard)) also > comes from the same Atomic clock that is feeding other synthesizer for > generates 24 MHz to this board. The RK3288 has some PWM generators. These are of course also fed from PLLs derived from the same 24 MHz input. So, why not produce a signal on the PWM that can be compared to your reference? This would tell you if the error is in the clock generation on the SoC or something in software that happens afterward. Or at least as far as the PWM clock tree overlaps the kernel timesource clock tree, which could be the CPU clock but it can be other things too. > The experiment is the following: 1- synchronize the computer's clock to NTP > server then leave it running free (no periodic synchronization), 2 - NTP will set the frequency skew too, so even if it is not doing periodic synchronization, there may still be a programmed frequency skew. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_l ists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
On Tue, Jan 5, 2021 at 9:42 PM Luiz Paulo Damaceno wrote: > The 24 MHz comes from an synthesizer that is locked to an atomic clock, the > clock of NTP server (also 24 MHz, but an embedded board (Tinkerboard)) also > comes from the same Atomic clock that is feeding other synthesizer for > generates 24 MHz to this board. The RK3288 has some PWM generators. These are of course also fed from PLLs derived from the same 24 MHz input. So, why not produce a signal on the PWM that can be compared to your reference? This would tell you if the error is in the clock generation on the SoC or something in software that happens afterward. Or at least as far as the PWM clock tree overlaps the kernel timesource clock tree, which could be the CPU clock but it can be other things too. > The experiment is the following: 1- synchronize the computer's clock to NTP > server then leave it running free (no periodic synchronization), 2 - NTP will set the frequency skew too, so even if it is not doing periodic synchronization, there may still be a programmed frequency skew. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
Marek, On 2021-01-06 09:06, Marek Dorsic wrote: > NTP has a drift file (usually /var/lib/ntp/ntp.drift or /var/lib/ntp/drift on > Linux) where it stores and periodically updates the computers clock drift > measured by ntpd in ppm. > In your scenario I assume it should contain only one number - 0. If it’s not > 0, does it correspond to the drift you are observing? If the actual clock is more than 15 ppm off from the value in the drift file, it will never track in the frequency error. This is due to algorithm error in the NTPD. I have pointed out this problem, but there have been very little interest in fixing it. The tell-tale of this being the problem will be a continuous reset of the clock phase. While this may not be the issue for this particlar test, one should be careful. The existence of a drift file bypasses the frequency learning phase, and there is no recovery mechanism if the phase learning phase fails. Cheers, Magnus > >.md > >> On 6 Jan 2021, at 08:28, Hal Murray wrote: >> >> >>> My question is: what i'm missing? >> Two ideas come to mind. >> >> Most PCs (and servers) smear the CPU clock frequency slightly to dance >> around >> the FCC rules. The chip that does that will have slight temperature >> influence >> so even if everything else is working right there will be tiny changes if >> you >> look closely enough. >> >> On Linux, you will see something like this at boot time. (look in dmesg) >> [0.00] tsc: Detected 3292.448 MHz processor >> >> Even if the hardware does the right thing, the software may screwup. If >> your >> system is using the TSC for timekeeping, that number above is used to setup >> the conversion from TSC ticks to ns. A year or 6 ago, there was a bug in >> that >> routine. If you patched the boot code to call that routine a half dozen >> times >> you would get a half dozen different answers. The kernel guys didn't notice >> because they were all close enough that ntpd could compensate. But any geek >> looking at ntpd graphs of drift would notice big jumps when the system was >> rebooted. >> >> >> -- >> These are my opinions. I hate spam. >> >> >> >> >> ___ >> time-nuts mailing list -- time-nuts@lists.febo.com >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
marek.dor...@gmail.com said: > NTP has a drift file (usually /var/lib/ntp/ntp.drift or /var/lib/ntp/drift on > Linux) where it stores and periodically updates the computers clock drift > measured by ntpd in ppm. The drift file only gets updated occasionally. (it's trying to avoid wearing out flash disks) If you turn on loopstats, you will get much more frequent data. A line gets written each time the clock is tweaked. One of the columns is the drift. Details are in the man/web pages. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
NTP has a drift file (usually /var/lib/ntp/ntp.drift or /var/lib/ntp/drift on Linux) where it stores and periodically updates the computers clock drift measured by ntpd in ppm. In your scenario I assume it should contain only one number - 0. If it’s not 0, does it correspond to the drift you are observing? .md > On 6 Jan 2021, at 08:28, Hal Murray wrote: > > >> My question is: what i'm missing? > > Two ideas come to mind. > > Most PCs (and servers) smear the CPU clock frequency slightly to dance around > the FCC rules. The chip that does that will have slight temperature > influence > so even if everything else is working right there will be tiny changes if you > look closely enough. > > On Linux, you will see something like this at boot time. (look in dmesg) > [0.00] tsc: Detected 3292.448 MHz processor > > Even if the hardware does the right thing, the software may screwup. If your > system is using the TSC for timekeeping, that number above is used to setup > the conversion from TSC ticks to ns. A year or 6 ago, there was a bug in > that > routine. If you patched the boot code to call that routine a half dozen > times > you would get a half dozen different answers. The kernel guys didn't notice > because they were all close enough that ntpd could compensate. But any geek > looking at ntpd graphs of drift would notice big jumps when the system was > rebooted. > > > -- > These are my opinions. I hate spam. > > > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] x86 CPU Timekeeping and clock generation
> My question is: what i'm missing? Two ideas come to mind. Most PCs (and servers) smear the CPU clock frequency slightly to dance around the FCC rules. The chip that does that will have slight temperature influence so even if everything else is working right there will be tiny changes if you look closely enough. On Linux, you will see something like this at boot time. (look in dmesg) [0.00] tsc: Detected 3292.448 MHz processor Even if the hardware does the right thing, the software may screwup. If your system is using the TSC for timekeeping, that number above is used to setup the conversion from TSC ticks to ns. A year or 6 ago, there was a bug in that routine. If you patched the boot code to call that routine a half dozen times you would get a half dozen different answers. The kernel guys didn't notice because they were all close enough that ntpd could compensate. But any geek looking at ntpd graphs of drift would notice big jumps when the system was rebooted. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
