I think people have a wrong idea of what a modern atomic clock looks like. These are readily available commercially, Microchip for example will happily sell you hydrogen, cesium or rubidium atomic clocks. Hydrogen masers are rather unwieldy, but you can get a rubidium clock in a 1U format and cesium ones are not much bigger. I think their cesium freq standards are formerly a HP business they acquired.
woah hold on a sec. that's not how these clocks are actually used though.
It's a huge huge huge misconception that you can just plunk down an "atomic clock", discipline an NTP server with it and get perfect wallclock time out of it forever. That is just not how it works. Two hydrogen masers sitting next to each other will drift. Two globally distributed networks of hydrogen masers will drift. They cannot NOT drift. The universe just be that way.
UTC is by definition a consensus; there is no clock in the entire world that one could say is exactly tracking it.
Google probably has the gear and the global distribution that they could probably keep pretty close over 30-60 days, but they are assuredly not trying to keep their own independent time standard. Their goal is to keep events correlated on their own network, and for that they just need good internal distribution and consensus, and they are at the point where doing that internally makes sense. But this is the same problem on any size network.
Honestly for just NTP, I've never really seen evidence that anything better than a good GPS disciplined TCXO even matters. The reason they offer these oscillators in such devices is because they usually do additional duties like running PtP or distributing a local 10mhz reference where their specific performance characteristics are more useful. Rubidium, for instance, is very stable at short timescales but has awful long term stability.
> Google probably has the gear and the global distribution that they could probably keep pretty close over 30-60 days, but they are assuredly not trying to keep their own independent time standard.
It is also important to realize that an atomic clock will only give you a steady pulse. It will count seconds for you, and do so very accurately, but that is not the same as knowing what time it is.
If you get a rubidium clock for your garage, you can sync it up with GPS to get an accurate-enough clock for your hobby NTP project, but large research institutions and their expensive contraptions are more elaborate to set up.
Sure, but F2 is a bit more accurate: "As of February 2016 the IT-CsF2 cesium fountain clock started reporting a uB of 1.7 × 10−16 in the BIPM reports of evaluation of primary frequency standards." ( from https://web.archive.org/web/20220121090046/ftp://ftp2.bipm.o... )
Thanks! In such serial articles usually there's link to the end pointing to the next one so, since there wasn't any, thought next one hadn't been written. This one indeed addresses the thesis. The TL;DR, taken directly from the article,
>The core problems I see with Python as a language for data science are call-by-reference semantics, lack of built-in concepts of missing values, lack of built-in vectorization, and lack of non-standard evaluation.
Wouldn't 0402 be 4x larger (if comparing lengths) or 16x larger (if comparing areas), not 2.5x?
Edit: Nevermind, I was wrong. I see now that the sizes don't actually directly correspond to the number codes! 01005 is 0.4mm x 0.2mm and 0402 is 1mm x 0.5mm. That's annoyingly confusing, IMO.
I was a bit outdated with resistor sizing and I don't have a great sources but apparently there are:
inch 0402, 0201, 01005, 009005, 008004, $1
mm 1005, 0603, 0402, 03015, 0201, 01005
these sizes... and $1 is the one in your mind that shall not be written in inches. The "01005 imperial" is just 0402, so it's not going up to the metric 01005 scale or beyond. I think.
https://www.microchip.com/en-us/products/microcontrollers/8-...
reply