Linux - Server This forum is for the discussion of Linux Software used in a server related context. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
01-21-2011, 10:06 AM
|
#1
|
Member
Registered: Sep 2003
Location: Laurel MD
Posts: 296
Rep:
|
NTP behavior
I'm seeing some strange behavior with NTP. Running "ntpq -p" on one of my client systems is showing the following:
root@cc:~# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
rt-ora1 LOCAL(0) 11 u 136 1024 377 0.544 24155.8 469.994
*LOCAL(0) .LOCL. 12 l 33 64 377 0.000 0.000 0.001
I'm confused about the large offset (24155) that's huge. When I run the date command on the systems there is about a 24 second variation between the NTP server and its client.
I've run NTP on many systems before and have never seen such large offsets. Does anyone have experience with this and any idea why this would happen. I have about 25 clients and all are experiencing much the same results.
Lastly does anyone have experience with NTP running on a VM? I was wondering if putting a server on a VM would be problematic.
Any help will be greatly appreciated.
Thank you
|
|
|
01-21-2011, 10:41 AM
|
#2
|
Member
Registered: Jan 2011
Location: the right coast of the US
Distribution: Ubuntu 10.04
Posts: 80
Rep:
|
From the NTPQ docs:
peers
Obtains a current list peers of the server, along with a summary of each peer's state. Summary information includes the address of the remote peer, the reference ID (0.0.0.0 if this is unknown), the stratum of the remote peer, the type of the peer (local, unicast, multicast or broadcast), when the last packet was received, the polling interval, in seconds, the reachability register, in octal, and the current estimated delay, offset and dispersion of the peer, all in milliseconds.
Code:
remote refid st t when poll re delay offset jitter
==============================================================================
rt-ora1 LOCAL(0) 11 u 136 1024 377 0.544 24155.8 469.994
So, 24155.8 msecs is about 24 secs which matches what you see using date.
As far as using NTP on a VM there should not be any issue there.
|
|
1 members found this post helpful.
|
01-21-2011, 10:44 AM
|
#3
|
LQ Guru
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 27,467
|
Quote:
Originally Posted by z1p
From the NTPQ docs:
peers
Obtains a current list peers of the server, along with a summary of each peer's state. Summary information includes the address of the remote peer, the reference ID (0.0.0.0 if this is unknown), the stratum of the remote peer, the type of the peer (local, unicast, multicast or broadcast), when the last packet was received, the polling interval, in seconds, the reachability register, in octal, and the current estimated delay, offset and dispersion of the peer, all in milliseconds.
Code:
remote refid st t when poll re delay offset jitter
==============================================================================
rt-ora1 LOCAL(0) 11 u 136 1024 377 0.544 24155.8 469.994
So, 24155.8 msecs is about 24 secs which matches what you see using date.
As far as using NTP on a VM there should not be any issue there.
|
There were (are?) known issues with VMware and RedHat. They may have fixed them, but in the past, there were combinations of RHEL and Vmware that would cause the time to drift wildly. You had to not only patch VMware, but also the Linux kernel with a VMware provided patch, to get NTP to work. Otherwise, the clock would drift so bad, the NTP server would die after about an hour.
They MAY have fixed it, but the OP doesn't say what version/distro of Linux or what kind of VM
|
|
1 members found this post helpful.
|
01-21-2011, 06:13 PM
|
#4
|
Member
Registered: Sep 2003
Location: Laurel MD
Posts: 296
Original Poster
Rep:
|
Thank you for the information, though what I was concerned about is that the offset and time difference between the systems was so large. In the past I've rarely seen an offset greater than 1000, they were generally between 300 and 700. My clients kept close track with the server.
My guess is the clocks on my NTP servers are rather bad and must be fluctuating wildly and the clients can't keep track. Possibly I should look at one of the other systems to act as the server. My previous servers were actual network clocks. I don't have one here and was hoping I picked a fairly accurate system as it was the newest.
For my NTP servers I have
Redhat on a Dell R710, no VMs, running Oracle 10G (picked because it is the newest)
Ubuntu running KVM with the NTP server on a VM on a Dell 2950 (also the DNS server)
|
|
|
01-21-2011, 06:48 PM
|
#5
|
Member
Registered: Jan 2011
Location: the right coast of the US
Distribution: Ubuntu 10.04
Posts: 80
Rep:
|
Quote:
Originally Posted by TB0ne
There were (are?) known issues with VMware and RedHat. They may have fixed them, but in the past, there were combinations of RHEL and Vmware that would cause the time to drift wildly. You had to not only patch VMware, but also the Linux kernel with a VMware provided patch, to get NTP to work. Otherwise, the clock would drift so bad, the NTP server would die after about an hour.
They MAY have fixed it, but the OP doesn't say what version/distro of Linux or what kind of VM
|
Thanks for setting me and the OP straight. I was not aware of the issues and fortunately have not run into them.
thllgo - sorry for being off the mark with my answer, I misunderstood what you asked. As TBone said there are indeed issue that can occur with NTP and VMs, so that may account for some of your time drift.
regards,
z1p
|
|
|
01-23-2011, 09:54 PM
|
#6
|
Member
Registered: Jun 2009
Posts: 131
Rep:
|
radio clock
thllgo: why not make your own radio clock and hook it up to one of your servers?
|
|
|
01-24-2011, 10:07 AM
|
#7
|
Member
Registered: Sep 2003
Location: Laurel MD
Posts: 296
Original Poster
Rep:
|
I like that idea, I'm guessing there are instructions someplace on the web?
|
|
|
01-24-2011, 11:36 AM
|
#8
|
LQ Guru
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 27,467
|
Quote:
Originally Posted by thllgo
I like that idea, I'm guessing there are instructions someplace on the web?
|
Yep...and another possibility is to use a cheap GPS receiver. I grabbed a $69 USB GPS receiver, plugged it in, and configured NTP to use the generic NEMA data. Works like a charm, and I have a very reliable stratum-1 time server at home. Use the same thing at work too, but with 5 GPS units in a 'pool', but all running Linux NTP.
I documented it on here before, give a quick search. I think there's even a link to the NTP documentation that tells you how to configure the server line for the different hardware devices.
|
|
1 members found this post helpful.
|
01-24-2011, 01:16 PM
|
#9
|
Member
Registered: Sep 2003
Location: Laurel MD
Posts: 296
Original Poster
Rep:
|
I'm definitely going to try the GPS idea. My company won't give up the cash to buy one of the professional ones, though I'm sure I can get enough money to buy two or 3 simple GPS units.
Thanks a bunch. 
|
|
|
01-24-2011, 01:22 PM
|
#10
|
LQ Guru
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 27,467
|
Quote:
Originally Posted by thllgo
I'm definitely going to try the GPS idea. My company won't give up the cash to buy one of the professional ones, though I'm sure I can get enough money to buy two or 3 simple GPS units.
Thanks a bunch. 
|
No problems, glad to have helped (if I did.  ). The thread I did on this is here:
http://www.linuxquestions.org/questi...th-gps-824129/
Obviously, if you're not using a bluetooth GPS, just replace the bluetooth device ID with the USB one, such as /dev/ttyUSB0. A note though...I've seen some instances where the GPS software expects to find a /dev/gps0. If that's the case (may not be any longer), you can just easily make a symlink.
|
|
|
All times are GMT -5. The time now is 06:47 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|