On 2011-09-01, Miguel Gon?alves <m...@miguelgoncalves.com> wrote:
> Hi!
>
> Thanks for your reply. My comments bellow.
>
> On 1 September 2011 18:24, unruh <un...@wormhole.physics.ubc.ca> wrote:
>
>> On 2011-09-01, Miguel Gon?alves <m...@miguelgoncalves.com> wrote:
>> > Hi all!
>> >
>> > I have two internal FreeBSD with GPS receivers attached (Garmin 18 LVC:
>> > 10.0.2.10 / Sure Evaluation Board:10.0.2.9). Both machines are on the
>> same
>> > LAN segment (VLAN).
>> >
>> > For redundancy, I've configured a Cisco switch as a stratum 2 server.
>> Here's
>> > the relevant information:
>> >
>> > $ ntpq -pcrv 10.0.2.254
>> >      remote           refid      st t when poll reach   delay   offset
>> >  jitter
>>
>> >==============================================================================
>> > +ntp0.as34288.ne .PPS.            1 u  814 1024  377   72.750   -1.084
>> > 0.780
>> > +canon.inria.fr  .GPSi.           1 u  399 1024  377   55.110    0.218
>> > 0.400
>>
>> What are those machines? You have names rather than IP addresses.
>> Are they your pps machines?
>
>
> No. This is a stratum 2 server and it gets the time from stratum 1 servers
> thus the names and not IP addresses.
>
> > I have another machine (Linux, CentOS 5.6) that is a client to these
>> stratum
>> > 1 FreeBSD machines. Here's the relevant information:
>> >
>> > $ ntpq -pcrv 10.0.2.2
>> >      remote           refid      st t when poll reach   delay   offset
>> >  jitter
>>
>> >==============================================================================
>> > +10.0.2.10       .GPS.            1 u  211  256  377    0.159   -0.139
>> > 0.350
>> > *10.0.2.9        .GPS.            1 u   71  256  377    0.166   -0.136
>> > 0.468
>>
>> That is a huge offset for being on the same lan, and for being only
>> .15ms away.
>
>
> It's really strange... I am getting on another LAN connected to this one
> these values...
>
> $ ntpq -p 10.0.99.99
>      remote           refid      st t when poll reach   delay   offset
>  jitter
>==============================================================================
> *10.0.2.10       .GPS.            1 u   21  256  377    0.173    0.196
> 0.008
> +10.0.2.9        .GPS.            1 u   93  256  377    0.175    0.191
> 0.014
> +10.0.2.254      81.94.123.16     2 u  149  256  377    0.583   -6.884
> 0.152
>
> This is a FreeBSD embedded PBX machine running Asterisk. The machine is
> mostly idle. What kind of offsets should I get with local machines?

Again, strange. That machine source 10.0.2.254 obviously has a clock
that is 6ms off. But why it is it not losing out on the selection
algorithm I do not know, since it clearly does not overlap the other two
sources. I cannot remember if the "delay" is the round trip delay or 1.2
of that. Again, having your offset be larger than your delay indicates
that something is pulling your machine off of the "correct" time. Even a
hugely assymetric roundtrip should not do that. 


>
> Here in Portugal our Time Dissemination Authority has two stratum 2 servers.
> One of them shows this:
>
> $ ntpq -p ntp02.oal.ul.pt
>      remote           refid      st t when poll reach   delay   offset
>  jitter
>==============================================================================
> *ntp01.oal.ul.pt .GPS.            1 u  113  128  377    5.125   -0.263
> 0.320
>  ntp03.oal.ul.pt .INIT.          16 u    - 1024    0    0.000    0.000
> 0.000
> -ntp04.oal.ul.pt 194.117.9.138    2 u   57  128  377    0.377   -0.056
> 0.080
> +ntp05.oal.ul.pt .GPS.            1 u   62  128  377    0.296    0.128
> 0.058
> +ntp06.oal.ul.pt .IRIG.           1 u   56  128  377    0.310    0.104
> 0.045
>
> Assuming ntp04, ntp05 and ntp06 are on the same LAN I see offsets higher
> than 100 us. Is it possible to decrease these numbers?

Usually yes. 


>
>> tick# ntpdate -p8 -q tock
>> > server 10.0.2.9, stratum 1, offset -0.000004, delay 0.02577
>> >  1 Sep 10:23:45 ntpdate[3537]: adjust time server 10.0.2.9 offset
>> -0.000004
>> > sec
>>
>> That probably says more about the symmetry of the path than the offset
>> of the machine.
>
>
> OK. But this is a 24 port Gigabit switch from Cisco. I wouldn't expect
> asymmetry but it could be.

Actually Gigabit tends to be really horrible for timekeeping. It has a
tendency to save packets so a bunch can be sent at once. While good for
network efficiency, it is horrible for ntp. My timekeeping on my
machines went to hell (relatively speaking) when we switched to Gigabit
switches. It used to be that I had completely consistant .14 ms delay
roundtrips between local clocks. Now I get .14, .28, and sometimes over
10ms delays on one machine. (Gbcard->Gb switch->100Mb card on the
server)
Look at the delays you see in the peerstats and plot them out. 

>
> > Are my GPS clocks OK? Does this happen due to the network latency? Are my
>> > stratum 2 servers OK?
>>
>> Your GPS seems to be consistant with each other ( that is all one can
>> say without another time source to compare them to). Your offsets are
>> large compared with the delay times ( was the machine recently heated
>> up due to working harder?)
>
>
> All these machines sit in a room temperature controlled at 20 ?C. 10.0.2.2
> is a backup server that just does some work every hour but nothing huge.
>
> 10.0.2.2 has been running for quite a while and it doesn't seem to get lower
> offsets. Could it be because it's running Linux? I've heard Linux is not as
> good as FreeBSD for time keeping.
>
> Thanks!
>
> Regards,
> Miguel

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to