Message-ID: <402C96B5.3010501@virgin.net>
Date: Fri, 13 Feb 2004 09:19:49 +0000
From: "Stewart Bryant" <stewart.bryant@virgin.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <20040210184134.KTHX20454.tomts35-srv.bellnexxia.net@smtp.bellnexxia.net> <402A6646.4030006@virgin.net> <1ArPAc-19FrkH0@fwd00.sul.t-online.com> <001a01c3f1bc$ad30ad60$6507a8c0@Main>
In-reply-to: <001a01c3f1bc$ad30ad60$6507a8c0@Main>
Subject: Re: LF: Timing GPS
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
Sender: <owner-rsgb_lf_group@blacksheep.org>
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Alan Melia wrote:
> Hi Uwe, is it not possible to allow for the delay down the connecting wire
> to the NTP sever. In the days I played TCP/IL over packet the PING facility
> gave the round-trip delay for paths through regenerators, and packet nodes.
> At least that software might be useful for keeping my home network all in
> sync
> 

NTP is not a simple time fetch protocol, it is a clock synchronisation
protocol that polls the master clock at regular intervals.

It does figure out what the RTT is and processes out this error (over
a period of time).


For non-local time servers the error with a 1024s polling interval
seems to be better than 2ms. For a local time server accuracies of
200us with a 64s poll are the norm.

See
http://www.eecis.udel.edu/~mills/database/brief/perf/perf.pdf

- Stewart G3YSX


> Cheers de Alan G3NYK
> alan.melia@btinternet.com
> 
> ----- Original Message -----
> From: "jannsen" <0482183881-0001@t-online.de>
> To: <rsgb_lf_group@blacksheep.org>
> Sent: 12 February 2004 22:18
> Subject: Re: LF: Timing GPS
> 
> 
> 
>>Hi Stewart es All,
>>I do some PC clock synchronizations via internet using the program
>>"Time Watch", downloaded from http://www.blue-series.de. the NTP server
>>transmitting the synchronization signals must be in your vicinity.
>>it is not usefull telling us that their timer is <1uS accurate
>>(in my case dirived from GPS receivings) if there is a long wire to the
>>server. it`s something else if you would know the phase fault on the line
>>and can correct it in some way.
>>
>>reading the PC clock in mSec from the window "Time Decoder" of SpecLab
>>of one PC with the clock (motherboard and sound card) permanent
>>synchronized by the standard time signal station DCF77 and at the
>>same time reading the mSec from the screen of the other PC just
>>clocking by the signals from the internet server, I believe I see
>>a difference, DCF77 in front.
>>
>>be that as it may, we should reach an agreement about what kind of
>>synchronization we will make use of.
>>
> 
> 
> 
> 
>