111–120 of 162 posts
Earlier quoted context omitted.
Spanner (See https://docs.cloud.google.com/spanner/docs/true-time-externa... )
Does it need to be this close to NIST, or just relative to each other? Because the latter one is solved by PTP.
It's been over a decade now since I managed the truetime team at google, things may have changed since :)
Earlier quoted context omitted.
those are GPS based too. You typically would have a circuit you trained off off 1PPS and hopefully had a 10 or so satellites in view. You can get 50ns with this. Of course, you would verify at NIST.
GPS could be blocked easily, and AFAIK even given corrupted inputs. And HFT could possibly benefit from blocking or corrupting competitors GPS.
Earlier quoted context omitted.
It's 1 us granularity , which means you should report your timestamps with six figures after the decimal point. The required accuracy (Tables 1 and 2 in that document) is 100 us or 1000 us depending on the system.
> The required accuracy (Tables 1 and 2 in that document) no, Tables 1 and 2 say divergence, not accuracy accuracy is a mix of both granularity and divergence regardless, your statement before: > The regulatory requirement you linked (and other typical requirements from regulators) allows a tolerance of one second, so it doesn't call for this kind of technology. is not true
I respectfully disagree.
In context, "granularity" is nothing more than a resolution constraint on reported timestamps. Its inclusion adjacent to the specified "divergence from UTC" is a function of market manipulation surveillance objectives as discussed in preamble item (2), and really doesn't have anything to do with accuracy proper.
Earlier quoted context omitted.
We don't use NTP, but for robotics, stereo camera synchronization we often want the two frames to be within ~10us of eachother. For sensor fusion we then also need a lidar on PTP time to be translated to the same clock domain as cameras, for which we also need We actually disable NTP entirely (run it once per day or at boot) to avoid clocks jumping while recording data.
For a low precision environment to avoid sudden jumps I used SetSystemTimeAdjustment on Windows (now SetSystemTimeAdjustmentPrecise) to smoothly steer the system clock to match the GPS supplied time signal. On Linux I think the adjtimex() system call does the equivalent https://manpages.ubuntu.com/manpages/trusty/man2/adjtimex.2.... It smears out time differences which is great for some situations and less ideal for…
Worked really well for the project.
Avoiding time jumps was really worthwhile.
Earlier quoted context omitted.
My guess would be scientific experiments where they need to correlate or sequence data over large regions. Things like correlating gravitational waves with radio signals and gamma ray bursts.
those are GPS based too. You typically would have a circuit you trained off off 1PPS and hopefully had a 10 or so satellites in view. You can get 50ns with this. Of course, you would verify at NIST.
I believe you'll need 12 GPS sats in view to gain incremental accuracy improvement over 8.
Earlier quoted context omitted.
GPS gets its time from NIST (though during this incident they failed over to another NIST site, so it wasn't impacted).
That is not correct at all. How did you arrive at that conclusion? GPS has its own independent timescale called GPS Time. GPS Time is generated and maintained by Atomic clocks onboard the GPS satellites (cesium and rubidium).
In particular, the atomic clocks on board the GPS satellites are not sufficient to maintain a time standard because of relativistic variations and Doppler effects, both of which can be corrected, but only if the exact orbit is known to within exceeding tight tolerances. Those orbital elements are created by reference to NIST. Essentially, the satellite motions are computed using inverse GPS and then we use normal GPS based on those values.
Out of curiosity, can anyone say the most impactful things they've needed incredibly accurate time for?
If (and it isn't very conceivable) GPS satellites were to get 5µs out of whack, we would be back to Loran-C levels of accuracy for navigation.
Has anyone here ever needed microsecond precision? Would love to hear about it.
I believe LTE and 5G networks require it to coordinate timeslots between overlapping cells. Of course, they can use whatever reference they want, as long as all the cells are using the same one - it doesn't have to be UTC. Some (parts of) networks transmit it across the network, while others have independent GPS receivers at each cell site. Synchronization is also required for SDH networks. Don't know if those are st…
It is very common to integrate a GPS in a WSPR beacon to discipline the transmit frequency, but with modest thermal management, very ordinary crystal oscillators have very nice stability.
Earlier quoted context omitted.
Lots of things do. Shoot, even plain old TDM needs timing precision on the order of picoseconds to nanoseconds.
But does that require accurate UTC?