Open-sourcing a more precise time appliance • Hacker News Board

Re: Open-sourcing a more precise time appliance

#111

Post by jrockway » Wed, Aug 11, 2021, 4:28 PM UTC

geoffeg wrote: post #66

jrockway wrote: post #31

What's interesting to me is how the form factor of timing GPS modules has stayed constant over the years. I started my GNSS timing journey with a used Trimble GPS from the 2000s, and it has the same form factor and pinout as the modern multi-constellation timing GPSes from uBlox. I've had a GPS clock going for several years at this point, and without an atomic clock or really any fanciness (just LinuxPPS and Chrony),…

Nice project, I've been working on something similar, but with an Arduino (Adafruit ESP32), an Adafruit GPS featherwing and a RTC. I originally started with a Linux-based solution like yours but no matter what I did I couldn't get the accuracy below about 5ms and my goal is sub-ms (verified with an oscilloscope.)

Yeah, I think you're on the right track. I like less and less having a Linux box to maintain, and there is less control over the timing of internal operations compared to a microcontroller, of course. On the other hand, Chrony is really, really good, and it would be a lot of code and debugging to write something that good from scratch.

With the Beaglebone, it's theoretically possible to drive the oscillator from a calibrated clock source (use the PPS pulse to discipline an oscillator). I was too lazy to build such a circuit and observe the effects. Some uBlox timing GPSes let you output a suitable signal (you can adjust the frequency in software), but the adjustability range when I last checked wasn't enough to make it work for the Beaglebone. Once you have the MCU running at a well-defined and stable frequency, I think it's possible to give Linux extremely accurate data, or at least know which clock cycle was the start of a second. I don't actually know how much any of this will help, and it's honestly not within my capability to measure.

For me, the outcome of my GPS clock project is that I never have to set my clock, and it looks really good. Running "chronyc sources" is always pleasurable as well, but I probably wouldn't notice a clock that's 20ms off unless I was comparing it against WWVB or something.

Re: Open-sourcing a more precise time appliance

#112

Post by ceejayoz » Wed, Aug 11, 2021, 4:29 PM UTC

chillingeffect wrote: post #109

eplanit wrote: post #68

Earlier quoted context omitted.

They've built and earned their (negative) reputation. This is cool, but it's like Philip Morris Tobacco Company coming out with a useful home appliance. Uhh....thanks?

Even a clock that moves backwards is right four times a day :)

Move the hands fast enough and it's right every second of every day.

Re: Open-sourcing a more precise time appliance

#113

Post by Terretta » Wed, Aug 11, 2021, 4:33 PM UTC

jrockway wrote: post #31

What's interesting to me is how the form factor of timing GPS modules has stayed constant over the years. I started my GNSS timing journey with a used Trimble GPS from the 2000s, and it has the same form factor and pinout as the modern multi-constellation timing GPSes from uBlox. I've had a GPS clock going for several years at this point, and without an atomic clock or really any fanciness (just LinuxPPS and Chrony),…

Thanks for the "one clock" mention for east coasters, about half price from Amazon vs. LaCrosse directly:

https://www.lacrossetechnology.com/products/404-1235ua-ss

https://smile.amazon.com/gp/product/B01CCHXTE2/

In the Zoom Age, ambiently glanceable accurate (for humans) time is super useful, as is the temporal pie chart of time left vs. how much I have to care how much time is left illustrated by analog clock faces.

Re: Open-sourcing a more precise time appliance

#114

Post by Terretta » Wed, Aug 11, 2021, 4:36 PM UTC

jrockway wrote: post #111

geoffeg wrote: post #66

Earlier quoted context omitted.

Nice project, I've been working on something similar, but with an Arduino (Adafruit ESP32), an Adafruit GPS featherwing and a RTC. I originally started with a Linux-based solution like yours but no matter what I did I couldn't get the accuracy below about 5ms and my goal is sub-ms (verified with an oscilloscope.)

Yeah, I think you're on the right track. I like less and less having a Linux box to maintain, and there is less control over the timing of internal operations compared to a microcontroller, of course. On the other hand, Chrony is really, really good, and it would be a lot of code and debugging to write something that good from scratch. With the Beaglebone, it's theoretically possible to drive the oscillator from a ca…

Yours does look fantastic.

Also enjoy mashing up accuracy with nixie tubes, feels very atomic '50s futurism:

- Atomic: http://www.nixie.dk/~jthomas/atomicnixie.html

- WWVB: http://www.nixie.dk/~jthomas/wwvb.html

Re: Open-sourcing a more precise time appliance

#115

Post by LeegleechN » Wed, Aug 11, 2021, 4:40 PM UTC

mFixman wrote: post #62

michaelt wrote: post #18

A few years back I was interested in microsecond-precise timekeeping. My experience was GPS-backed network clocks were surprisingly cheap - but PTP-aware network switches were surprisingly expensive. And though I thought I could cut the cost of a grandmaster clock from $2000 down to $200, I figured there'd be no point if I then have to connect it to a $20,000 network switch. I wonder how Facebook are connecting their…

I'm curious: what's the use case for microsecond-precise timekeeping?

Globally distributed, consistent databases. See this Google paper: https://static.googleusercontent.com/media/research.google.c...

