Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
two machines syncing to the same master - hardware issues?
23 views
Skip to first unread message
matthew...@gmail.com
May 30, 2013, 2:18:05 PM5/30/13
to
I have two servers in the same physical location that are syncing to the same two NTP servers. My understanding is that these NTP servers are in the same building as my servers, and we are connected via an in-building connection. In other words, network jitter should be reasonably low (at least compared to the Internet, for example).
My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
Oldbox has been used as our company's central NTP server for many years. But the machine is not dedicated to this purpose: it performs other business functions that are erratic in nature. So we procured newbox to act as a poor-man's dedicated NTP server. In other words, newbox does nothing but NTP.
What we've found is that newbox generally has a much larger offset to its NTP peer, compared to oldbox. Likewise, newbox's offset also varies much more over time.
I'm measuring the offset via "ntpdate -q <peer ntp server>"
I rebooted newbox yesterday, and it has taken about 20 hours for newbox's offset to be in line with oldbox's. And based on observation, I'm not so sure it will stay this way.
Is it possible there is a hardware problem with newbox? I don't really understand NTP well enough to know where to start looking.
I guess a related question is, what kind of offset can I realistically expect in such a situation? It seems like on oldbox the offset is consistently under 100 microseconds.
Thanks,
Matt
My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
Oldbox has been used as our company's central NTP server for many years. But the machine is not dedicated to this purpose: it performs other business functions that are erratic in nature. So we procured newbox to act as a poor-man's dedicated NTP server. In other words, newbox does nothing but NTP.
What we've found is that newbox generally has a much larger offset to its NTP peer, compared to oldbox. Likewise, newbox's offset also varies much more over time.
I'm measuring the offset via "ntpdate -q <peer ntp server>"
I rebooted newbox yesterday, and it has taken about 20 hours for newbox's offset to be in line with oldbox's. And based on observation, I'm not so sure it will stay this way.
Is it possible there is a hardware problem with newbox? I don't really understand NTP well enough to know where to start looking.
I guess a related question is, what kind of offset can I realistically expect in such a situation? It seems like on oldbox the offset is consistently under 100 microseconds.
Thanks,
Matt
David Taylor
May 30, 2013, 3:47:44 PM5/30/13
to
On 30/05/2013 19:18, matthew...@gmail.com wrote:
> I have two servers in the same physical location that are syncing to the same two NTP servers. My understanding is that these NTP servers are in the same building as my servers, and we are connected via an in-building connection. In other words, network jitter should be reasonably low (at least compared to the Internet, for example).
>
> My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
>
> Oldbox has been used as our company's central NTP server for many years. But the machine is not dedicated to this purpose: it performs other business functions that are erratic in nature. So we procured newbox to act as a poor-man's dedicated NTP server. In other words, newbox does nothing but NTP.
>
> What we've found is that newbox generally has a much larger offset to its NTP peer, compared to oldbox. Likewise, newbox's offset also varies much more over time.
[]
> I have two servers in the same physical location that are syncing to the same two NTP servers. My understanding is that these NTP servers are in the same building as my servers, and we are connected via an in-building connection. In other words, network jitter should be reasonably low (at least compared to the Internet, for example).
>
> My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
>
> Oldbox has been used as our company's central NTP server for many years. But the machine is not dedicated to this purpose: it performs other business functions that are erratic in nature. So we procured newbox to act as a poor-man's dedicated NTP server. In other words, newbox does nothing but NTP.
>
> What we've found is that newbox generally has a much larger offset to its NTP peer, compared to oldbox. Likewise, newbox's offset also varies much more over time.
For a central server I would hope that you are using a really good clock
- such as the PPS signal from a GPS making that server stratum-1. I see
offsets usually less than 10 microseconds.
The current NTP is 4.2.6, and I am using the development version
4.2.7p368 on all of my PCs.
--
Cheers,
David
Web: http://www.satsignal.eu
unruh
May 30, 2013, 6:41:46 PM5/30/13
to
On 2013-05-30, matthew...@gmail.com <matthew...@gmail.com> wrote:
> I have two servers in the same physical location that are syncing to the same two NTP servers. My understanding is that these NTP servers are in the same building as my servers, and we are connected via an in-building connection. In other words, network jitter should be reasonably low (at least compared to the Internet, for example).
>
> My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
Why?
> I have two servers in the same physical location that are syncing to the same two NTP servers. My understanding is that these NTP servers are in the same building as my servers, and we are connected via an in-building connection. In other words, network jitter should be reasonably low (at least compared to the Internet, for example).
>
> My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
>
> Oldbox has been used as our company's central NTP server for many years. But the machine is not dedicated to this purpose: it performs other business functions that are erratic in nature. So we procured newbox to act as a poor-man's dedicated NTP server. In other words, newbox does nothing but NTP.
>
> What we've found is that newbox generally has a much larger offset to its NTP peer, compared to oldbox. Likewise, newbox's offset also varies much more over time.
Plot the offset vs time from the peerstats file. You might discover that
your understanding is wrong.
>
> I'm measuring the offset via "ntpdate -q <peer ntp server>"
every few minutes already.
>
> I rebooted newbox yesterday, and it has taken about 20 hours for newbox's offset to be in line with oldbox's. And based on observation, I'm not so sure it will stay this way.
>
> Is it possible there is a hardware problem with newbox? I don't really understand NTP well enough to know where to start looking.
something on the box is resetting the clock behind ntpd's back.
>
> I guess a related question is, what kind of offset can I realistically expect in such a situation? It seems like on oldbox the offset is consistently under 100 microseconds.
servers get their time from gps. If not, the servers themselves can be
woggling all over the place.
Rick Jones
May 30, 2013, 8:11:33 PM5/30/13
to
unruh <un...@invalid.ca> wrote:
> On 2013-05-30, matthew...@gmail.com <matthew...@gmail.com> wrote:
> > My two machines are somewhat different: "oldbox" is running NTP
> > 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as
> > ships with RedHat 6.3.
^^^^^^^^^^
> On 2013-05-30, matthew...@gmail.com <matthew...@gmail.com> wrote:
> > My two machines are somewhat different: "oldbox" is running NTP
> > 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as
> > ships with RedHat 6.3.
> > Is it possible there is a hardware problem with newbox? I don't
> > really understand NTP well enough to know where to start looking.
> It is possible. What operating system is on newbox? And it could be
> that something on the box is resetting the clock behind ntpd's back.
memory but I believe it is a variation on the 2.6.38 kernel. Actually
checking online shows that to be a mistake - it is a 2.6.32 kernel:
http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_6
2.6.38 may have been in one of the Ubuntu distributions.
rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
matthew...@gmail.com
May 31, 2013, 9:36:39 AM5/31/13
to
On Thursday, May 30, 2013 5:41:46 PM UTC-5, unruh wrote:
> > My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
>
> Why?
Because oldbox has a lot of other custom functions that haven't been validated against the newer OS. newbox does only NTP, so we're not stuck with the older version.
> > My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
>
> Why?
> Plots would be good.
> Plot the offset vs time from the peerstats file. You might discover that
> your understanding is wrong.
> > I'm measuring the offset via "ntpdate -q <peer ntp server>"
>
> Very silly way of doing it, esp since your machine measures the offset
> every few minutes already.
> > Is it possible there is a hardware problem with newbox? I don't really understand NTP well enough to know where to start looking.
>
> It is possible. What operating system is on newbox? And it could be that
> something on the box is resetting the clock behind ntpd's back.
How can I determine if something else is messing with the clock?
> You can expect offsets of the order of 10-20microseconds IF the ntp
> servers get their time from gps. If not, the servers themselves can be
> woggling all over the place.
Thanks again.
matthew...@gmail.com
May 31, 2013, 9:40:32 AM5/31/13
to
On Thursday, May 30, 2013 7:11:33 PM UTC-5, Rick Jones wrote:
> RedHat 6.3 ships with a version of the Linux kernel. I am going from
> memory but I believe it is a variation on the 2.6.38 kernel. Actually
> checking online shows that to be a mistake - it is a 2.6.32 kernel:
Yes, it is a 2.6.32-based kernel. But in general, I've found Redhat kernels to be "Frankenstein" kernels. Redhat is constantly back-porting features from newer kernels.
> RedHat 6.3 ships with a version of the Linux kernel. I am going from
> memory but I believe it is a variation on the 2.6.38 kernel. Actually
> checking online shows that to be a mistake - it is a 2.6.32 kernel:
David Lord
May 31, 2013, 10:22:18 AM5/31/13
to
matthew...@gmail.com wrote:
> On Thursday, May 30, 2013 5:41:46 PM UTC-5, unruh wrote:
>>> My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
>> Why?
>
> Because oldbox has a lot of other custom functions that haven't been validated against the newer OS. newbox does only NTP, so we're not stuck with the older version.
>
>
>> Plots would be good.
>> Plot the offset vs time from the peerstats file. You might discover that
>> your understanding is wrong.
>
>
> Currently I'm not generating a peerstats file, but will change that after business hours this evening.
>
>>> I'm measuring the offset via "ntpdate -q <peer ntp server>"
>> Very silly way of doing it, esp since your machine measures the offset
>> every few minutes already.
>
> Where can I access this information? I assume from the peerstats file? Or is there another mechanism for querying this pre-existing data?
There is a mass of documentation with most of ntpd
> On Thursday, May 30, 2013 5:41:46 PM UTC-5, unruh wrote:
>>> My two machines are somewhat different: "oldbox" is running NTP 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as ships with RedHat 6.3.
>> Why?
>
> Because oldbox has a lot of other custom functions that haven't been validated against the newer OS. newbox does only NTP, so we're not stuck with the older version.
>
>
>> Plots would be good.
>> Plot the offset vs time from the peerstats file. You might discover that
>> your understanding is wrong.
>
>
> Currently I'm not generating a peerstats file, but will change that after business hours this evening.
>
>>> I'm measuring the offset via "ntpdate -q <peer ntp server>"
>> Very silly way of doing it, esp since your machine measures the offset
>> every few minutes already.
>
> Where can I access this information? I assume from the peerstats file? Or is there another mechanism for querying this pre-existing data?
releases. Try <www.ntp.org>
There are some utilities with the distributions. I call
summary.sh from cron each night and that script gives
a summary of loopstats, peerstats and clockstats.
>
>>> Is it possible there is a hardware problem with newbox? I don't really understand NTP well enough to know where to start looking.
>> It is possible. What operating system is on newbox? And it could be that
>> something on the box is resetting the clock behind ntpd's back.
>
> newbox is running Redhat (CentOS actually) 6.3.
>
> How can I determine if something else is messing with the clock?
>
>> You can expect offsets of the order of 10-20microseconds IF the ntp
>> servers get their time from gps. If not, the servers themselves can be
>> woggling all over the place.
>
> Is there any way to determine if the ntp servers are using GPS or not?
>
> Thanks again.
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.6p5-o Wed Feb 1 07:49:06 UTC 2012 (import)",
processor="i386", system="NetBSD/6.1_STABLE", leap=00, stratum=2,
precision=-18, rootdelay=0.725, rootdisp=11.089, refid=192.168.59.61,
reftime=d55326e2.5822c70b Fri, May 31 2013 13:40:50.344,
clock=d55328c1.b2d725b5 Fri, May 31 2013 13:48:49.698, peer=25540, tc=6,
mintc=3, offset=0.520, frequency=-49.924, sys_jitter=0.458,
clk_jitter=0.122, clk_wander=0.010, tai=35, leapsec=201207010000,
expire=201306280000
remote refid st t when poll reach delay offset jitter
========================================================================
+SHM(0) .MSFa. 1 l 26 64 267 0.000 -0.652 1.176
-ns1.lordynet.or xxxxxxxxx 3 u 60 64 376 0.229 1.657 0.019
-ns3.lordynet.or xxxxxxxxx 3 u 2 64 377 0.354 1.683 0.058
-ns0.lordynet.or xxxxxxxxx 3 u 60 64 377 0.697 1.635 0.541
*me6000e.home.lo .PPSb. 1 u 21 64 377 0.725 0.520 0.457
-xxxxxxxxxxxxxxx xxxxxxxxx 2 u 13 256 377 18.766 2.822 0.159
-xxxxxxxxxxxxxxx xxxxxxxxx 2 u 101 256 377 20.567 2.689 0.347
+xxxxxxxxxxxxxxx xxxxxxxxx 2 u 135 256 377 26.693 2.044 0.290
-xxxxxxxxxxxxxxx xxxxxxxxx 2 u 76 256 377 27.286 2.523 0.247
-xxxxxxxxxxxxxxx xxxxxxxxx 2 u 257 256 377 42.265 3.263 0.243
$ ntpq -crv -p me6000e
associd=0 status=01fd leap_none, sync_pps, 15 events, kern,
version="ntpd 4.2.6p5-o Wed Feb 1 07:49:06 UTC 2012 (import)",
processor="i386", system="NetBSD/6.1_STABLE", leap=00, stratum=1,
precision=-18, rootdelay=0.000, rootdisp=1.655, refid=PPSb,
reftime=d55328c6.b349da0b Fri, May 31 2013 13:48:54.700,
clock=d55328f6.f6f18593 Fri, May 31 2013 13:49:42.964, peer=54815, tc=6,
mintc=3, offset=-0.001, frequency=-35.098, sys_jitter=0.004,
clk_jitter=0.001, clk_wander=0.005, tai=35, leapsec=201207010000,
expire=201306280000
remote refid st t when poll reach delay offset jitter
========================================================================
*GPS_NMEA(2) .GPSb. 4 l 50 64 377 0.000 7.655 8.881
oPPS(2) .PPSb. 0 l 48 64 377 0.000 -0.001 0.004
+ns0.lordynet.or xxxxxxxxx 3 u 39 64 377 1.697 1.597 0.579
ns2.lordynet.or 192.168.5 2 u 48 64 377 0.549 -0.339 0.518
+ns1.lordynet.or xxxxxxxxx 3 u 45 64 377 1.122 1.141 0.345
+ns3.lordynet.or xxxxxxxxx 3 u 29 64 377 0.750 1.467 0.477
+xxxxxxxxxxxxxxx xxxxxxxxx 2 u 88 256 377 19.418 2.451 0.666
Steve Kostecke
May 31, 2013, 1:12:47 PM5/31/13
to
On 2013-05-31, David Lord <sn...@lordynet.org> wrote:
> matthew...@gmail.com wrote:
>
>> On Thursday, May 30, 2013 5:41:46 PM UTC-5, unruh wrote:
>>
> matthew...@gmail.com wrote:
>
>> On Thursday, May 30, 2013 5:41:46 PM UTC-5, unruh wrote:
>>
>>> ATTRIBUTION MISSING wrote:
>>>
>>>> My two machines are somewhat different: "oldbox" is running NTP
>>>> 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as
>>>> ships with RedHat 6.3.
[snip]
>>>
>>>> My two machines are somewhat different: "oldbox" is running NTP
>>>> 4.2.2 as ships with RedHat 5.7; "newbox" is running NTP 4.2.4 as
>>>> ships with RedHat 6.3.
>> Where can I access this information? I assume from the peerstats
>> file? Or is there another mechanism for querying this pre-existing
>> data?
>
> There is a mass of documentation with most of ntpd releases. Try
> <www.ntp.org>
http://doc.ntp.org/4.2.4
Your OS should provide the official NTP HTML documenation (either as a
part of their NTP package or as a seperate NTP docs package).
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
Steve Kostecke
May 31, 2013, 1:20:03 PM5/31/13
to
> Is there any way to determine if the ntp servers are using GPS or not?
But keep in mind that there other factors besides the time source at
play here.
unruh
May 31, 2013, 3:38:06 PM5/31/13
to
On 2013-05-31, Steve Kostecke <kost...@ntp.org> wrote:
> On 2013-05-31, matthew...@gmail.com <matthew...@gmail.com> wrote:
>
>> On Thursday, May 30, 2013 5:41:46 PM UTC-5, unruh wrote:
>>
>>> You can expect offsets of the order of 10-20microseconds IF the ntp
>>> servers get their time from gps. If not, the servers themselves can
>>> be woggling all over the place.
>
> That's misleading.
Probably. What I was trying to emphasise is that in worrying about the
> On 2013-05-31, matthew...@gmail.com <matthew...@gmail.com> wrote:
>
>> On Thursday, May 30, 2013 5:41:46 PM UTC-5, unruh wrote:
>>
>>> You can expect offsets of the order of 10-20microseconds IF the ntp
>>> servers get their time from gps. If not, the servers themselves can
>>> be woggling all over the place.
>
> That's misleading.
scatter of offsets on your machine, you have to wrry about the source as
well. One of my machines ( connected to a Garmin 18 gps) has a scatter
of offsets of about 100 usec. Clearly the Gamin has failed. (actually
they seem to produce crap, since both my Garmin 18s have failed over
about 3 years time). Clearly you can tell very little about your own
machine's timekeeping if you use something like that machine as your source of
time.
0 new messages