[time-nuts] Re: What everyday uses are there for accurate clocks?

[Joseph Gwinn]

On Thu, 01 Dec 2022 03:30:52 -0500, time-nuts-request at lists.febo.com 
wrote:
Re: time-nuts Digest, Vol 223, Issue 37

> Message: 11
> Date: Wed, 30 Nov 2022 01:49:42 -0800
> From: Hal Murray <halmurray at sonic.net>
> Subject: [time-nuts] Re: What everyday uses are there for accurate
> 	clocks?
> To: Discussion of precise time and frequency measurement
> 	<time-nuts at lists.febo.com>
> Cc: "Dr.  David Kirkby" <drkirkby at kirkbymicrowave.co.uk>, Hal Murray
> 	<halmurray at sonic.net>
> Message-ID: <20221130094942.6D54D28C201 at 107-137-68-211.lightspeed.sntc
> 	ca.sbcglobal.net>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> Dr. David Kirkby said:
>> I can't see how knowing who posted what first on Facebook, Instagram etc
>> affects the user experience, when differences in time are any less than a
>> second.
> 
> It doesn't make any difference to the people which of two 
> really-close events happens first.
> 
> What does matter is that separate data centers agree.  It's a data 
> base issue 
> rather than a user interface issue.
> 
> Google put atomic clocks in all their data centers.
> 
> Spanner: TrueTime and external consistency
>   <https://cloud.google.com/spanner/docs/true-time-external-consistency>
> 
> ----------
> 
> Many years ago, it wasn't quite uncommon for Unix shops to get into trouble 
> because the time on their systems weren't consistent.  I forget the 
> details.  
> It involved NFS - Network File Systems and time on the NFS server being 
> different from the time on the workstation used to edit a file.
> 
> This looks like a good summary:
> 
> why does NFS require synchronized system clocks?
> 
<https://unix.stackexchange.com/questions/549550/why-does-nfs-require-synchronized-system-clocks>

On a civilian weather-radar project many decades ago, the programming 
team started to experience mysterious lossage of code updates, 
causing general chaos, with much random blame-shifting.  It turned 
out that NFS was the culprit, for an unexpected reason.

NFS and SCCS were designed back in the days of small programs and 
small programming teams.  NFS an/or SCCS used timestamps to infer 
update order.  (Don't recall exactly how SCCS and NFS were fit 
together back then - it was project-developed.)  When the programming 
team was about 100 people, we started to experience mysterious 
lossage of updates, causing general chaos.  In those days, UNIX 
timestamps had one-second granularity. With ten programmers, 
collisions were unlikely enough that the lossage was not noticed.  
With a hundred programmers, collisions were common and the lossage 
was devastating.

The solution was to provide a common atomic sequence number generator 
and use these numbers to sequence-stamp code updates.

For the record, the basic source of time in those UNIX boxes was the 
local power line frequency, 60 Hz in the US or 50 Hz elsewhere.  Use 
of the local power-line cycle interrupt for time-stamping would have 
reduced the lossage rate, but could not completely eliminate 
collisions.  GPS was not available then.

Joe