Newly published: Introduction to Time Service

I’ve published a background paper on precise clocks, time service, and NTP. It is Introduction to Time Service and is meant to be read as a companion to (or before) the GPSD Time Service HOWTO.

Comments, critiques, and suggestions for additions will be welcome.

Published
Categorized as General

46 comments

  1. Is it really feasible to use a general-purpose OS like Linux to provide local GPS-based time service? Wouldn’t a hard-real time or bare-metal platform be a better fit for the job, especially since nowadays you’d want to run such a service on a dedicated board, i.e. something like Raspberry Pi or BeagleBone Black?

    1. >Is it really feasible to use a general-purpose OS like Linux to provide local GPS-based time service?

      Yes, generally, unless you’re doing physics experiments. It’s all about the magnitude of the jitter you’re willing to tolerate, and for most purposes anywhere near the real world GPSD feeding a Linux box is just fine.

      Which is not to say the idea of building a dedicated Stratum 1 server out of a RasbPi or Beaglebone isn’t mad cool and rather tempting even to this raw novice at hardware hacking. But cost-effective it would not be.

  2. 1) You say that propagation delay from time standard transmitters like WWVB to receivers is constant and can be compensated out. That’s not quite the case. The atmosphere has a velocity factor, just like a cable does, and it varies with density and moisture content. Does that variation induce enough jitter to matter at the time scales you’re talking about?

    2) Yeah, propagation at 60 kHz is a bitch. There’s a reason people moved up into the MF and HF ranges early on: while it’s easier to generate an LF signal with primitive technology, it just doesn’t work as well.

    3) “Jitter induced by variable WAN propagation delays (including variations in switch latency and routing) makes it impractical to try to improve the accuracy of NTP time to much better than 100ms.”
    Shouldn’t this be “…of NTP time obtained from outside of a LAN” or something like that? After all, as you note later, NTP works great on a LAN, especially (I would suspect) on a gigabit or faster LAN with nonblocking switches.

    4) “Of all the time sources described here, the only one not precise enough to drive WAN NTP is in-band time from a GPS without 1PPS .” EXPN “footnote”?

    5) Are older time radios totally unusable, or simply degraded? And why couldn’t they be firmware updated to the new scheme?

    1. >Does that variation induce enough jitter to matter at the time scales you’re talking about?

      If it did, I’m certain I would have stumbled over a reference to the problem during the deep dive into time mensuration I just came out of. As it is, the silence on this issue suggests that any jitter introduced this way is small compared to the 26ns error budget of the transmissions.

      >Shouldn’t this be “…of NTP time obtained from outside of a LAN” or something like that?

      That’s why it says “WAN”. Duh. :-)

      >EXPN “footnote”?

      Uh oh. Markup glitch. Will fix.

      >Are older time radios totally unusable, or simply degraded?

      Unusable.

      >And why couldn’t they be firmware updated to the new scheme?

      My sources imply the incompatibility would require a fix to the analog portion of the RF stage, well before firmware sees it.

  3. “Which is not to say the idea of building a dedicated Stratum 1 server out of a RasbPi or Beaglebone isn’t mad cool and rather tempting even to this raw novice at hardware hacking. But cost-effective it would not be.”

    What, you couldn’t get <100ns jitter on your LAN for under $100? That sounds cost effective to me.

  4. Jitter of in-band GPS time is listed as “> 100ns (100000000ns)”. That should be *ms*, right?

  5. Paragraph four of the “Basics of NTP” section has a unit label mSec (most ±100 mSec). You have used ms elsewhere.

    1. >Paragraph four of the “Basics of NTP” section has a unit label mSec (most ±100 mSec). You have used ms elsewhere.

      Paste-o. Will fix.

  6. Style issue, and it is a matter of opinion, but I think quantities like 100000000ns would be more readable with commas and spaces (100,000,000 ns)

    The lack of a space also has a significantly greater impact on readability than it might otherwise because you chose Georgia [which has text figures] as the font – the smaller zero tends to run together with the following letters.

  7. To clarify I think there should be a space before the unit on all quantities, not just the large ones.

  8. “(popularly called an “atomic clock”)”

    I think ‘atomic clock’ has a very specific meanng, namely apparatus that uses atoms as a frequency standard for its timekeeping element.

    “By international agreement, the U.S. and other major national time authorities use primary standards based on electronic transitions between the two hyperfine ground states of cesium-133 atoms.”

    That’s actually the *definition* of second in the International System of Units (SI) since quite a long time.

    1. >Accuracy and precision are very different things.

      Yes. I tried to use the distinction properly. If you think I failed, email me a diff.

  9. > Which is not to say the idea of building a dedicated Stratum 1 server out of a RasbPi or Beaglebone isn’t mad cool and rather tempting even to this raw novice at hardware hacking. But cost-effective it would not be.

    I think building one that doubles as a wall clock would be much more cool.

  10. “I think ‘atomic clock’ has a very specific meanng, namely apparatus that uses atoms as a frequency standard for its timekeeping element.”

    You’re correct, Jakub. Eric’s referring to a particular bit of marketing prevalent in the US that calls anything with a WWVB receiver in it an “atomic clock”. No matter how incorrect the usage, it’s still very common, more so than the correct usage.

  11. Version 1.0 Typo:

    “More applications than is commonly realized require precise time” should be “More applications than are commonly realized require precise time”.

  12. @W. Craig Trader: It looks all right to me “it is commonly realized”; but I am not a native speaker.

  13. guest: One of the things to consider between bare-metal boards and general-purpose architectures is that your standard PC may have several orders of magnitude greater performance and corresponding reduction in execution time.
    An 8051 microcontroller has (originally) a 1 MHz instruction clock. Finding an x86 architecture machine which has less than a 1 GHz instruction clock is hard. In the span of time that the microcontroller could jump to the interrupt vector, the x86 machine might have been able to process the whole time update.

    Another item to consider is that we synchronize time because *somebody* cares about it. If your dedicated system does a better job of synchronizing to a source, but the user is on another machine, you have to take into account the additional network hop for the consumer. If the time consumer is on the local machine, you can avoid that hop and latency/jitter.

  14. Eric,

    In the first paragraph of your section titled Time Service Types, you say: “By international agreement, the U.S. and other major national time authorities use primary standards based on electronic transitions between the two hyperfine ground states of cesium-133 atoms.”

    Your usage of “ground states” (plural) is a contradiction in terms. The electron shells of atoms can only have one single ground state. Hence, depending on how precise you want your wording to be, I would rephrase that either as “electronic transitions between the two hyperfine energy levels of the ground state of cesium-133 atoms”, or as “electronic transitions in cesium-133 atoms”.

  15. “U.S.’s has two” at the end of the Time Service Types section–did you mean to refer to the states as a plural, necessitating the apostrophe?

    1. >did you mean to refer to the states as a plural, necessitating the apostrophe?

      “National time standards, including the U.S.’s” It’s possessive.

  16. In “Table 1. Summary of worst-case deviation from UTC”, you have a line for “1PPS delivered by OS kernel: 1us (1000 ns)”. That made me wonder: Where does the kernel get the time for the PPS signal it ships? And how does the kernel make its outgoing PPS signal more precise than the PPS signals coming in through the USB or serial interfaces? Does it compute a long-term average of the incoming signals and then extrapolate it? Does it have some other, more precise source of incoming time inside the computer, maybe one of the Rubidium clocks you mentioned? So I re-read the main text to find out, but I couldn’t find anything about the kernel and its PPS signal. Could you add a sentence or two to clarify this?

    1. >Could you add a sentence or two to clarify this?

      Some of this is explained in the companion, the GPSD time service HOWTO. The kernel is not more accurate than the PPS signal off the receiver, it’s less so by a factor of 200. There is no internal rubidium clock, just the quartz crystakl the 1PPS is meant to condition.

    1. >Slightly OT: Apparently the guy doing most of the NTP maintenance and user support is living on a shoestring:

      That’s actually not off topic at all.

      Later today I expect to be able to stop being mysterious about this.

  17. David J Taylor http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html has a bunch of pis with different clock sources, includes graphs of offset deviations. Another Stratum 1 raspberry pi server http://ntpi.openchaos.org/pps_pi/ from 2 years ago. PPS is also available.

    So a <$100 cost is certainly possible, as it was less than that at the time.

    version="ntpd … Sun Jan 6 19:01:13 UTC 2013 (1)",
    processor="armv6l", system="Linux/3.6.11+", leap=00, stratum=1,
    precision=-19, rootdelay=0.000, rootdisp=1.195, refid=PPS,
    reftime=d494807e.342184bb Mon, Jan 7 2013 0:00:14.203,
    clock=d494808b.d9329de3 Mon, Jan 7 2013 0:00:27.848, peer=36158, tc=4,
    mintc=3, offset=0.000722, frequency=36.518, sys_jitter=0.003583,
    clk_jitter=0.004, clk_wander=0.001

  18. “There is about three orders of magnitude”
    should be
    “There are about three orders of magnitude”
    because “three orders” is plural.

    1. >“There is about three orders of magnitude” should be “There are about three orders of magnitude” because “three orders” is plural.

      I consider both uses to be acceptable in specific connection with mass nouns or mass noun phrases, and to suggest different shades of meaning. You are either emphasizing the singularity of the mass or the plurality of its parts.

  19. >Later today I expect to be able to stop being mysterious about this

    planning to take over ntp ?

  20. @kn:

    > planning to take over ntp ?

    Why on earth would Eric take an apparently more-than-fulltime job from someone who, by all accounts, is doing it well and loves it?

    I don’t think you’ve been paying attention to the rumblings here and elsewhere about how open source actually requires money in many cases, and companies are going to have to step up to the bar and help out. Obviously, Eric is in a good position to help facilitate this.

  21. @Patrick Maupin

    well, I don’t know how good Eric is at fundraising; I’m not familiar with any success stories in that area, except maybe the Beast fund, but then sustainably financing a project is different from collecting donations for a one time purchase.
    Otoh, “coding” and “being in charge” are 2 things I think Eric could do well, so that’s probably where that hunch came from. And it is just that – the first thing that popped up in my mind. No, I didn’t think that trough. Sometimes I sit and think, but often I just sit.

    Now a question I do find interesting is how to fund open source, but I’ve always assumed that at least the infrastructure would have corporate sponsors; the openssl story was a surprise to me.

  22. > I consider both uses to be acceptable in specific connection with mass nouns or mass noun phrases, and to suggest different shades of meaning. You are either emphasizing the singularity of the mass or the plurality of its parts.

    I think that requires “There is a difference of about three orders of magnitude”.

  23. I think this could benefit from a couple paragraphs on the distinction between atomic time and astronomical time, and a comparison of IAT, UTC, and UT0.

    1. >Are you aware of PHK’s work on ‘Ntimed’ ?

      I am. But it’s still a long way from an implementation that can be fielded.

  24. @Thomas Blankenhorn:
    Your usage of “ground states” (plural) is a contradiction in terms.

    That language appears in the actual SI definition of the second; see p. 112 here:

    http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf

    The terminology does seem unusual if you interpret “ground state” to mean “state of lowest energy”; but that term also has another interpretation in this connection, which is basically “all the electrons are in their lowest possible orbital”. The hyperfine splitting is between different possible states of the single electron in the 6s orbital; it’s not due to that electron jumping between that orbital and some other higher orbital.

  25. Me> So I re-read the main text to find out, but I couldn’t find anything about the kernel and its PPS signal. Could you add a sentence or two to clarify this?

    ESR> Some of this is explained in the companion, the GPSD time service HOWTO.

    Thanks for the pointer, and for your explanation after it. If you do not wish to transplant the companion’s explanation to the introduction, may I suggest that you remove kernel PPS from the introduction’s summary table as well? Bringing up a new issue in the summary table, an issue that wasn’t in the text supposedly summarized, confuses the reader. (Well, this reader, anyway.)

  26. Peter Denis> That language appears in the actual SI definition of the second; see p. 112 here:

    Thanks for the reference — but I must respectfully disagree. In your document, SI defines the second in terms of “the transition between the two hyperfine levels of the ground state”. Notice: Plural of “level”, singular of “state”. Also notice that the plural of “state” was the only usage I objected to in Eric’s Introduction. I have no problem with the plural of “level” — indeed, I suggested it myself in one of the replacements I offered.

    And as best I can see, SI supports my view. When I searched your document for the string “ground state”, I got six hits for the singular form “ground state”, none of which was followed by an ‘s’. Searching for the plural, “ground states”, got me a “not found” message.

    So, to expand on what I said in my previous post about this: It really comes down to the level of precision that is appropriate here (or pedantry, if you prefer). Because this is an introduction, my personal preference as a reader is to side-step the finer points of quantum-physical nomenclature by keeping the language informal and simply saying: “electronic transitions in Caesium atoms”. But if Eric does prefer to be precise (or formal, or pedantic…), it’s better that he do it the right way and talk about energy levels (plural) within the ground state (singular).

  27. @Thomas Blankenhorn:
    the plural of “state” was the only usage I objected to in Eric’s Introduction. I have no problem with the plural of “level”

    Ah, I see. Yes, I agree that “state” should be singular, at least as the term would normally be used in physics (and the SI definition appears to use it that way).

Leave a comment

Your email address will not be published. Required fields are marked *