On 7/2/18 10:42 AM, jimlux wrote:
https://news.slashdot.org/story/18/07/01/2022232/google-and-nasdaq-pursuing-nano-second-precision-in-network-time-protocol
https://www.nytimes.com/2018/06/29/technology/computer-networks-speed-nasdaq.html
100 ns... Doesn't seem particularly challenging if you have something
like PTP.
But there's this:"The new synchronization system will make it possible
for Nasdaq to offer “pop-up” electronic markets on short notice anywhere
in the world, Mr. Prabhakar said"
OK, 100ns world wide is a trickier proposition.
oooohhh I see what's new and different - the authors of the paper
https://www.usenix.org/conference/nsdi18/presentation/geng
https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf
they're using Support Vector Machines and Machine Learning (how sexy!
how fashionable!)
and "Because HUYGENS is implemented in software running on standard
hardware, it can be readily deployed in current data centers."
And, more troubling - in terms of the desire to do fast transactions..
They do the processing in batches ( on page 82 of the paper)
A crucial feature of HUYGENS is that it processes the transmit (Tx)
and receive (Rx) timestamps of probe packets exchanged
by a pair of clocks in bulk: over a 2 second interval
and simultaneously from multiple servers.
SO they're actually not really "synchronizing the systems" (in the sense
that I can schedule an event on System A to occur tomorrow at
12:34:56.000,000,000 and an event on System B tomorrow at
12:34:56.000,000,001 and record the events on System C by starting my
recorder at 12:34:55.999,999,999 and stopping the recorder at
12:34:56.000,000,002
They're "adjusting the time of events recorded by multiple different
clocks to a common time scale, post hoc"
We do this now in spacecraft work - it's generically called "time
correlation" where you relate the onboard spacecraft clock (generally
some sort of free running counter) to external measured events (i.e. the
Earth Received Time of a message, or GPS 1pps ticks, or ...) and then
create a suitable model of the clock behavior so that you can schedule
future events (thruster burns, camera actions), etc.
Sometimes the results are quite impressive
(https://www.nasa.gov/mission_pages/msl/news/msl20120806b.html)
But I will readily concede that the current spacecraft approach is not
scalable to dozens, much less, thousands of entities.
So Huygens meets the "reconcile transaction time stamps at the end of
the day" kind of need, but does NOT meet the "schedule future events
independently" need.
I find that "knowing the time of an event in the past precisely" is
interesting and useful, but "scheduling the time of an event in the
future precisely" is, in the long term, a more useful thing.
Here's a practical example..
You have a constellation of N satellites, all independent (in the sense
that they do not communicate with each other) and observing an
astronomical object for a sporadic phenomenon (a coronal mass ejection,
as it happens). You don't have enough storage or communication
bandwidth to record everything all the time, so you record some at a
duty cycle of 1% - record a millisecond's data every 100 milliseconds.
The phenomenon of interest lasts minutes or hours, so you'll get plenty
of data. However, the 1 millisecond recording times must be
synchronized across all satellites, because you're going to combine the
data later, and it needs to be coherent - (they're radio interferometers).
So what you need is "good clocks" that are predictable in the future -
if satellite 1 is at 10.000,01 MHz and satellite 2 is at 9.999,997, you
can adjust the sampling rate generator accordingly (in terms of rate and
offset) to ensure that every 100 ms, the sampling gate opens for 1 ms -
and they're all the same millisecond.
http://adsabs.harvard.edu/abs/2018AAS...23221102K
http://www.ursi.org/proceedings/procGA17/papers/Paper_HJ26-3(1332).pdf
https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=3662&context=smallsat
(Full Disclosure - I'm the project manager for SunRISE)
_______________________________________________
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.
