Re: [time-nuts] Cheap jitter measurements
Tom Van Baak wrote on Sun, 8 Apr 2018 at 12:36:52 -0700 in <55EB8D26CCDC4B1ABFBC53F95E4C0557@pc52>: > My mental model of a black box computer running NTP ... > Imagine the black box has two BNC connectors; one accepts an input > pulse to be timed; one outputs a pulse at certain times. Theory runs into reality. The problem is that NTP is easy to set up to do the former, and hard to set up to do the latter. Where "easy" means "it's commonly done" and "hard" means "I'm not aware that it's ever done" (not that I'm so expert that I would necessarily know if it were). > To me this better than relying on NTP to tell you how NTP is doing, > which as far as I can tell from live plots on the web, is all that > most people do. Instead use real, external, physical > measurement. The internal NTP stats are fine for tracking the > performance of the PLL, but don't confuse that with actual timing. One of the things that NTP does is it reports on its status with respect to other NTP peers. Yes, this is still "internal" to the "NTP universe," but it's also external to the device you have in front of you. For instance, my ntp server currently reports that it is offset between .6 and 2.1 millisecon ds from 7 ntp peers it is talking to, and there's at least some reason to think these are not particularly correllated. That gives me reason to infer that my server's clock is probably not off by more than a few milliseconds. (This is not sub-ns timing, of course. It's intended to be illustrative. And for a variety of reasons this particular server's network connection is a bit unstable, so most NTP users can probably do a lot better.) Yeah, that's not truly reliable, like I was comparing it to a truly external reference, but it's also not as meaningless as staring at internal parameters. Indeed, one way in practice that ntp people measure ntp is to wire up an external reference to the "input BNC" of your black box, instruct the ntp server to monitor that PPS input but not use it in the clock monkeying algorithm, and then compare what NTP reports for the local clock with what it reports for other NTP peers. --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] On the IETF leap-seconds.list SHA1
Umm, the presence of a copy of the IANA TZ distribution at https://www.ietf.org/timezones/ is not evidence of an "IETF leap-seconds list." This is bizarre, and probably a web server configuration error that even exists. The IETF is not involved in this list. I guess this shows why Google is an unreliable indicator of authority. https://www.ietf.org/timezones/data/leap-seconds.list is not a URL anyone should be depending on. https://data.iana.org/time-zones/code/leap-seconds.list is perhaps a better URL for the file in the tz distribution, but I'd hestitate to call it canonical. Start at https://www.iana.org/time-zones. But then the tz database isn't an authorative source, either. Per the NEWS file: The 'leapseconds' file is now generated automatically from a new file 'leap-seconds.list', which is a copy of <ftp://time.nist.gov/pub/leap-seconds.list>. A new source file 'leapseconds.awk' implements this. The goal is simplification of the future maintenance of 'leapseconds'. That is, it's just a copy of NIST's file. Your email would make a lot more sense if you had included the URLs directly rather than referring to your source code and output file that happen to contain them. --jh...@mit.edu John Hawkinson Anders Wallin wrote on Wed, 20 Dec 2017 at 13:51:21 +0200 in : > So I'm doing the typical Wednesday thing you might do, that is writing a > small script for checking the SHA1 checksum in leap-seconds.list files. > I came up with [1] which produces output [2]. ... > For the IETF file there seems to be one byte, a "0" at the start of the > third group of 8 hex characters missing. > > This is somewhat funny/alarming, since the IETF leap-seconds.list is the > first thing that shows up (at least for me) on google when looking for > leap-seocnds.list. ... > [1] > https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/leap_sha.py > [2] > https://github.com/aewallin/leap-seconds.list_sha1_check/blob/master/output.txt ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Weird GPSDO behavior
I would have thought the easy test is to run the GPSDO on battery power (perhaps with a UPS). Maybe that's not so easy? --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Ships fooled in GPS spoofing attack suggest Russian cyberweapon
So, what I wonder: to what extent (if any) are GPS, GLONASS, and Galileo sufficiently different that it is challenging to spoof all three in the same way? Is there any reason why it is more than 3 times the work to spoof all 3? Is there something clever receivers can do, with awareness of all three services, that makes them harder to spoof (beyond checking the services against each other)? --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Can Lady Heather set PC time directly from aTrimbleThunderbolt?
David J Taylor via time-nuts wrote on Fri, 4 Aug 2017 at 17:18:12 +0100 in <90765FA83DAC4C7EAA06F9A781AA5906@Alta>: > BTW: you refer to "GPS time". Not my area of expertise, but GPS > time and UTC aren't the same - GPS time doesn't use leap-seconds, > for example, so it's many seconds off from NTP. We've been though this before, but I'll say it again. This is not a very helpful thing to say. "GPS time" is a very bad phrase to use, because it can mean "UTC derived via GPS," which is what most people mean. This accounts for leap seconds as most people expect. It is what essentially all consumer GPS receivers will display. But "GPS time" can also mean "GPS system time," the internal time used by the GPS system that does not include leap seconds. It is extremely rare that anybody means this, but it does happen (esp. on time-nus). And many GPS receivers can be convinced to display GPS system time. So, please don't say "GPS time," because it is ambiguous. But please also don't suggest that when people say "GPS time" they must mean "GPS system time," because they rarely do and it's just an unnecessary bit of confusion. --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] more of a time distribution question
Hal Murray wrote on Thu, 30 Mar 2017 at 13:43:34 -0700 in <20170330204334.18a8d406...@ip-64-139-1-69.sjc.megapath.net>: > That should work too. I don't know much about the Mac environment. If it's > running a normal-enough ntpd it is already a server and you don't have to do > anything. If not, you will have to build/install your own and/or poke holes > in the firewall rules. It is worth noting that the ntpd that Apple ships is kind of bizarre, and it does not actually adjust the clock on the Mac. (Instead it writes to the drift file -- or at least it is supposed to -- and an Apple process called "pacemaker(8)" readthe drift file and tries to maintain the systme clock. In my experience (only through Yosemite -- 10.10) this mechanism was horribly broken and did not maintain my laptop's system clock in any useful way.) This probably doesn't actually affect the intended use (as the goal is to keep machines in sync, not to keep them accurate), but anyone who messes with ntpd under OS X should be aware that it is "weird." Building the stock ntpd under OS X works just fine, and I recommend that for anyone who wants to tinker with ntp under OS X. --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Smart Phone time display accuracy...?
Chris Albertson wrote on Fri, 17 Mar 2017 at 14:38:17 -0700 in : > > AndroiTS GPS Test (V 1.48 Free) is good, but a battery hog I find. On > THIS is why the phones don't really track time so well. Not that they > can't but doing so requires battery power. This statement doesn't seem to be well-supported. I think it's basically untrue if we're talking about timing at the tens of millisecond level. Anything more precise seems relatively useless in a smartphone without specialized mechanisms to get the time off of the phone. A phone's GPS receiver takes a lot of battery. But GPS is not the primary mechanism that phones use get their time. They get time from the cellular phone network (whether from the layer two timing information or at a higher layer with something like NTP). The effort required to keep a phone's clock in sync, even with a really bad local oscillator, is lost in the noise of all the other things the phone has to do. It's just not a battery issue. The only reason modern smartphones keep bad time is because their designers can't be bothered to do better, or possibly the network is providing "bad" time to the phone. (Unless I'm missing something.) --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Smart Phone time display accuracy...?
There is a lot of...problematic...advice here. For instance:
Gary Woods wrote on Thu, 16 Mar 2017
at 18:09:26 -0400 in :
> Not to gloat, but my Android phone is always spot on. I have a GPS
> time app that shows the difference between GPS and phone time and
> it's always in the tenths of a second area.
Notice Gary doesn't specify which brand of Android phone, much less
the specific model and carrier. This matters...a lot.
For instance, my Verizon Samsung Galaxy S7 is regularly off by 300-700ms,
and sometimes off by more than a second. A colleague's cell phone
is regularly off by about 10 seconds. On the other hand, another colleague's
Nexus {i forget what model} seems good to 10 ms.
It's not clear to me how Android phones set their own time from the
cell network, but I think the actual answer is "in many cases, not
very well."
The "ClockSync" android app will compare your phone's time to NTP,
which does a pretty decent job.
The "GPS Time" and other similar apps will compare your phone's time to
UTC as derived from your phone's GPS receiver, although I think this is
necessarily imprecise not only because of multipath but because of software
issues between the GPS receiver and the phone. *handwave*
I can't speak for iPhones, but for Android phones, it's really
extremely hit-or-miss, and highly variable, both between models and
even with a given phone from day to day. And if your threshold is
something like half a second, you might think your phone is always
good enough, and then have a rude awakening (I did!) when one day it's
off by >1 second.
--jh...@mit.edu
John Hawkinson
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] wifi with time sync
This has nothing to do with time-nuts, can it stop please? [ I don't know what forum to send you to for "weird wifi problems"; there is probably no good one, because it is a very common consumer problem :( ] NTP was mentioned because you (Bob Camp) had not defined the problem very well, and asked some questions that it can solve. It will not help spot an instanteous failure; it will help characterize the delay of your network, and do so over fairly long time averages. It seems pretty clear that nobody knows much about the protocol discussed at CES, and probably most people have stopped reading this thread because it is discussing something else entirely (...). So we can probably just stop there. However: I do not think your use of the word "overlay" is one that makes sense. Typically things that are overlays increase overhead rather than reduce it. Similarly, buffering causes delays which reduce the ability to get precise timing, they do not help it. So while we can't say with much certainty what a "magic protocol" is, it is surely not "giant buffers." I tried to engage with you off-list and give you some pointers on this, but that does not seem to be working. Consumer wifi driver problems are manifestly inappropriate for this list, and trying to do both at once leads to gross confusion :( I know this is my personal opinion and I don't speak with any authority. --jh...@mit.edu John Hawkinson Bob Camp wrote on Sat, 14 Jan 2017 at 10:46:16 -0500 in <3ee57dee-3d6e-438b-9d1f-c2bc216c6...@n1k.org>: > Ok, what I see is that every few hours, I get a “rogue delay” on a > single ping. How would NTP help me spot a single transit with a 250 > ms round trip and identify the time it occured? Keep in mind that > NTP is going to throttle back to a very low level of “chat” quite > quickly….. > > While this *is* getting far more into my WiFi (which I had no real > intention of doing) it does apply to timing and running audio over > WiFi as well. The basic transport as it runs up through the various > layers is *not* very good time wise. There is indeed a real need for > some sort of overlay to take care of that issue. I’d still love to > know if this magic protocol is simply giant buffers and some sort of > tagging or if they do something more interesting. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] wifi with time sync
Bob Camp wrote on Fri, 13 Jan 2017 at 15:35:19 -0500 in : > What standard protocol would you recommend I run from the command > line on my computer to get a quick estimate of the timing lag and > variablilty on my particular WiFi connection? Bob: I hope you read the whole of my message, rather than just the short upper part you quoted. I said "I'm not aware of a tool that does this today" -- I don't think there is a good answer. ==> There isn't one. <== You can certainly use ping to get a gross upper bound. But rememnber it's a gross upper bound, and the underlying technology can do much better. As Chris said, ntp will do a good job telling you the delay between two hosts (that are running ntp and talking to each other) by sending a lot of samples and averaging over time. But what is your application here? You haven't made it clear. Ping is not representative of what you could get with a wifi using a new technology, which was what was how this thread started, and so the context some of the anwers (esp. mine) are in. Ping is representative of other things, though. --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] wifi with time sync
Can we please stop talking about pings? Bob Camp wrote on Fri, 13 Jan 2017 at 15:12:38 -0500 in : > I’m sure you are right about the response time. Right now the > variation is running almost 3 ms at one sigma on a ping so there is > a lot to do simply to get the accuracy anywhere near 1 us. Using ping remains deeply problematic as a measure of what is possible. The underlying layer does retransmissions and inserts delays. And ping measures around those things, not within them. But any real tool that was using the wireless frames for timing would be measuring the raw layer 2 frame timing. (It's not apparent that this would require hardware timestamping support, although that can certainly help.) This sort of thing is doable with today's hardware and software technology. Although I'm not aware of a tool that does this today (but building one is not hard). Denny Page's comment about hosts not prioritizing responding to ICMP is...IMO misleading. That's not really what happens. When you ping a switch, think of the switch as a network switch with a small computer (host) attached that handles mangement functions, like responding to pings. They are entirely decoupled, and the load on the management computer is not related to the load on the network, and sometimes it's really slow. That makes the claim about priority effectively true for network equipment, but it's not generally true for *hosts*. Most hosts will indeed respond to ICMP rapidly (in the kernel) without prioritizing it any differently from other packets. Except the other kinds of packets often require leaving kernel space (e.g. application processes) which ncessarily induces more delay. But anyhow, the upshot is correct: don't trust pings to switches, but pings to idle hosts will be much more meaningful. But still not meaningful on wireless networks. So...can we please stop talking about pings? Thanks. --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Using GPSDO as a Refrence for Protable Amateur Radio Microwave Operations
Chris Albertson (and Bob Camp ): > Why to people always build 10MHz GPSDOs? Because "a lot" (...) of amateur radio microwave equipment is designed off the shelf to accept an external 10 MHz input. [And other kinds of equipment, too.] If you're not designing from the ground-up, then it makes a lot of sense. --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Temp/Humidity control systems?
jimlux wrote on Thu, 27 Oct 2016 at 07:51:37 -0700 in : > (and frankly, if someone made something that opened/closed my > windows, I'd love that too, for the same reason. http://www.mcmaster.com/#motorized-louvers/=14s2pox --jh...@mit.edu John Hawkinson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NIST UT1 NTP server results
I have to wonder if it's really such a great idea to have this as an open NTP server without huge red flags that it is not UTC. One could imagine it leading to big problems if some people started syncing to it without undersatnding that it was. Has there been thought to at least setting the reference ID to 'UT1' instead of 'NIST' (or maybe 'NUT1' since 'NIST-UT1' is too long?). With respect to interpolation and soforth, it seems like a lot of NTP cares more about frequency than offset, and all this stepping presumably wreaks havoc with the frequency? Maybe I'm wrong though... --jh...@mit.edu John Hawkinson Tom Van Baak wrote on Fri, 22 Jul 2016 at 15:14:26 -0700 in <60BA6696E49A4C4FA9F6B5792176F81A@pc52>: > > The current algorithm on the server uses the UT1 offset from > > Circular A with no interpolation. The value changes at 0 UTC every day. > > I did not use any interpolation because the difference in the dUT1 > > value from one day to the next is on the order of 1-2 ms, and I > > considered that it was likely that the jitter and asymmetry of the > > network connection to a typical user would limit the accuracy to a > > larger value anyway so that interpolation would not actually improve > > anything. However, I will certainly consider changing this. It would not > > be a big deal to add interpolation if there were some good reason for > > doing so. > > > > Best wishes, > > > > Judah Levine ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] [LEAPSECS] NIST UT1 NTP server results
"Mike" wrote on Fri, 22 Jul 2016 at 22:21:08 +0200 in : > You will also note from the NIST document and the NIST time server > address links, that the UT1 NTP service will not respond to > unregistered requests. NIST may or may not have opened the box > deliberately. I don't know, but if you wish to use the service > please at least contact Judah before doing so. It would be a shame > to have it going deaf. On June 28, Judah Levine and NIST announced via the IERS Message list that NIST's UT1 ntp-based time service would be open access beginning in July 2016. Announcement reproduced below. I found your email fairly confusing. --jh...@mit.edu John Hawkinson Message-ID: <25948628.481467094028650.javamail.cmad...@gsb50ml1.ffm.web> Date: Tue, 28 Jun 2016 08:07:08 +0200 From: To: Subject: IERS Message No. 303: NIST UT1 Internet Time Service IERS Message No. 303 June 28, 2016 NIST UT1 Internet Time Service The Time and Frequency Division of NIST operates an Internet time server that transmits UT1 time in the Network Time Protocol (NTP) format. The server is synchronized to UTC(NIST) by a direct connection to a local cesium standard. The offset between UT1 and UTC is added to the reply to a query for the time. The time difference between UT1 and UTC is obtained from IERS Bulletin A, and the value used by the time server changes every day at 0 h UTC. The time step at 0 h UTC is generally about 1-2 ms. This time step is generally too small to be detected by most users. The accuracy of the time at the server is approximately 4 ms, and is determined by the uncertainty in the prediction of the difference UT1-UTC in the IERS Bulletin A. The accuracy of the time received by a user will usually be limited by the stability of the network delay from the user's system to the time server. The overall accuracy of the time as received by a user will generally be better than 10 ms, and will often be significantly better than this value. The name of the server is ut1-time.colorado.edu and its address is 128.138.140.50. The ut1 time service is currently restricted to users who register with NIST (by e-mail to Judah.levine [at] nist.gov), but it will be converted to open-access in July, 2016. The NIST is the US National Institute of Standards and Technology (http://www.nist.gov/). Questions or comments to Judah.Levine [at] nist.gov IERS Messages are edited and distributed by the IERS Central Bureau. If not stated otherwise, the IERS is only the distributor of the message and is not responsible for its content. To submit texts for distribution and to subscribe or unsubscribe, please write to . Archives: http://www.iers.org/Messages/ ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