Re: Open-sourcing a more precise time appliance

#116

Post by aelzeiny » Wed, Aug 11, 2021, 4:45 PM UTC

tyingq wrote: post #27

kall wrote: post #7

Earlier quoted context omitted.

There are probably a few reasons. One that I can imagine is that they use a distributed database somewhere that benefits from reliably tight wall clocks (in the style of Cloud Spanner or Cockroach).

Cockroach is much less dependent on highly accurate clocks. That was basically the core goal. Spanner like, without expensive clock infrastructure. Though it sounds like CockroachDB does better with at least reasonably well synced clocks. https://www.cockroachlabs.com/blog/living-without-atomic-clo...

True, I'm not disagreeing with you. However, it's worth nothing that Cockroach DB's consistency model assumes consensus in 180ms, and Spanner assumes similar SLOs at 6ms. Arguably, one could say that the reason why an open-source spanner-like DB doesn't exist in the marketplace with comparable performance is because these types of cards are proprietary and close-source (i.e Google's TrueTime). To your point, Cockroach is much less dependent on highly accurate clocks, but if these PCI-e cards became a common hardware commodity Cockroach can become even faster.

Now imagine a world where distributed DB technologies get so good that the trade-offs between consistency and availability is enough to warrant the use of a distributed DB for mid-sized projects. Right now, these DBs are seen as muscle cars with high cost and high maintenance only for BIG projects. A card like this might be the game-changer.

Re: Open-sourcing a more precise time appliance

#117

Post by mlichvar » Wed, Aug 11, 2021, 4:48 PM UTC

throw0101a wrote: post #97

mlichvar wrote: post #76

Earlier quoted context omitted.

Do the transparent clocks in your datacenter support unicast PTP? There is a possibility to use PTP as a transport for NTP to take advantage of PTP-specific hardware timestamping. It could also process the correction field, but it seems the switches typically don't support unicast PTP. The large asymmetry and banding of NTP in the test with Calnex Sentinel suggests it doesn't support the interleaved mode. NTP with ha…

> but it seems the switches typically don't support unicast PTP. Doing a quick search, the documentation for Cisco, Arista, and Juniper all mention unicast PTP, so it may be the feature is becoming more prevalent. See also "Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages": * https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-ptp-...

The unicast PTP support can be limited to boundary clocks and the enterprise profile doesn't require transparent clocks to support the unicast mode.

Also, there are different types of PTP transparent clocks. They can either be end-to-end or peer-to-peer, and either one-step or two-step clocks. To be useful for NTP, I think it would need to be an end-to-end transparent clock and ideally it would be a one-step clock to avoid dealing with with the follow-up messages.

Re: Open-sourcing a more precise time appliance

#118

Post by throw0101a » Wed, Aug 11, 2021, 5:07 PM UTC

throw0101a wrote: post #36

MisterTea wrote: post #28

Earlier quoted context omitted.

This gear will get cheaper soon. There is a big push in the Industrial automation world to get TSN/PTP deployed more widely and perhaps universally. The idea is to eliminate the dichotomy of real time vs non real time Ethernet networks in control systems from the plant network down to the machine level. This way you can send EtherCAT frames at equidistant intervals to servo drives in the microsecond range while casua…

> single pair Ethernet For anyone wondering: > In addition to the more computer-oriented two and four-pair variants, the 100BASE-T1 and 1000BASE-T1 single-pair Ethernet PHYs are intended for automotive applications[17] or as optional data channels in other interconnect applications.[18] The single pair operates at full duplex and has a maximum reach of 15 m or 49 ft (100BASE-T1, 1000BASE-T1 link segment type A) or up…

Addendum: The .3cz task force is working on 25/50/100 Gb/s over single twisted pair (two conductors) at lengths up to 11m (point-to-point):

* https://ieee802.org/3/cz/index.html

Re: Open-sourcing a more precise time appliance

#119

Post by m-ee » Wed, Aug 11, 2021, 5:09 PM UTC

daddylonglegs wrote: post #99

I cannot find any source files for the FPGA code in the repository (no .v .vhd .vhdl files and I can't see anything by looking around manually). The FPGA directory [1] contains some binaries and some documents relating to commercial code from a Swiss firm [2]. I've seen plenty of projects described as open source when the firmware is open source and the hardware is closed but this is the first time I've seen one wher…

Valve did something similar for the Vive tracker dev kit. There was a time before the standalone tracker was available https://www.vive.com/us/accessory/vive-tracker/

where if you wanted a tracker that wasn't a full controller you had to build it yourself. This involved a paid workshop in Seattle to get access to the dev kit and learn their tooling. Hardware was open source, but firmware was closed. If you wanted firmware changes you had to pay Synapse consulting fees for them to do it for you, and the updated firmware would then be made available free of charge to anyone else who paid for the workshop.

Re: Open-sourcing a more precise time appliance

#120

Post by Tepix » Wed, Aug 11, 2021, 5:20 PM UTC

This seems like a cool project. I didn't see a price estimate for this PCIe card.

However, isn't it smarter to try to build an infrastructure/architecture that can deal with somewhat less precise time information (milliseconds instead of nanoseconds)?