Discussion:
once again timenuts in the news
Add Reply
jimlux
2018-07-02 17:42:22 UTC
Reply
Permalink
Raw Message
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.


_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions the
jimlux
2018-07-02 18:18:43 UTC
Reply
Permalink
Raw Message
Post by jimlux
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-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there
Poul-Henning Kamp
2018-07-02 19:35:46 UTC
Reply
Permalink
Raw Message
--------
In message <1e83f1bb-8688-687b-6840-***@earthlink.net>, jimlux writes:

Jim,

The more you tell us about this stuff, the more we'll have to pester you
to write a book, or at least a long article titled "Clocks in Spaaaaaaaaaace!"

:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
jimlux
2018-07-02 19:50:43 UTC
Reply
Permalink
Raw Message
Post by Poul-Henning Kamp
--------
Jim,
The more you tell us about this stuff, the more we'll have to pester you
to write a book, or at least a long article titled "Clocks in Spaaaaaaaaaace!"
:-)
I have been thinking about just that...

There are others who are *much* better at some of the details - the
literature on Ultra Stable Oscillators, for instance.

I'm more of a "now that we have it, what do we do with it, and why do we
care about ADEV and PN"



_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Steven Sommars
2018-07-02 18:18:08 UTC
Reply
Permalink
Raw Message
Usenix paper:
https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf
Usenix talk: https://www.usenix.org/conference/nsdi18/presentation/geng
At the end of the talk the presenter mentions WAN sync between labs at
Utah, Wisconsin and Clemson "under 10 microseconds"

I'd like to see an error analysis and a complete list of prerequisites.
How does RTT/2 disappear?
Post by jimlux
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-netwo
rks-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.
_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/
listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.feb
Gabs Ricalde
2018-07-03 02:18:59 UTC
Reply
Permalink
Raw Message
they're using Support Vector Machines and Machine Learning (how sexy! how
fashionable!)
This approach has been done before, I wonder why it's not mentioned in
their literature survey.
The papers below have more details.

[1] Sirdey, R. & Maurice, F. "A linear programming approach to highly
precise clock synchronization over a packet network"
F. 4OR (2008) 6: 393.
https://doi.org/10.1007/s10288-007-0060-6

[2] D. E. Pinkovich and N. Shimkin, "Clock synchronization using
maximal margin estimation"
2011 19th Mediterranean Conference on Control & Automation (MED),
Corfu, 2011, pp. 1182-1187.
https://doi.org/10.1109/MED.2011.5983128

_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Loading...