On 5/3/25 07:47, Timothy Collinson - timothy.collinson at port.ac.uk
(via tml list) wrote:
>
>
> Hi there
>
> <snip>
>
>     >
>     > However, lower accuracy (1 second in 30,000 years) commercial
>     caesium
>     > and rubidium clocks had been developed which could typically be
>     housed
>     > within a 500 x 500 x 130 mm rack-mountable enclosure with thermal
>     > rather than cold atoms.
>
>     >
>     > And "the last few years" have seen the emergency of chip-scale
>     atomic
>     > clocks that can fit in a matchbox with a core 'physics package' of
>     > less than 1cm^3 - accuracy: 1 second in 300 years.
>     >
>     > No doubt things have moved on in the last 12 years although I've
>     not
>     > had time to look at where they are now.
>
>     Like so? https://www.ingenia.org.uk/articles/compact-atomic-clocks/
>
>
> Ah, thank you - will save that for tomorrow.
Up the _really_ precise end, how about less than 1 second per age of
universe?  https://www.eurekalert.org/news-releases/943211
>
>
>     However, if accurate to second-per-millennium clocks are
>     _commercially_
>     available _now_, would that be good enough for C57 civilian traffic
>     traipsing through the main routes of charted space (or C22 civilian
>     traffic traipsing around the main routes of Ushuggi), syncing up
>     during
>     starport visits?
>     That caesium clock you mentioned occupies 0.04 cubic metres - or less
>     than 0.004 dtons.  With (I _think_) costs of ~50k USD each _now_,
>     that's
>     what, 60k CrImp for three (WHAT DO when two clocks aboard ship
>     disagree?), taking up three-fifths of sod-all space? Compared to the
>     cost of even a Scout ship, that's epsilon.
>
>
> Well, it was just a thought.
>
> I was more imagining that the 3m tall vacuum thingy might be the
> *necessary* atomic clock onboard ship, not the matchbox sized one...

I wasn't talking about the matchbox-sized ones, I was talking about the
caesium clocks you mentioned that take up a volume 500 x 500 x 130 (?)
mm, or 0.5 x 0.5 x 0.13 m, for 0.0325 m3.

The really fancy ("3m tall vacuum thingy") ones would be in starports
and possibly capital starships, where volume isn't as much of a
constraint as it is aboard the 400 dton _Carries No Change_.

>
>     I lean towards the option taken in GT: Interstellar Wars, where
>     most of
>     the volume of a Traveller "computer" is taken up by stuff not
>     subject to
>     Moore's law - stuff like sensors, governed by more mundane things
>     like
>     the laws of physics.
>
>
> I don't disagree.  I just thought it might spark something off for
> someone.
>
>     As computronium _is_ subject to Moore's Law (or something like
>     it), I'm
>     not seeing how financial transactions would _require_ a beefy
>     computer.
>
>
> From the article:
> Financial transactions
> High-frequency trading requires a network to be synchronised with an
> accuracy of around 0.1 microseconds, otherwise it may appear that
> trades have occurred before they have actually been executed.  Such
> networks are typically synchronized to GPS time and are hence
> susceptible to GPS outage.
>
>
> I'm not sure that helps in a Traveller setting where I doubt they're
> synchronized to GPS and I suspect they may well appear to have
> occurred before they've actually been executed... but I'll have to
> leave that for greater minds.

I think the combination of a second-per-millennium atomic clock _plus_
satnav sync would tide you over most outages assuming linear drift, for
HFT purposes, that are less than an hour.  For wide-area time sync (such
as NTP), where the bound is on close order of 10 _milli_seconds from
UTC, you're covered (using the same kit) for a 10 year outage.

For quadratic drift, it would be 115 days' holdover for HFT purposes,
and a century for a wide-area time-sync outage (before other external
factors).

Due to the latencies imposed by jump/lack of ansibles, HFT would
probably only be viable on/very near a planet.

>
>     Could you expand more on secure/efficient comms?
>
>
> Only to quote the article, you know me, a bear of very little brain
> (though I like the sound of temporal windows):
>
> ///quote
> Flexible networks
> Chip-scale clocks would allow powerful ad hoc communications
> networks to be established in the field for military purposes and
> enable data to be passed more reliably and securely via precision time
> stamping, data authentication and temporal windows.
At a _guess_, what the article calls "temporal windows" sounds a lot
like range gating in radar - given target is approx X km away, only
listen for a band of time that's around 2X/c seconds away (round-trip
time of radar pulse).  The data analogue would be discarding messages
that fall outside some time-bound relative to their origination.
>
> Secure communications
> More generally, chip-scale clocks can potentially allow messages to be
> retrieved from data streams without the need for protocol 'headers'
> and 'footers', enabling messages to be transmitted with greater speed
> and security.

Sounds a lot like SDH/SONET.  Also sounds like such streams would be
vulnerable to timing loops - where one network element derives its
timing from other network elements, and they likewise derive their
timing from network elements including the original, without any being a
designated master source.  Such a loop would see its timing drift away
from external networks, ultimately causing massive traffic loss.

I'd expect some form of clock recovery capability directly from the
transmitted data, even if only to roughly align the receiver's local
clock before the fine alignment to the network references starts.

>
> Efficient communications
> Chip-scale clocks allow the radio spectrum to be used more
> efficiently, for example via ultra-wideband spread-spectrum
> approaches, and help mitigate the high attendant data loss of undersea
> communications.
> ///endquote
>
> If that helps.
>
> tc
>
> -----
>
That it does. Thanks for the extra blurb.

Alex