[ntp:questions] Trying to use Dimension 4 time keeper

unruh unruh at invalid.ca
Sat Sep 14 23:06:28 UTC 2013


On 2013-09-14, David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> On 14/09/2013 17:56, unruh wrote:
> []
>> Well, no. The offset tells you what the difference is between the time
>> as measured from that remote server and the time on your system. If the
>> path is completely symmetric, then that time time is also the remote
>> servers best estimate of UTC (and depending what its stratum is, that
>> could be pretty far off). But if the delay is assymetric then that
>> estimate is out by half that assymetry. Thus the lower the offset, the
>> nearer your machine is to its own best estimate is of UTC based on its
>> measurement. But ntp works hard to make that offset zero. In fact that
>> is its whole purpose. Thus that offset should fluctuate around zero over
>> the long term, because the estimate of UTC fluctuates (due to
>> assymetries, and errors upstream)
>
> Understand that I meant the lower the magnitude of the offset, not its 
> signed value.  I would have hoped that would have been obvious.

But even that does not help. If your outgoing message to the ntp server
goes from California to New York via Kansas, and the return consistantly
goes via the moon, your computer will always be about 2 seconds behind
UTC, even if the offset is always 0.
Over a long time, the fluctuations in the offset will give a good idea
of what the random fluctuations are, and what the random errors are in
the time on your machine. But they tell you nothing about the systematic
errors. And the instantanous offset tells you  little as well-- your
computer could just have done a huge job which heated it up, and made
the crystal oscillate faster. Over time that should average out. But
that is only over time. (and it could be that you carry out hot jobs
every day at 2PM, and thus every day between two and 5 your computer
will be faster than and displaced to the future of UTC.


>
> []
>>> The Linux box
>>> could be as simple as the Raspberry Pi card PC, and even adding a GPS to
>>> that only adds ~US $35 to the cost.
>>
>> And some hacking-- both rewiring the gps and rewiring the RPi and
>> installing GPIO input interrupt software.
>
> Yes, you do need to connect the two units together, but no "rewiring" is 
> required.  You can use just four wire jumpers (which you can buy, even 
> as part of a ribbon cable if you want a neater looking job) to connect 
> the pins on the Adafruit module to the appropriate GPIO pins on the 
> Raspberry Pi.  The Adafruit unit includes a pin for the PPS output, and 
> has the correct voltage levels for the Raspberry Pi.  I did choose to 
> solder the wires at the Adafruit end in this installation:
>
>    http://www.satsignal.eu/ntp/RaspberryPi-2-with-Adafruit-GPS.jpg
>
> but I could have used jumpers instead.

I was probably refering to the Sure unit which is more difficult. 
I have never looked at the Adafruit module. Also doesn't the Adafruit
also require an extra antenna to work properly?

>
> As the Pi comes without an OS installed, you need to do that 
> installation in any case.  The additional software is easiest if you use 
> the "user-mode" PPS software, and just a few commands are then required, 
> all detailed here:
>
>    http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode
>
> This is but a small addition to the time taken for the installation and 
> configuration of Linux on the Raspberry Pi.  Performance is shown here:
>
>    http://www.satsignal.eu/mrtg/raspi4_ntp.html
>
> and may be quite adequate for many purposes, especially as a source of 
> local stratum-1 time for a collection of Windows PCs, which was my 
> suggestion to the OP.



More information about the questions mailing list