Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: Re: WSPR and CW - NTP

To: [email protected]
Subject: Re: LF: Re: WSPR and CW - NTP
From: Stewart Bryant <[email protected]>
Date: Tue, 30 Dec 2008 11:43:53 +0000
In-reply-to: <5804028F4B3F4EB48348D8C62C8432B4@JimPC>
References: <[email protected]> <007101c969dd$7d40fdf0$8cd9160a@EFREMOV> <0FA664D5D2F74FFA80C9460AA01B9C78@Silver> <2AAC194CE68E48069E6980FBC3713C88@JimPC> <5804028F4B3F4EB48348D8C62C8432B4@JimPC>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Thunderbird 2.0.0.18 (Macintosh/20081105)

James Moritz wrote:
Dear LF Group,

There is a similar NTP set-up for Windows Vista - see http://www.howtogeek.com/howto/windows-vista/dealing-with-windows-vista-time-sync-problems/ . I am trying it here at the moment, and it seems to work.

Cheers, Jim Moritz
73 de M0BMU





Some other things to think about WRT NTP. You should be less concerned about picking the "best" reference clock on the net than picking
a good clock that has a reliable (i.e. constant delay) path to your
site. So whilst it might be for example tempting to pick the NPL clock, a good clock within the network of your service provider may well be better.

It may be very difficult to figure out what sort of hardware they
are using, but if your ISP is providing the clock from their
router hardware, then you need to take a careful look at the
quality - in general they are not as good as you will get from
a specialist time server. That said, expect major improvements
in the next generation as all of the providers gear up to
service the mobile phone industry (which needs very precise
time and frequency to operate).

One of the biggest errors that you get is with the ADSL link to your
house - cable should be better. This is because NTP takes the path delay (and hence server to client time offset ) to be half the round trip time. The final hop is asymmetric and extremely variable. The new generation cable services should be very interesting in this regard, since they will quite precise time at the STB to work and one has to hope that this will be made available to the user applications.

You might also note that NTP needs to run continuously to get the best out of it. There are two reasons for this. The first is that it learns drift characteristics of the client oscillator over time and makes predictive correction. The second is that it has an algorithm that looks for the packets that appear to arrive with lowest delay compared to the packets it previously received. These packets are interesting because in a packet switching network the packets that have the minimum delay represent a stiff timing edge - the lowest delay packets have been switched by the routers without queuing and hence give the most consistent delay measurement.

Finally I am not sure whether the common O/Ss can support it but
NTP has a way to average the time over a number of servers. I am fairly sure you will get this on any O/S based on UNIX since that is the NTP development group reference platform.

Cheers

Stewart/G3YSX







<Prev in Thread] Current Thread [Next in Thread>