HM

Hal Murray

Tue, Jan 31, 2023 5:56 AM

John Miller said:

I imagine most of us here use traditional RS232 serial ports to get this
signal into an x86 computer, usually using the DCD pin. I've found some
implementations of RS232 on PCs don't implement all of the additional
signaling pins, so sometimes DCD is flat out missing. In other cases -
especially with smaller embedded-type boards only UARTs with Rx/Tx are
available to the user. (I'm fiddling with using GPIO pins on a few such
systems, but it's quite a struggle.) So, there is a need for getting PPS
signals into systems.

There is PPS support on GPIO pins on Raspberry Pi.
There are a couple of HOWTOs with details for use with NTP.

Quick start NTP on the Raspberry Pi
https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html

The Raspberry Pi as a Stratum-1 NTP Server
https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

Stratum-1-Microserver HOWTO
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/

On linux, you can get at the PPS time stamps with
$ cat /sys/devices/virtual/pps/pps0/assert
1675144263.000009495#1771119
$
The stuff before the # is the time stamp, seconds and nanoseconds. After the

is a counter.

Use clear rather than assert for the falling edge.
ntpd turns off the edge it isn't using.

I haven't worked with PTP. Fiddling bits in packets while they are in flight
breaks security.

One problem with doing timing in the NIC is that it gets you the time in the
NIC. If you are interested in NTP, you probably want the time on the main CPU.

I've daydreamed about an FPGA with a clock input from your best house clock.
The idea is that you program it to keep POSIX time: seconds and nanoseconds
and set things up so that users can map it into memory read-only. All you
have to do to get the time is read a 64 bit register from a device. Extra
credit if you have PPS inputs that capture a time stamp etc.

Anybody know how long it takes to read a device register?

Modern read-the-clock on Linux doesn't do a system call. The kernel keeps info in shared memory (man vdso) so user code can get the time from the TSC. This PC is 3.6GHz. Here is a histogram of reading the clock a million times in a loop, warm cache and such:
Histogram: CLOCK_REALTIME, 1 ns per bucket, 1000000 samples.
ns hits
10 6012
11 152279
12 459189
13 212678
14 137852
15 29083
16 401
17 538
18 714
19 441
813 samples were bigger than 19.
Slowest was 69632 ns

--
These are my opinions. I hate spam.

John Miller said: > I imagine most of us here use traditional RS232 serial ports to get this > signal into an x86 computer, usually using the DCD pin. I've found some > implementations of RS232 on PCs don't implement all of the additional > signaling pins, so sometimes DCD is flat out missing. In other cases - > especially with smaller embedded-type boards only UARTs with Rx/Tx are > available to the user. (I'm fiddling with using GPIO pins on a few such > systems, but it's quite a struggle.) So, there is a need for getting PPS > signals into systems. There is PPS support on GPIO pins on Raspberry Pi. There are a couple of HOWTOs with details for use with NTP. Quick start NTP on the Raspberry Pi https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html The Raspberry Pi as a Stratum-1 NTP Server https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html Stratum-1-Microserver HOWTO https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ On linux, you can get at the PPS time stamps with $ cat /sys/devices/virtual/pps/pps0/assert 1675144263.000009495#1771119 $ The stuff before the # is the time stamp, seconds and nanoseconds. After the # is a counter. Use clear rather than assert for the falling edge. ntpd turns off the edge it isn't using. --------- I haven't worked with PTP. Fiddling bits in packets while they are in flight breaks security. One problem with doing timing in the NIC is that it gets you the time in the NIC. If you are interested in NTP, you probably want the time on the main CPU. I've daydreamed about an FPGA with a clock input from your best house clock. The idea is that you program it to keep POSIX time: seconds and nanoseconds and set things up so that users can map it into memory read-only. All you have to do to get the time is read a 64 bit register from a device. Extra credit if you have PPS inputs that capture a time stamp etc. Anybody know how long it takes to read a device register? Modern read-the-clock on Linux doesn't do a system call. The kernel keeps info in shared memory (man vdso) so user code can get the time from the TSC. This PC is 3.6GHz. Here is a histogram of reading the clock a million times in a loop, warm cache and such: Histogram: CLOCK_REALTIME, 1 ns per bucket, 1000000 samples. ns hits 10 6012 11 152279 12 459189 13 212678 14 137852 15 29083 16 401 17 538 18 714 19 441 813 samples were bigger than 19. Slowest was 69632 ns -- These are my opinions. I hate spam.

EM

Ed Marciniak

Tue, Jan 31, 2023 5:20 PM

I have no idea on implementation details, but I know the wired Ethernet interface on the Intel Galileo single board computer mentioned IEEE-1588 hardware support.

I’ve often thought about the idea for an amateur radio microwave station that it would be nice to distribute a clock via an Ethernet switch to drive local oscillators. Unfortunately, nanosecond level jitter on timing often doesn’t mean great phase noise performance.

Get Outlook for iOShttps://aka.ms/o0ukef

From: Hal Murray via time-nuts time-nuts@lists.febo.com
Sent: Monday, January 30, 2023 11:56:34 PM
To: Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Cc: Hal Murray halmurray@sonic.net
Subject: [time-nuts] Re: Network interface cards that support timestamping

John Miller said:

I imagine most of us here use traditional RS232 serial ports to get this
signal into an x86 computer, usually using the DCD pin. I've found some
implementations of RS232 on PCs don't implement all of the additional
signaling pins, so sometimes DCD is flat out missing. In other cases -
especially with smaller embedded-type boards only UARTs with Rx/Tx are
available to the user. (I'm fiddling with using GPIO pins on a few such
systems, but it's quite a struggle.) So, there is a need for getting PPS
signals into systems.

There is PPS support on GPIO pins on Raspberry Pi.
There are a couple of HOWTOs with details for use with NTP.

Quick start NTP on the Raspberry Pi
https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html

The Raspberry Pi as a Stratum-1 NTP Server
https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

Stratum-1-Microserver HOWTO
https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/

On linux, you can get at the PPS time stamps with
$ cat /sys/devices/virtual/pps/pps0/assert
1675144263.000009495#1771119
$
The stuff before the # is the time stamp, seconds and nanoseconds. After the

is a counter.

Use clear rather than assert for the falling edge.
ntpd turns off the edge it isn't using.

I haven't worked with PTP. Fiddling bits in packets while they are in flight
breaks security.

One problem with doing timing in the NIC is that it gets you the time in the
NIC. If you are interested in NTP, you probably want the time on the main CPU.

I've daydreamed about an FPGA with a clock input from your best house clock.
The idea is that you program it to keep POSIX time: seconds and nanoseconds
and set things up so that users can map it into memory read-only. All you
have to do to get the time is read a 64 bit register from a device. Extra
credit if you have PPS inputs that capture a time stamp etc.

Anybody know how long it takes to read a device register?

Modern read-the-clock on Linux doesn't do a system call. The kernel keeps info in shared memory (man vdso) so user code can get the time from the TSC. This PC is 3.6GHz. Here is a histogram of reading the clock a million times in a loop, warm cache and such:
Histogram: CLOCK_REALTIME, 1 ns per bucket, 1000000 samples.
ns hits
10 6012
11 152279
12 459189
13 212678
14 137852
15 29083
16 401
17 538
18 714
19 441
813 samples were bigger than 19.
Slowest was 69632 ns

--
These are my opinions. I hate spam.

time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com

I have no idea on implementation details, but I know the wired Ethernet interface on the Intel Galileo single board computer mentioned IEEE-1588 hardware support. I’ve often thought about the idea for an amateur radio microwave station that it would be nice to distribute a clock via an Ethernet switch to drive local oscillators. Unfortunately, nanosecond level jitter on timing often doesn’t mean great phase noise performance. Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Hal Murray via time-nuts <time-nuts@lists.febo.com> Sent: Monday, January 30, 2023 11:56:34 PM To: Discussion of precise time and frequency measurement <time-nuts@lists.febo.com> Cc: Hal Murray <halmurray@sonic.net> Subject: [time-nuts] Re: Network interface cards that support timestamping John Miller said: > I imagine most of us here use traditional RS232 serial ports to get this > signal into an x86 computer, usually using the DCD pin. I've found some > implementations of RS232 on PCs don't implement all of the additional > signaling pins, so sometimes DCD is flat out missing. In other cases - > especially with smaller embedded-type boards only UARTs with Rx/Tx are > available to the user. (I'm fiddling with using GPIO pins on a few such > systems, but it's quite a struggle.) So, there is a need for getting PPS > signals into systems. There is PPS support on GPIO pins on Raspberry Pi. There are a couple of HOWTOs with details for use with NTP. Quick start NTP on the Raspberry Pi https://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html The Raspberry Pi as a Stratum-1 NTP Server https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html Stratum-1-Microserver HOWTO https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ On linux, you can get at the PPS time stamps with $ cat /sys/devices/virtual/pps/pps0/assert 1675144263.000009495#1771119 $ The stuff before the # is the time stamp, seconds and nanoseconds. After the # is a counter. Use clear rather than assert for the falling edge. ntpd turns off the edge it isn't using. --------- I haven't worked with PTP. Fiddling bits in packets while they are in flight breaks security. One problem with doing timing in the NIC is that it gets you the time in the NIC. If you are interested in NTP, you probably want the time on the main CPU. I've daydreamed about an FPGA with a clock input from your best house clock. The idea is that you program it to keep POSIX time: seconds and nanoseconds and set things up so that users can map it into memory read-only. All you have to do to get the time is read a 64 bit register from a device. Extra credit if you have PPS inputs that capture a time stamp etc. Anybody know how long it takes to read a device register? Modern read-the-clock on Linux doesn't do a system call. The kernel keeps info in shared memory (man vdso) so user code can get the time from the TSC. This PC is 3.6GHz. Here is a histogram of reading the clock a million times in a loop, warm cache and such: Histogram: CLOCK_REALTIME, 1 ns per bucket, 1000000 samples. ns hits 10 6012 11 152279 12 459189 13 212678 14 137852 15 29083 16 401 17 538 18 714 19 441 813 samples were bigger than 19. Slowest was 69632 ns -- These are my opinions. I hate spam. _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe send an email to time-nuts-leave@lists.febo.com

GR

Gabs Ricalde

Thu, Feb 2, 2023 7:34 AM

On Tue, Jan 31, 2023 at 8:58 PM Hal Murray via time-nuts
time-nuts@lists.febo.com wrote:

I've daydreamed about an FPGA with a clock input from your best house clock.
The idea is that you program it to keep POSIX time: seconds and nanoseconds
and set things up so that users can map it into memory read-only. All you
have to do to get the time is read a 64 bit register from a device. Extra
credit if you have PPS inputs that capture a time stamp etc.

Anybody know how long it takes to read a device register?

I tried interfacing a cheap FPGA board (QMTECH XC6SLX16) with the LPC
bus, accessible via the TPM header on some motherboards. Reading 1
byte takes around 1.5 us, and then you can read the rest of the
counter.

The rest of this project has an OCXO, a PPS timestamping counter at
slightly less than 1 GHz using the Spartan 6 ISERDES, and a Linux PTP
hardware clock (PHC) driver (just the clock without the networking
parts). Instead of directly using the PHC, chrony can tightly sync the
system clock (TSC) from the PPS timestamped by the PHC (the PHC itself
may be free running). I may revisit this project and provide
details/measurements if anyone is interested.

On Tue, Jan 31, 2023 at 8:58 PM Hal Murray via time-nuts <time-nuts@lists.febo.com> wrote: > > I've daydreamed about an FPGA with a clock input from your best house clock. > The idea is that you program it to keep POSIX time: seconds and nanoseconds > and set things up so that users can map it into memory read-only. All you > have to do to get the time is read a 64 bit register from a device. Extra > credit if you have PPS inputs that capture a time stamp etc. > > Anybody know how long it takes to read a device register? > I tried interfacing a cheap FPGA board (QMTECH XC6SLX16) with the LPC bus, accessible via the TPM header on some motherboards. Reading 1 byte takes around 1.5 us, and then you can read the rest of the counter. The rest of this project has an OCXO, a PPS timestamping counter at slightly less than 1 GHz using the Spartan 6 ISERDES, and a Linux PTP hardware clock (PHC) driver (just the clock without the networking parts). Instead of directly using the PHC, chrony can tightly sync the system clock (TSC) from the PPS timestamped by the PHC (the PHC itself may be free running). I may revisit this project and provide details/measurements if anyone is interested.