[time-nuts] Re: NIST NTP servers way off for anyone else?

On Tue, Dec 14, 2021 at 2:21 PM Hal Murray wrote: > > > I've seen cards (ethtool) that support several time options - what are they > > and how do I use them? > > I'm not sure which options you are referring to. Probably the flags from ethtool -T output: Time stamping parameters for eth0:

[time-nuts] Re: PPS latency? User vs kernel mode

On Mon, Dec 13, 2021 at 8:03 AM David Taylor via time-nuts wrote: > > On 13/12/2021 04:17, Adam Space wrote: > >> What do you mean by "kernel mode"? > > I am referring to this guide > > that another user here > > recommended to me a bit ago. I

[time-nuts] Re: PPS latency? User vs kernel mode

On Mon, Dec 13, 2021 at 6:56 AM Poul-Henning Kamp wrote: > > In FreeBSD you get all that for free: > > https://papers.freebsd.org/2002/phk-timecounters.files/timecounter.pdf > "It is painfully obvious that the interrupt latency is the dominant noise factor in PPS timestamping in the

[time-nuts] Re: PPS latency? User vs kernel mode

I found the plot I made earlier (Aug 2017), which I've attached. The link I sent in 2017 and in the list archive still works, but I'm not allowed to post links to google photos anymore. The uncorrected value would be comparable to pps-gpio, without a hardware timer. Worst case is 100 µs. This

[time-nuts] Re: PPS latency? User vs kernel mode

What I did was measure the phase offset of the PPS timestamps in Linux, after ntp has locked the clock to the PPS. I think would be made up of three main sources of error: 1. The phase offset in the PPS signal itself. 2. The error in the Linux clock doing the timestamping, over a tau of 1

[time-nuts] Re: When did computer clocks get so bad?

On Wed, Sep 29, 2021 at 1:48 PM Poul-Henning Kamp wrote: > Since these embedded chips generally are incredibly robust with > respect to timing, the xtal on the BOM is the cheapest that will > meet spec. Crystals? We don't need no stinking crystals! At least for the RTC. Chips like, e.g. the

Re: [time-nuts] Raspberry Pi 4 oscillator replacement

On Thu, Feb 4, 2021 at 4:09 PM Hal Murray wrote: > In case anybody isn't familiar with ARM SOC chips, they typically have a layer > of muxes between the external pins and the internal I/O devices. I don't know > if the chip used in the Pi-4 works this way. Quite likely. > > > The system

Re: [time-nuts] An Other Ublox 8

On Thu, Jan 28, 2021 at 1:34 AM Javier Herrero wrote: > I have been playing lately with the M8F, but did not had a detailed look > to the 30.72MHz frequency as John did. I have used it along with a > Zynq-based board (a very unexpensive surplus EBAZ4205, that can be get > for ~10 EUR) to made an

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

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 >

Re: [time-nuts] Time Interval Counter(?) for high-precision watch measurement

I used the open source application tg, https://github.com/vacaboja/tg I've found the microphone from some wired earbuds works well. Just set against the watch. It picks up quartz watches. tg lets you "calibrate" it by comparing to a reference audio PPS source, like a quartz watch. But it

Re: [time-nuts] Raspberry Pi NTP server

On Mon, Jul 13, 2020 at 4:52 PM Hal Murray wrote: > > Is there any way for a USB device to synchronise with the CPU clock (perhaps > > via the USB framing) so that a special-purpose device could timestamp the > > PPS > > occurrence with respect to CPU time ? It seems maybe this was thought

Re: [time-nuts] Raspberry Pi NTP server

On Mon, Jul 13, 2020 at 8:54 AM Petr Titěra wrote: > > All Prolific chips I saw claimed to be USB 2.0 Full-speed. That means > they are polled only once in 1ms and there is no way how to change it > (poll rate is selected at hardware level). Looking at the UHCI specification, for USB 1.1 HCIs,

Re: [time-nuts] Raspberry Pi NTP server

On Sun, Jul 12, 2020 at 11:51 AM jimlux wrote: > > Is the PPS via USB CTS stamped at interrupt time? or is it stamped > higher up in the stack? > > I started tracing this out, but then decided I'm not going to be writing > Linux USB drivers any time soon, so gave it up. > > I could easily

Re: [time-nuts] Raspberry Pi NTP server

On Sun, Jul 12, 2020 at 5:08 AM Matthias Welwarsky wrote: > > If you think about using an AM3358, there's zero reason to use a GPIO for PPS > input. There are much better options, like the gptimer inputs or the eCAP > engine, which runs on a 200MHz clock and is therefore able to create much more

Re: [time-nuts] Raspberry Pi NTP server

On Sat, Jul 11, 2020 at 7:37 PM jimlux wrote: > > You might want to look into one of the "real time" linux kernels or > other similar implementations - they might have "turned some of the > knobs" to improve the handling of device data. The real time kernel primarily is about trying to get

Re: [time-nuts] Raspberry Pi NTP server

On Fri, Jul 10, 2020 at 12:17 PM Tim S wrote: > > I believe the issue is arising from the understanding of "what" is being > interrupted. > > When a UART or GPIO is triggering an interrupt - for the UART it's a FIFO > notice that data is available to be pulled out, for the GPIO it's >

Re: [time-nuts] Linear or quadractic fit algorithms for small microcontrollers?

On Thu, Dec 27, 2018 at 8:47 PM Tim Shoppa wrote: > > Getting rid of the outliers turns out to be important when using the ES100 > in tracking mode. It turns out that in my noisy household environment here > on the east coast, every few hundred attempts, the ES100 tracking attempt > will return