On 2011-09-02, Miguel Gon?alves <[email protected]> wrote: > On 2 September 2011 07:56, unruh <[email protected]> wrote: > >> >> Nope. >> >> It is completely unclear to me what your question is. Your 10.0.2.254 is >> an outside switch. > > > I had several questions in my first message. Your assumption is wrong. > > You are telling me that a switch I installed in my rack and defined its many > IP addresses is outside my company? Uau!
I am not telling you anything. I am trying to find out what you are doing. > > 10.0.2.254 is a local as any machine in the 10.0.0.0/8 network. > >>> > $ 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 tells me that your two GPS receivers are consistant with each >> other, but I have no idea why the offset is larger than the delay, and >> why the offsets are so large. On a lan, the offsets should be a factor >> of 20 or so less than what you are getting here. >> That the external router is 7 ms out just tells me that it is really >> poorly synced with the outside world. >> > > I found out the problem and just for the record I'll explain... > > The offset is larger than the delay because NTPd is using 10.0.2.254 (more > on this switch later) as a time source and it shouldn't because it has two > local stratum 1 clocks that are closer (0.170 ms vs 0.583 ms) are show less > jitter. Anyway... to prove my point I removed 10.0.2.254 (the **internal** > switch) from the configuration and here's the result of ntpq -p as of now: > > $ ntpq -p 10.0.2.2 > remote refid st t when poll reach delay offset > jitter >============================================================================== > +10.0.2.10 .GPS. 1 u 889 1024 377 0.179 -0.066 > 0.083 > *10.0.2.9 .GPS. 1 u 391 1024 377 0.166 -0.084 > 0.051 Still far too large an offset. > > Oddly enough, FreeBSD embedded machine with roughly the same NTP > configuration shows better results > > $ ntpq -p 10.0.99.99 > remote refid st t when poll reach delay offset > jitter >============================================================================== > +10.0.2.10 .GPS. 1 u 864 1024 377 0.193 0.025 > 0.301 > *10.0.2.9 .GPS. 1 u 1012 1024 377 0.192 0.030 > 0.004 That is better, but still large. > > Regarding 10.0.2.254 it is an internal switch it is getting time over a > cable connection from several sources Thank you. Why not have it also get its time from your intenal GPS sources? > > $ ntpq -p 10.0.2.254 > remote refid st t when poll reach delay offset > jitter >============================================================================== > -ntp0.as34288.ne .PPS. 1 u 391 1024 377 71.960 -1.029 > 0.270 > *canon.inria.fr .GPSi. 1 u 707 1024 377 55.220 0.199 > 0.700 > +ntp1.inrim.it .CTD. 1 u 359 1024 377 65.860 0.091 > 1.830 > +ntp-p1.obspm.fr .TS-3. 1 u 373 1024 377 55.110 -0.215 > 0.610 > -metasweb01.admi .HBGi. 1 u 992 1024 377 73.290 -5.182 > 0.850 > > I can't control the network at my upstream provider and while my link is not > saturated (far from that) my upstream provider links be could and there's > nothing I can do about it except deploying local time sources as I did. > > I am checking my local time sources with some remote NTP stratum 1 servers > at a fixed interval and plotting the results. I see that once in a while the > offset to external time servers increases and I agree this has to be with > network congestion but this happens at my ISP so there's not much I can do. > >>> > This is a FreeBSD embedded PBX machine running Asterisk. The machine is >> >> > mostly idle. What kind of offsets should I get with local machines? >> >> >> >> in the 10s of usec range max. Certainly less than the delay. >> >> >> > >> > tens of usec is good... Anyone here which can explain why NTP isn't >> getting >> > that? >> >> How could we? >> Maybe you are running a virtual BSD machine, and thus the clocks are >> wonkey. Maybe you have lousy hardware. Who knows. >> > > No lousy hardware here but I think posting detailed hardware specifications > won't help. > > No virtualization here also. > >>> > Assuming ntp04, ntp05 and ntp06 are on the same LAN I see offsets >> higher >> >> > than 100 us. Is it possible to decrease these numbers? >> >> >> >> Sure. all my systems have offsets in the 10us range-- on the same lan >> >> as my time server. >> >> Mind you I do use chrony, not ntpd but even ntpd should be in a few 10s >> >> of usec. >> > >> > >> > Can ntpd really get there? I'll try to query some good public servers to >> see >> > what others are getting... >> >> Sure it can. It can get better than 30us. But why you are not getting it >> is impossible for us to say. > > > > I got it... As you saw above. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
