NavList:

   

Reply

I now have three clocks running on my computer, NIST (
http://nist.time.gov/timezone.cgi?Pacific/d/-8/java# ), Navy celnav
website (
http://www.usno.navy.mil/USNO/astronomical-applications/data-services/cel-nav-data
) and the USNO time website that you pointed out (
http://www.usno.navy.mil/USNO/time/display-clocks/simpletime )

 When I refresh both of the Navy clocks they start off one second behind
NIST and drift slower. The celnav website updates every 5 minutes but
always starts one second behind NIST. The USNO website updates every 3
minutes and also starts one second behind NIST. The two Navy sites stay
in lockstep but there may me a several second difference between them
depending how much the first site has drifted when the the second site
updates. After an hour I noticed that the NIST time had advanced a
second compared to my watch which I am sure did not loose a second
during that period. I refreshed the NIST site and it now agrees with my
watch.

So, who do you trust?

I am only looking at this to make sure my watch is set properly which I
usually use WWV to do but I can't receive that here in Europe.

gl

Frank Reed wrote:
>
> Gary, you wrote:
> "it displays the time from the USNO master clock. If you also have
> open the NIST site you can compare the two times. When you first go
> the the Navy site the two times are in agreement but after a short
> while the USNO master clock time runs slow, it is 39 seconds slow
> right now on my computer. If I refresh the Navy site the time is again
> in synchronization.
> Curiouser and curiouser."
>
> The time display on the USNO site uses a simple bit of javascript to
> display the time. It also, most likely, does not do any of the tricks
> like checking round-trip travel time or using UDP which, I think, are
> employed in the java app that you see on the NIST site (despite the
> similarity in name, javascript and java are radically different things).
>
> So why does the USNO clock fall behind? Probably because the coder of
> that javascript tool made a common error (also known as a "less than
> optimal design choice") in creating the clock display on this specific
> web page. There are coding objects usually called "timers." They are
> used in most applications like this that have to update themselves on
> a regular basis. For example, you can set up a timer to "fire" once
> every second to update a display. When this occurs with a clock
> application, you have two choices: take the previously known time and
> add one second to it, OR you can read the system clock (your
> computer's clock in other words) and add to that some offset in
> seconds which was generated when the software first polled the really
> accurate online source. Those might sound like they would yield
> identical results, but the first depends on those timer events
> occurring at exact one second intervals. But they don't do that. A
> software clock programmed to update that way will drift rather
> quickly. Instead you have to rely on the local built-in clock to get
> some time with an error determined on launch. A third approach would
> be to re-poll the accurate online source at some short interval, maybe
> once a minute. I suspect that the USNO javascript on that web page
> does this eventually but the interval may be over an hour.
>
> Update since I wrote the above: I've just discovered another USNO
> online clock, probably implemented by a different programmer or maybe
> by the same folks a few years later, that does exactly this third
> option. It's located here:
> http://www.usno.navy.mil/USNO/time/display-clocks/simpletime
> and it re-polls the exact time once every three minutes thus avoiding
> the drift problem.
>
> With modern GPS-equipped smartphones and similar small computers,
> there's still another option. It's possible to write applications (and
> they do exist) which request the GPS fix time from the GPS hardware
> along with the position data. That can then be displayed with an
> accuracy of some small fraction of a second depending on the
> processing time of the code. I've experimented with this on an Android
> phone (Android is an operating system developed primarily by Google
> and used on huge numbers of new smartphones ...as Windows is to
> Macintosh, Android is to iPhone). The standard system time displayed
> through the usual clock applications on these devices is accurate to
> about 15 seconds which is good enough for most phone users, but you
> can bypass that close-enough time and get at the more accurate GPS
> time using various freely-available apps. The same should be true on
> iPhones and other iOS devices, but I haven't actually yet.
>
> -FER
>
>
> ----------------------------------------------------------------
> NavList message boards and member settings: www.fer3.com/NavList
> Members may optionally receive posts by email.
> To cancel email delivery, send a message to NoMail[at]fer3.com
> ----------------------------------------------------------------
>

   

Reply