Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
The Linux Intergration Services don't work for Virtual Server; they are only for Hyper-V and Hyper-V is only for 64-bit and I have 32-bit hardware so Hyper-V isn't an option for me. Therefore the Intergration Services aren't a viable option. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-14, Ralph ra...@depth.net wrote: Maybe what I'm misunderstanding is the 'how' of that measurement? And I correct that the assumption in all this is that the system clock ticks are consistent? And that is the root of the problem in getting things to work properly on a VM? In reading the NTP spec it sounded to me like the formula involved taking the transmission from the client (org), receipt at server (rec), server transmit (xmt), and client receipt (dst). The problem lying with the fact that if the clock ticks on the client aren't consistent, then the client realistically doesn't know that the distance between org and rec is even comparable to the distance between xmt and dst, correct? And further the client can't tell during which segment of time the variation in time occurred, right? The problem is not the round trip measurement ( although that can be a minor problem). The problem is that the rate of the vm clock is not consistant, and thus ntp, which adjusts the clock by adjusting the rate ( and strongly assumes that that rate changes slowly if it changes) cannot adjust if the clock rate keeps changing by large amounts. I've been doing a little playing around with hwclock and adjtimex to see what the various clocks are really doing. What it looks like is that the hardware clock is reporting time accurately (over time at least) even though the system clock Sure. Teh Hw clock ( rtc) is on its own timer which does not depend on any of the system timers. However it typically has a rate that is many PPM out and that rate cannot be adjusted. This makes it completely unsuitable for the clock adjustment that ntp uses. Also setting that clock is tough and it is not very accurate ( only delivers time to the second-- and on modern system even that can be somewhat inaccurate since the rtc interrupt has been screwed up in modern versions of Linux. Also setting the clock only occurs .5 sec after the adjustment is actually made.). The rtc makes for a lousy clock. isn't. I'm assuming that this is because under the covers the VM is having the hardware clock report time in sync with the clocking on the host. Nope. The HW clock is a clock which is completely separate from the operating system. So maybe if we could have a mode where ntpd uses the hardware clock to measure the round trip and instead of the system clock? Or just uses the hardare clock Impossible. The HWclock has a precision of only 1 second. And if your round trip times are many seconds long, you are in a situation where VM are the least of your worries ( eg on a spaceship) as the reference? And then adjusts the system clock to be closer to accurate? In this way if you have a host system that is properly adjusted so that the hardware clock of the VM is reporting fairly accurrately, then you ought to be able to get ntpd to adjust the system clock to properly reflect the time. I know this is similar to what one can do with adjtimex, but it would be nice if there was a way to have this done properly without having to work adjtimex manually and determine 'by hand' what the right values are. So now I'm probably going to get told to go find the adjtimex newsgroup... but since this is time related, I hope that maybe you will continue to humor me. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
unruh wrote: On 2011-03-14, Ralph ra...@depth.net wrote: Nope. The HW clock is a clock which is completely separate from the operating system. So maybe if we could have a mode where ntpd uses the hardware clock to measure the round trip and instead of the system clock? Or just uses the hardare clock Impossible. The HWclock has a precision of only 1 second. And if your round trip times are many seconds long, you are in a situation where VM are the least of your worries ( eg on a spaceship) The standard error made here in this group/mlist! Someone has time requirements of a certain accuracy. Forex not more than 10s off The tool of choice is ntp ( or crony, or.. ) this will be sufficient : ntp allows sync to less than 10s off ntp: Check! actually it is much better than that, a couple of magnitudes. Now if someone is asking for help with one issue or other advice is given in relation to the accuracy that ntp can/should achieve and no longer in relation to what the _actual requirement_ for this use case is/was. This tends to be aggravated by the fact that help seekers tend to sit on relevant information ( like VM, OS, ... ) or tell all but not their initial requirement. Still this group has on occasion a knack for answering a question not put ;-) that said. In a low accuracy requirement have the VM machine clock run guaranteed slow and drag it forward regularly with hard settings of the clock. ( guaranteed no backward moves ) uwe uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
unruh un...@wormhole.physics.ubc.ca wrote: The problem is not the round trip measurement ( although that can be a minor problem). The problem is that the rate of the vm clock is not consistant, and thus ntp, which adjusts the clock by adjusting the rate ( and strongly assumes that that rate changes slowly if it changes) cannot adjust if the clock rate keeps changing by large amounts. Why do you keep asserting that, while you clearly don't know what you are talking about? You keep assuming that the time in the client is measured by number of CPU cycles, which is of course hogwash. The time in the client can be determined from a number of sources, and in Linux you can even select which source the kernel should use for timekeeping. The sources selectable depend on the kernel version. Each of those sources is virtualized, to a more or less good degree. But your idea that the CPU is scheduled away from the client and then those sources stop dead and lose time, is completely wrong. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Rob wrote: unruhun...@wormhole.physics.ubc.ca wrote: The problem is not the round trip measurement ( although that can be a minor problem). The problem is that the rate of the vm clock is not consistant, and thus ntp, which adjusts the clock by adjusting the rate ( and strongly assumes that that rate changes slowly if it changes) cannot adjust if the clock rate keeps changing by large amounts. Why do you keep asserting that, while you clearly don't know what you are talking about? You keep assuming that the time in the client is measured by number of CPU cycles, which is of course hogwash. The time in the client can be determined from a number of sources, and in Linux you can even select which source the kernel should use for timekeeping. The sources selectable depend on the kernel version. Each of those sources is virtualized, to a more or less good degree. But your idea that the CPU is scheduled away from the client and then those sources stop dead and lose time, is completely wrong. It is in fact so wrong that a recent VMware report quoted here stated that with current VMware products you would get _better_ time sync on a client OS by running ntpd on the client, than by running ntpd on the host and using VMware's option to always time sync the client to the host. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Sunday, March 13, 2011 11:41:59 PM UTC-7, unruh wrote: Sure. Teh Hw clock ( rtc) is on its own timer which does not depend on any of the system timers. However it typically has a rate that is many PPM out and that rate cannot be adjusted. This makes it completely unsuitable for the clock adjustment that ntp uses. Also setting that clock is tough and it is not very accurate ( only delivers time to the second-- and on modern system even that can be somewhat inaccurate since the rtc interrupt has been screwed up in modern versions of Linux. Also setting the clock only occurs .5 sec after the adjustment is actually made.). The rtc makes for a lousy clock. Nope. The HW clock is a clock which is completely separate from the operating system. You are thinking of HW clocks that run on hardware. This is about a HW clock within a VM guest. And a hardware clock within a VM is not hardware anymore, it is software on the HOST that is emulating the hardware. And the software that is doing that emulation is doing it based on the [system] clocking on the host O/S. So if one has the HOST O/S clocking getting adjusted to fairly good accuracy, then the HW clock within the guest will be close to as accurate as the [system] clocking on the HOST. If you believe that the HW clock on the guest is run otherwise, then find some evidence to that effect because everything I've found so far indicates that the guest HW clock is emulated just like all the other pieces of 'hardware' in the guest. Now Linux's inability to read / set the HW clock accurately is something I can't speak to, but as Uwe points out, I'm not looking for super accuracy. And I don't think you understood what I was describing... I wasn't advocating adjusting the HW clock the way ntpd adjusts the system clock. I was advocating allowing the use of the HW clock to provide ntpd with a 'stable' clock for it to use in calculations. Maybe the precision isn't as good, but it would still be a good enough level of precision for my purposes and would allow ntpd to determine the level of adjustment that needs to be made to the system clock in order to get it to run closer to reality. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Mar 14, 2011, at 4:45 AM, Terje Mathisen wrote: It is in fact so wrong that a recent VMware report quoted here stated that with current VMware products you would get _better_ time sync on a client OS by running ntpd on the client, than by running ntpd on the host and using VMware's option to always time sync the client to the host. Please show me data from an example where ntpd in a client keeps better time than sync'ing to the host OS with tools.syncTime = true. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-14, Ralph ra...@depth.net wrote: On Sunday, March 13, 2011 11:41:59 PM UTC-7, unruh wrote: Sure. Teh Hw clock ( rtc) is on its own timer which does not depend on any of the system timers. However it typically has a rate that is many PPM out and that rate cannot be adjusted. This makes it completely unsuitable for the clock adjustment that ntp uses. Also setting that clock is tough and it is not very accurate ( only delivers time to the second-- and on modern system even that can be somewhat inaccurate since the rtc interrupt has been screwed up in modern versions of Linux. Also setting the clock only occurs .5 sec after the adjustment is actually made.). The rtc makes for a lousy clock. Nope. The HW clock is a clock which is completely separate from the operating system. You are thinking of HW clocks that run on hardware. This is about a HW clock within a VM guest. And a hardware clock within a VM is not hardware anymore, it is software on the HOST that is emulating the hardware. And the software that is doing that emulation is doing it based on the [system] clocking on the host O/S. So if one has the HOST O/S clocking getting adjusted to fairly good accuracy, then the HW clock within the guest will be close to as accurate as the [system] clocking on the HOST. If you believe that the HW clock on the guest is run otherwise, then find some evidence to that effect because everything I've found so far indicates that the guest HW clock is emulated just like all the other pieces of 'hardware' in the guest. If that is true, then by all means read the hardware clock. Ufortunately all the software on Linux assumes that the hardware clock gives time to the nearest second. It can read to very close to exactly that second mark by the harware issuing an interrupt at the 1 second mark (like a PPS) but Linux has largely destroyed that usefulness because of the reallocation of its interrupt handling. It thus polls to find the second mark. Now Linux's inability to read / set the HW clock accurately is something I can't speak to, but as Uwe points out, I'm not looking for super accuracy. Then by all means use the hardware clock. And I don't think you understood what I was describing... I wasn't advocating adjusting the HW clock the way ntpd adjusts the system clock. I was advocating allowing the use of the HW clock to provide ntpd with a 'stable' clock for it to use in calculations. Maybe the precision isn't as good, but it would still be a good enough level of precision for my purposes and would allow ntpd to determine the level of adjustment that needs to be made to the system clock in order to get it to run closer to reality. Well, you could run hwclock once every 10 sec say or once a minute, and simply step the system clock to the right time each time (eg a cron job). That might make timing a bit ropey (ie if you wanted to have parogram run for exaclty 20ms, that might get messed up if that 20ms occured on a clock resetting boundary-- that is one reason why ntp resets the clock by adjusting the rate.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Fri, Mar 11, 2011 at 12:47 PM, John Hasler jhas...@newsguy.com wrote: The hardware doesn't go away when you add another layer or two of complexity by adding VMWare. What's baffling, though, is why you need to add an entire virtual machine and operating system just to run another process. If only it were as simple as running another process. Virtualization is popular because operating systems (not just Windows) are actually quite weak at isolation. Shared libraries, permissions, resource allocation, software which requires exclusive use of particular ports, etc. are issues on various POSIX-like systems, as well as Windows. If I have 25 different applications on one box, I have to wait until ALL of them support and have been tested on a particular level of kernel, hardware drivers, shared libraries, file systems, database versions, whatever before I can safely upgrade. That is a major operational problem in a very heterogeneous IT environment (which most corporations have). Right now we have three Windows and six Linux server OS versions in production. Don't get me started on all the variations of the underlying dependencies - vendors all move at their own pace, and you have to stick with what is officially supported to keep that maintenance contract. If you write all your own software and your stack is trivially simple and uniform (e.g. twitter), good for you, but some of us live in the real world. Put another way, vritualization's major benefit is the encapsulation of all of an application's needs into a few big files that can be moved around (even while running!) from one piece of hardware to another. You can efficiently snapshot, clone for dev and QA environments, set up virtual isolated networks, etc. The virtual machine is the process unit. It sounds inefficient, but it is in practice vastly more efficient than what came before (bunches of physical boxes to handle all the heterogeneity in software dependencies). -- RPM ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Chris Albertson wrote: Use either ntpdate or ntpd -q. They both work the same way. They go to an NTP server and then jump the local system time to match the server. Run this every hour as a cron job. I think he will likely need to use ntpd -g -q and much more often than once a hour, if he doesn't make use of M$'s Linux Integration Services Timesync fix for the issue. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Once upon a time, Chris Albertson albertson.ch...@gmail.com said: On Fri, Mar 11, 2011 at 10:12 AM, Ryan Malayter malay...@gmail.com wrote: . have you ever audited the code of your BIOS? Or the firmware on your chipsets, NICs, RAID cards, or disk drives? Your control of a physical server is just as illusory as that of a Virtual Machine. Yes, Linux, after the first boot block is loaded does not use any of that code, no BIOS calls are made from the OS, none of other ROMs either. It's open Source so people read the code. Nope, Linux doesn't magically replace all the firmwares. You typical PC has a multitude of processors, and you only (mostly) control what runs on one class, the general-purpose CPU. You don't control what runs on the NIC, storage controllers (e.g. RAID), storage devices (disk drives, DVD drives, etc.), video cards, etc. Linux still has to deal with SMM and ACPI that is not Open Source. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Maybe what I'm misunderstanding is the 'how' of that measurement? And I correct that the assumption in all this is that the system clock ticks are consistent? And that is the root of the problem in getting things to work properly on a VM? In reading the NTP spec it sounded to me like the formula involved taking the transmission from the client (org), receipt at server (rec), server transmit (xmt), and client receipt (dst). The problem lying with the fact that if the clock ticks on the client aren't consistent, then the client realistically doesn't know that the distance between org and rec is even comparable to the distance between xmt and dst, correct? And further the client can't tell during which segment of time the variation in time occurred, right? I've been doing a little playing around with hwclock and adjtimex to see what the various clocks are really doing. What it looks like is that the hardware clock is reporting time accurately (over time at least) even though the system clock isn't. I'm assuming that this is because under the covers the VM is having the hardware clock report time in sync with the clocking on the host. So maybe if we could have a mode where ntpd uses the hardware clock to measure the round trip and instead of the system clock? Or just uses the hardare clock as the reference? And then adjusts the system clock to be closer to accurate? In this way if you have a host system that is properly adjusted so that the hardware clock of the VM is reporting fairly accurrately, then you ought to be able to get ntpd to adjust the system clock to properly reflect the time. I know this is similar to what one can do with adjtimex, but it would be nice if there was a way to have this done properly without having to work adjtimex manually and determine 'by hand' what the right values are. So now I'm probably going to get told to go find the adjtimex newsgroup... but since this is time related, I hope that maybe you will continue to humor me. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-12, Ralph ra...@depth.net wrote: @Chris I appreciate the offer to help. I've been thinking about this problem a while and here are my thoughts... It seems to me that ntpd has the goal of keeping extremely accurate time - which is important for many obvious reasons. However there are those of us that don't need time accurate to the millisecond and / or don't need time to be perfectly in sync with the rest of the world. With that in mind, it would be nice if there was something out there that operated in a slightly different mode than ntpd does... It appears that the problem that ntpd has is that because the distance between ticks on the local machine are variable and therefore calculating the time between a transmission and receipt is 'impossible'. But why not have something that assumes that No, that is not the problem. The problem is that the computer has an internal clock that depends on things like counting processor cycles. If suddenly the processor disappears for a while with no processor cycles, the timing will be messed up. ntpd cannot do anything about that. It just looks as if the local call has suddenly slews backwards. the local ticks simply can't be trusted? Keep track of how far off the local clock is from the ntp sources (averaged over numerous queries) and adjust the How? clock based on the average adjustment that is needed. Don't mess with trying That is what ntpd does. It does it by adjusting the rate of the clock. to calculate the time taken for the round trip and all that, if the replies And how does it know what the ntp sources say the time is then? back from servers are within a certain amount of time of one another, then just average them out. If you do something similar to what I suggest, you will end up running further 'behind' than a ntpd server that has consistent ticks, but you ought to at least be able to have something that disciplines the clock into running fairly close to real time on average and stays within a handful of seconds within 'real' time. Nope. ntpd adjusts a clock by altering the rate of the clock. But it has a hard 500PPM limit on the rate, and such a rate adjustment will bring the rate to a place which is trying to adjust for a bunch of lost ticks. This is made particularly bad because ntpd has a horrible adjustment time to a change in rate ( hours). It is NOT designed to compensate for such variable rates. On linux, chrony might be better ( it has no 500PPM limit, more like 10PPM) and has a much much faster response to rate changes. But even it will have a hard time keeping up with a clock which randomly looses chuncks of time. Alternatively, you could run ntpdate everyminute and just jump the clock to the right time. It will tick by fits and starts, but the time may be not too badly out. As I said, this probably is a completely different solution than ntpd, but it seems like it would be really useful for people that are more concerned with making time consistent / realistic than they are with making it ultra-accurate. And this could also be very useful for people that have hardware clocks that don't seem to run consistently enough for ntpd - the people whom I've seen been told to replace their motherboard in order to get a clock that can keep time. I'm no time expert, so feel free to explain where I've lost my mind if I'm not thinking through this all the way... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Chris Albertson wrote: On Fri, Mar 11, 2011 at 10:47 AM, John Hasler jhas...@newsguy.com wrote: RPM writes: What's baffling, though, is why you need to add an entire virtual machine and operating system just to run another process. The problem is Windows does not multitask well. I've been told you can't expect to run multiple service on the same machine and expect it to remain stable for long. So they use one computer per process. I remember the first time I got shown around a Windows based sever room. I was astounded at the number of servers they needed and most were running at very light loads. Is that NT3.5 fact still valid ? Never understood why anyone would use Windows for real work anyway. The thing that it does best is waiting ever faster for the next keypress from the user. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Chris Albertson wrote: On Fri, Mar 11, 2011 at 10:12 AM, Ryan Malayter malay...@gmail.com wrote: . have you ever audited the code of your BIOS? Or the firmware on your chipsets, NICs, RAID cards, or disk drives? Your control of a physical server is just as illusory as that of a Virtual Machine. Yes, Linux, after the first boot block is loaded does not use any of that code, no BIOS calls are made from the OS, none of other ROMs either. It's open Source so people read the code. My understanding is that system management mode code is still executed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
David Woolley wrote: Chris Albertson wrote: Yes, Linux, after the first boot block is loaded does not use any of that code, no BIOS calls are made from the OS, none of other ROMs either. It's open Source so people read the code. My understanding is that system management mode code is still executed. With dislike, though. It is closed and unmanaged source. You can still disable it. Or you could get an open source bios ( for a select range of motherboards ). Imho with a bit of effort you can defang the majority of potential backdoors on Linux and most probably the BSDs (but not on apple) too. I haven't followed the TPM infrastructure stuff. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Is that NT3.5 fact still valid ? Never understood why anyone would use Windows for real work anyway. The thing that it does best is waiting ever faster for the next keypress from the user. uwe Perhaps people use Windows because the software they wish to run is only available for Windows? I know that two reasons I develop for Windows are that my customers want Windows software, and I don't need to create half a dozen different versions for the variants of UNIX-style OSes which are out there. But I also use FreeBSD and Apple's IOS where they are more appropriate. Oh, and for many people, their interaction with Windows is not mainly via the keyboard. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
David J Taylor wrote: Is that NT3.5 fact still valid ? Never understood why anyone would use Windows for real work anyway. The thing that it does best is waiting ever faster for the next keypress from the user. uwe Perhaps people use Windows because the software they wish to run is only available for Windows? I know that two reasons I develop for Windows are that my customers want Windows software, and I don't need to create half a dozen different versions for the variants of UNIX-style OSes which are out there. But I also use FreeBSD and Apple's IOS where they are more appropriate. Look at how x-platform OSS software can be without much hassle. Best organised example : Debian imho. Getting no traction cross distribution but on the same CPU family is nearly 100% attributable to not understood dependency and build processes. Same with all the display and usability problems Adobe has on linux. Big mouth and a long list of what linux lacks. But OSS software invariably does not have the issues while not lacking in performance either. Oh, and for many people, their interaction with Windows is not mainly via the keyboard. you mean they only do click and drool ;-) Cheers, David G! uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Uwe Klein uwe_klein_habertw...@t-online.de wrote in message news:h01s48-89b@klein-habertwedt.de... David J Taylor wrote: Is that NT3.5 fact still valid ? Never understood why anyone would use Windows for real work anyway. The thing that it does best is waiting ever faster for the next keypress from the user. uwe Perhaps people use Windows because the software they wish to run is only available for Windows? I know that two reasons I develop for Windows are that my customers want Windows software, and I don't need to create half a dozen different versions for the variants of UNIX-style OSes which are out there. But I also use FreeBSD and Apple's IOS where they are more appropriate. Look at how x-platform OSS software can be without much hassle. Best organised example : Debian imho. Getting no traction cross distribution but on the same CPU family is nearly 100% attributable to not understood dependency and build processes. Same with all the display and usability problems Adobe has on linux. Big mouth and a long list of what linux lacks. But OSS software invariably does not have the issues while not lacking in performance either. Oh, and for many people, their interaction with Windows is not mainly via the keyboard. you mean they only do click and drool ;-) Cheers, David G! uwe Uwe, I will not discuss this further with you as it's veering off-topic here. Suffice it to say I am happy to live and let live, and take advantage of the best features of each OS I use without feeling the need to insult others who may have different needs. I will say a very big THANK YOU to those who have ported NTP to the different operating systems, and spent a lot of their own time working round the differing challenges this provides. For my own part, I have done quite a bit of testing, provided tools to help monitor and manage NTP, and published my findings to help others. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
unruh un...@wormhole.physics.ubc.ca wrote: The problem on a VM system is that the frequency jumps around. Ie, when the VM is running, its frequency should be very close to the fundamental clock frequency, and when it is not running, its freq is 0. What do you know about that? Did you ever do a small test to see if it is true what you write? It seems not... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
unruh un...@wormhole.physics.ubc.ca wrote: On 2011-03-08, Ralph ra...@depth.net wrote: When are you going to start working on it? ... or are you asking others to do free programming for you, to work around your unique problem? Maybe I deserve that flame for having ranted a bit, but I hardly think the problem of clock time that won't behave within a linux guest VM is 'unique'. Do a google search on it, I'm clearly not the only one with this problem. Of course it is not unique. It is also unsolveable. A VM simply does not run in a way that it can keep accurate time. the only way to do it is to have the underlying OS that runs the VM keep accurate time and to have the VM gets its time from there. think about it-- there is no clock tha tthe VM can discipline to keep accurate time. Clocks based on CPU cannot work because the VM can be interrupted at will and stopped. Clocks based on hardware cannot work because you would run into the problem of 5 different VM all fighting over the same hardware and constantly changing what the other had done. You have a fundamental misunderstanding of what a virtual machine system is and how it operates. It is the basic concept of a VM system that it emulates hardware that a guest operating system can manipulate as if it is real hardware, without having problems because of the same function being performed by other guest systems running in other VMs. So it is not at all true that it cannot work. It is how it is supposed to work. The fact that you don't have a picture of an implementation in front of you does not mean it cannot work. (and in fact, it works quite well in systems like VMware ESX) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Friday, March 11, 2011 11:49:39 PM UTC-8, unruh wrote: No, that is not the problem. The problem is that the computer has an internal clock that depends on things like counting processor cycles. If suddenly the processor disappears for a while with no processor cycles, the timing will be messed up. ntpd cannot do anything about that. It just looks as if the local call has suddenly slews backwards. the local ticks simply can't be trusted? Keep track of how far off the local clock is from the ntp sources (averaged over numerous queries) and adjust the How? clock based on the average adjustment that is needed. Don't mess with trying That is what ntpd does. It does it by adjusting the rate of the clock. to calculate the time taken for the round trip and all that, if the replies And how does it know what the ntp sources say the time is then? I think your response demonstrates where the thinking is 'stuck inside the box'. Stop being so concerned with the internal clock ticks - assume they are wrong and assume they are variable and don't try to use them for any measurement of time. Simply try to figure out the average of how far off they are - I know this is what ntpd does but it does it in a way that requires the ticks to be consistent because it is trying to compensate for trip time. What I'm saying is that you don't bother compensating for trip time because the distance between (org) and (dst) is not linear and consistent the way the time between (rec) and (xmt) are. Instead if you just use (xmt) as the 'correct' time and use the difference between (dst) and (xmt) as the adjustment that needs to be made, then you can get to a point where you know how much to slow down or speed up the ticks on average over time. So take a VM that has ticks that occurr the following number of nanoseconds apart... 1,3,5,5,2,1,1,5,5,2,2,1,1,5,5,1,1,2,2,1 and let's for time to run 'properly' you need the ticks to be one every 3 nanos. So what you need to do is add 0.45 nanos to every tick. At the core I don't think this is any different than what ntpd does today; but the difference is that if it sends out a ntp packet and gets nothing but 5 ns ticks and then sends out another and gets nothing but 1 ns ticks, it's calculation of the round trip is totally inconsistent, right? So if instead you just say the difference between the (dst) time and (xmt) time was local being 300s slow so I need to speed up to get in sync. And hopefully you have multiple time servers so you can average the differences to get a difference that has less variation - call this avg(xmt). And if you keep track of the difference for each server between the (xmt) it gave you and the avg(xmt), then you should be able to calculate the average that a given source is off over time so that you can detect bad round trips vs good ones. The net result of all this would be that you have a clock that is generally consistent but would be potentially succeptable to sustained periods of high network latency (vs the 'normal' latency) and runs at a time that is behind 'real' time by the average number of nanoseconds that a packet take to get from a time server to the client. So instead of trying to find a correction to apply to the internal tick of the clock, you are trying to find the correction to make to the average amount of time that the ticks are off by. This means looking at it over a much larger period of ticks and it probably takes longer to find the 'proper' adjustment. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Right. So what would be good is a solution along the lines of those methods that simply use the time off the time servers without worrying about the local clock, but that 'fix' the local clock in a more friendly way like ntpd does. (See my other reply for a few other ideas). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Appartently timesharing is for educational environments now; and not just for 'big iron'... http://www.microsoft.com/windows/multipoint/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph writes: So what would be good is a solution along the lines of those methods that simply use the time off the time servers without worrying about the local clock... How are you going to measure the offset? -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
As I outline in my other post, this method wouldn't care about offset. It isn't about precision accuracy, it's about relative consistency. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Sat, Mar 12, 2011 at 1:24 AM, David Woolley david@ex.djwhome.demon.invalid wrote: Chris Albertson wrote: My understanding is that system management mode code is still executed. It does not runif it is disabled of not present. and of course this only applies to PC hardware. Linux runs on many platforms from office copy machines to IBM System 390, routers and what not. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Sat, Mar 12, 2011 at 11:14 AM, Ralph ra...@depth.net wrote: Right. So what would be good is a solution along the lines of those methods that simply use the time off the time servers without worrying about the local clock, but that 'fix' the local clock in a more friendly way like ntpd does. You may be missing the point. The point is that even in theory f the local clock jumps around and stops and starts you really can't measure its rate.What NTP does is measure the rate of the system clock and compare that rate to a set of reference clocks and then adjust the rate of the local clock to match the speed of the reference.If yu can't measure the local rate yu are not able to use this method. The best best is to jump the local clock when ever you notice there is some difference between it's time and the reference. So try this... run a script that pools a refference clock every minute or so. You can use rtime to get the time. subtract that from local time. If the difference is 1 second reset the local time. This would fit in a small script of less then about 1 dozen lines. Use Bash shell, perl and whatever script you like. Might take 15 minute to set this up. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Thu, Mar 10, 2011 at 4:33 PM, Uwe Klein uwe_klein_habertw...@t-online.de wrote: IMHO most leveragers of VMs don't understand what happens in their loved sandbox which completely destroys the notion of a controlled and escape proof environment No, we do, it's just that 20:1 server consolidation ratios and the attendant cost savings, as well as the all of the deployment and management flexibility offered by VMs outweigh the other considerations. We started saving hundreds of thousands of direct expense per year when we went all-VMware on the server side two years ago, and we are a small company. As for your notion of safety when running on a real physical server... have you ever audited the code of your BIOS? Or the firmware on your chipsets, NICs, RAID cards, or disk drives? Your control of a physical server is just as illusory as that of a Virtual Machine. -- RPM ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
RPM writes: As for your notion of safety when running on a real physical server... have you ever audited the code of your BIOS? Or the firmware on your chipsets, NICs, RAID cards, or disk drives? Your control of a physical server is just as illusory as that of a Virtual Machine. The hardware doesn't go away when you add another layer or two of complexity by adding VMWare. What's baffling, though, is why you need to add an entire virtual machine and operating system just to run another process. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Parvin, Richard wrote: I run Symmetricom S300. I would like to use Sysplex to manage the time on my mainframes. Could someone point me to some documentation? How much are you paying researchers? justfuckinggoogleit.com symmetricom.com/resources/compliance-certifications/sysplex-timer www-03.ibm.com/systems/z/advantages/pso/stp/ntp.html -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Fri, Mar 11, 2011 at 10:12 AM, Ryan Malayter malay...@gmail.com wrote: . have you ever audited the code of your BIOS? Or the firmware on your chipsets, NICs, RAID cards, or disk drives? Your control of a physical server is just as illusory as that of a Virtual Machine. Yes, Linux, after the first boot block is loaded does not use any of that code, no BIOS calls are made from the OS, none of other ROMs either. It's open Source so people read the code. = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Fri, Mar 11, 2011 at 10:47 AM, John Hasler jhas...@newsguy.com wrote: RPM writes: What's baffling, though, is why you need to add an entire virtual machine and operating system just to run another process. The problem is Windows does not multitask well. I've been told you can't expect to run multiple service on the same machine and expect it to remain stable for long. So they use one computer per process. I remember the first time I got shown around a Windows based sever room. I was astounded at the number of servers they needed and most were running at very light loads. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
@Chris I appreciate the offer to help. I've been thinking about this problem a while and here are my thoughts... It seems to me that ntpd has the goal of keeping extremely accurate time - which is important for many obvious reasons. However there are those of us that don't need time accurate to the millisecond and / or don't need time to be perfectly in sync with the rest of the world. With that in mind, it would be nice if there was something out there that operated in a slightly different mode than ntpd does... It appears that the problem that ntpd has is that because the distance between ticks on the local machine are variable and therefore calculating the time between a transmission and receipt is 'impossible'. But why not have something that assumes that the local ticks simply can't be trusted? Keep track of how far off the local clock is from the ntp sources (averaged over numerous queries) and adjust the clock based on the average adjustment that is needed. Don't mess with trying to calculate the time taken for the round trip and all that, if the replies back from servers are within a certain amount of time of one another, then just average them out. If you do something similar to what I suggest, you will end up running further 'behind' than a ntpd server that has consistent ticks, but you ought to at least be able to have something that disciplines the clock into running fairly close to real time on average and stays within a handful of seconds within 'real' time. As I said, this probably is a completely different solution than ntpd, but it seems like it would be really useful for people that are more concerned with making time consistent / realistic than they are with making it ultra-accurate. And this could also be very useful for people that have hardware clocks that don't seem to run consistently enough for ntpd - the people whom I've seen been told to replace their motherboard in order to get a clock that can keep time. I'm no time expert, so feel free to explain where I've lost my mind if I'm not thinking through this all the way... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Fri, Mar 11, 2011 at 9:24 PM, Ralph ra...@depth.net wrote: @Chris I appreciate the offer to help. I've been thinking about this problem a while and here are my thoughts... It seems to me that ntpd has the goal of keeping extremely accurate time - which is important for many obvious reasons. However there are those of us that don't need time accurate to the millisecond and / or don't need time to be perfectly in sync with the rest of the world. With that in mind, it would be nice if there was something out there that operated in a slightly different mode than ntpd does.. You can set that up if you like. Use either ntpdate or ntpd -q. They both work the same way. They go to an NTP server and then jump the local system time to match the server. Run this every hour as a cron job. There are other even simpler and older time protocols that you can use rather then ntpdate. I think rdate is the oldest one used on the Internet with the RFC dated in 1983. Running rdate is very simple and light weight.You call it periodically and it jumps the clock to roughly match the rdate server. The trouble with all the simple methods is that that jump the clock to the correct time. This means time will run backwards if you clock was fast. This is not good at all if yur computer was measuring time. NTP is smart in that it never causes a big jump in time and I thin it is about as simple as can a system that never jumps time can be -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Chuck, Thanks for all the insights and information here... I'm sure it got lost in the myriad of message here. The VM technology being used in the this case is Microsoft's Virtual Server (which is the server version of Virtual PC) and the predecessor to Hyper-V. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Dave Hart wrote: On Wed, Mar 9, 2011 at 20:24 UTC, Chuck Swiger cswi...@mac.com wrote: I'm sure programs can detect virtualization, but the point is VoIP softswitches do care about latency and probably about system clock jitter, another example alongside the lvm approach demonstrating VM timekeeping can be respectable, it's all about the particular virtualization software and its integration with guest OSes. My impression was that VM is very good at aggregating systems with low utilisation. The reason for Linux Clockless mod : avoid uneccesary churn. With a hammer in your hand every problem is a nail. So the unix solution to problems is quite often slapping on another layer of indirection. VMs are that. But is not a universal solution. What actually happened to the idea of different users ;-) uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: The VM technology being used in the this case is Microsoft's Virtual Server (which is the server version of Virtual PC) and the predecessor to Hyper-V. So, you are trying to run ntp-4.2.2pl-9 on CentOS (v ?) in a Microsoft's Virtual Server (2005 ?) on windows 2008? Microsoft CentOS would clearly be the places to ask about your unique needs. A little research shows REHL (where CENTOS is ripped off from) has several recommendations depending on the version of REHL of kernel parameters that need to be set to get NTP to run properly on REHL in a VM. disable_lost_ticks, clock=pmtmr, divider=10, clocksource=acpi_pm, ... They also recommend tinker panic 0 # Must be at the top of the ntp.conf file server 192.168.0.1 # Whatever the IP of the host OS is as seen by virtual OS # Make sure the firewall permits NTP between the virtual OS and the host OS # disable CPU power management M$ seems to have notes on the subject, among them: http://support.microsoft.com/kb/918461 M$ seems say they have solved it in Hyper-V: Linux Integration Services Timesync: The clock inside the virtual machine will remain synchronized with the clock on the host. http://blogs.technet.com/b/virtualization/archive/2010/07/29/linux-integration-services-v2-1-now-available.aspx I think you have your solution. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Uwe Klein uwe_klein_habertw...@t-online.de wrote: What actually happened to the idea of different users ;-) Silly Uwe - timesharing is for old, slightly bulging guys with beards. :) It requires too much thought to make sure that User A can't ever see anything of User B's and that Instance 1 of COTSware won't step on the toes of Instance 2... It is so much easier to just slap an entire virtual machine onto the iron and be done with it... rick jones -- I don't interest myself in why. I think more often in terms of when, sometimes where; always how much. - Joubert 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... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Rick Jones wrote: Uwe Klein uwe_klein_habertw...@t-online.de wrote: What actually happened to the idea of different users ;-) Silly Uwe - timesharing is for old, slightly bulging guys with beards. :) Have we met before in person ;-? ( How did you know ) It requires too much thought to make sure that User A can't ever see anything of User B's and that Instance 1 of COTSware won't step on the toes of Instance 2... It is so much easier to just slap an entire virtual machine onto the iron and be done with it... And the naive expect this to be true and not just hiding another set of much more convoluted problems that the simple task of controlling access via 3 degrees of freedom would present. IMHO most leveragers of VMs don't understand what happens in their loved sandbox which completely destroys the notion of a controlled and escape proof environment G! uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Tue, Mar 08, 2011 at 03:26:34PM -0800, Chuck Swiger wrote: You are better off running ntpdate (or sntp) periodically via cron in the DomUs. Perhaps in certain cases, but not across the board. I'd be happy to review counterexamples to my generalization I'd say it depends on the VM. For instance, Fedora 14 running in kvm on Fedora 14. There are four clocksources available in the guest system: kvm-clock tsc hpet acpi_pm. With each of them the frequency seems to be stable, even when the host or guest CPU is heavily loaded. The kvm-clock and hpet clocks seem to be running at same rate as the host's system clock, tsc at the real CPU's rate and acpi_pm is off by few tens of ppm. Here is a rv output from ntpd running in the guest with the tsc clock, the host is not synchronized: associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version=ntpd 4.2.6p2@1.2194-o Mon Aug 23 12:18:41 UTC 2010 (1), processor=x86_64, system=Linux/2.6.35.2-9.fc14.x86_64, leap=00, stratum=3, precision=-23, rootdelay=128.742, rootdisp=41.165, refid=10.34.32.125, reftime=d121ddab.0ab5b995 Wed, Mar 9 2011 6:06:19.041, clock=d121ddab.5dd3a440 Wed, Mar 9 2011 6:06:19.366, peer=47730, tc=4, mintc=3, offset=-0.013, frequency=22.454, sys_jitter=0.011, clk_jitter=0.016, clk_wander=0.028 -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Mar 8, 2011, at 5:56 PM, Steve Kostecke wrote: On 2011-03-08, Chuck Swiger cswi...@mac.com wrote: [ ... ] NTP disciplines the system (i.e. kernel) clock, not the hardware clock on the mother board. That's right, although in reasonably common for platforms to periodically write the system clock time back to the hardware clock-- variously called the RTC/TOD/TOY clock which is in the BIOS/EFI/firmware and keeps time when the system is off. The RTC is _updated_, not synced, by the kernel. Right. Perhaps I'm mistaken, but I don't recall suggesting otherwise...? [ ... ] I have a Debian 6.0 system running as a VMWare guest. ntpd on this system has no problem disciplining the clock. OK. Does it do any better than using VMWare's tools.syncTime = true? I don't have access to the host. OK. If I was going to compare two things, well, I would actually try them both while measuring relevant factors to my comparison. If I had never tried one of the two, and I didn't have any other data available, then I wouldn't try to draw a conclusion about which alternative works better. Note [1]. Your jitter values are well over an order of magnitude worse than that of ntpd running on a non-virtualized machine, and your offsets are nearly an order of magnitude worse: You're comparing apples and oranges. Absolutely. In fact, this is exactly the point I was making. For all of that, your VM is doing pretty well running ntpd compared to others I'd seen. I'd imagine the host running the VM isn't especially busy; if it was, I wouldn't be surprised if ntpd can't manage to discipline the clock without tinker panic 0. The default panic threshold is 1024 seconds. Right. Depending on which VM technology is being used, it's entirely possible to suspend a guest OS for longer than 1024 seconds. Again, there's a point lurking here about the quality of timekeeping which is possible within a VM. A real machine, or the host ESX/Dom 0/whatever, ought to be able to keep good time without this option, and I would be looking for hardware failure, interrupt routing problems, etc if it could not. You are better off running ntpdate (or sntp) periodically via cron in the DomUs. Perhaps in certain cases, but not across the board. I'd be happy to review counterexamples to my generalization... There's my example. See note [1] above. To my mind, you don't have enough data to draw a conclusion from your example. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Mar 9, 2011, at 3:36 AM, Miroslav Lichvar wrote: On Tue, Mar 08, 2011 at 03:26:34PM -0800, Chuck Swiger wrote: You are better off running ntpdate (or sntp) periodically via cron in the DomUs. Perhaps in certain cases, but not across the board. I'd be happy to review counterexamples to my generalization I'd say it depends on the VM. OK. For instance, Fedora 14 running in kvm on Fedora 14. There are four clocksources available in the guest system: kvm-clock tsc hpet acpi_pm. With each of them the frequency seems to be stable, even when the host or guest CPU is heavily loaded. The kvm-clock and hpet clocks seem to be running at same rate as the host's system clock, tsc at the real CPU's rate and acpi_pm is off by few tens of ppm. I'm less familiar with linux-kvm than some of the alternatives, but what you've described here seems pretty reasonable. For instance, there's only one real CPU-- or maybe several real CPUs or CPU cores, depending on what's in the box-- so RDTSC is going to get the same results in the host OS and guest. (Again, depending availability of p-state invariant TSC, multicore TSC synchronization, etc.) Ditto for the real HPET timers, or ACPI, etc if they are exposed to the guest. However, note the caveats mentioned at http://www.linux-kvm.org/page/KVMClock Some basic mechanism to make sure it works: * Try guests without kvm-clock too. Make sure they at least boot * make sure successive gettimeofday calls never go backwards (testing this can take days) * make sure that calls to different time sources (like gettimeofday and monotonic) do not deviate too much, nor go backwards. --- The first line quoted above is the last sentence in a paragraph; there are prior assumptions which condition this statement. Let me try to rephrase more clearly: 1) Running ntpd in the Dom0/host ESX/host is very useful. Keeping good time there means that good time will be available to all of the VMs/guests via independent_wallclock = 0, tools.syncTime = true, etc. 2) Running ntpd in the Dom0/host ESX/host also means that system/kernel clock will or ought to be sync'ed, which means that the periodic updates to the RTC/TOD/TOY clock are also good. 3) Running ntpd in a DomU/guest is possible, however a DomU/guest OS cannot update the time seen in other DomUs/guests, and it cannot update the RTC/TOD/TOY clock. 4) Furthermore, ntpd in a DomU/guest may experience large jumps in time depending on the loading of the physical host, whether the VM is swapped out or otherwise suspended for long periods of time, etc. [ This is why the suggested ntp.conf's for DomU/guests use tinker panic 0, and recommend not to use to undisciplined local clock. This whole thread started because Ralph, the OP, couldn't get ntpd to keep time within a guest without that option. ] 5) I have yet to see an example where running ntpd in a DomU/guest kept better time than ntpd running in Dom0/host OS. 6) I have yet to see an example where ntpd running in a DomU/guest kept better time than using independent_wallclock = 0, tools.syncTime = true, etc if the Dom0/host OS is sync'ed. Because of the above, I've drawn the conclusion that running ntpd's in the other DomUs/guest VMs is almost entirely pointless. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Wed, Mar 9, 2011 at 20:24 UTC, Chuck Swiger cswi...@mac.com wrote: Because of the above, I've drawn the conclusion that running ntpd's in the other DomUs/guest VMs is almost entirely pointless. One oft-quoted reason I hear is we don't control the Dom0 whether it's corporate orgchart separation, or leased VMs. The VMware suggestion to run ntpd is an admission of engineering defeat. While lurking on a conference call run by irc.freenode.net #freeswitch people, someone mentioned maximizing the use of sub-$1000 16-core servers drawing less than 2W with colo loss-leader offers for 100Mbit connectivity and 2W power for less than $250/mo. The speaker was turning those into a dozen or more Windows Server VMs each leased to a different customer and mentioned the Microsoft VM solution didn't have problems with time in VMs, they get it from the supervisor (akin to Dom0). I'm sure programs can detect virtualization, but the point is VoIP softswitches do care about latency and probably about system clock jitter, another example alongside the lvm approach demonstrating VM timekeeping can be respectable, it's all about the particular virtualization software and its integration with guest OSes. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: Maybe I deserve that flame for having ranted a bit, but I hardly think the problem of clock time that won't behave within a linux guest VM is 'unique'. Do a google search on it, I'm clearly not the only one with this problem. And if they gave a flying flip about the many different flavor of linux, I'm sure the world would be a better place. But in the meantime, since I'm not running one of the very few flavors that they actually support, I have to find other solutions. Here are some links I've run across in the past related to VMware NTP. You'll likely need to look at the support files for your version of VMware. Xen, VMware, and Other Virtual Machine Implementations http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2. 13.6. VMware and NTP http://psp2.ntp.org/bin/view/Support/VMWareNTP 9.2.2.1. VMware http://psp2.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.1. http://www.xen.org/files/XenCloud/guest.pdf BlockQuote Time handling in Linux VMs To set individual Linux VMs to maintain independent times changing the /etc/sysctl.conf configuration file and adding: # Set independent wall clock time xen.independent_wallclock=1 /BlockQuote FreeBSD machdep.independent_wallclock instead of en.independent_wallclock ? -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ok. The host OS time is fine so I'd have no problem using that as the source for my linux guest. What no one has provided yet is an answer to 'how' to get the linux guest VM to get the proper time from the host? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Sorry if the formatting is bad. I don't have a local newsfeed (ISPs seems to have abonded providing that) so I have to post via google. I wraps fine on their editor but I can see where it might not format well in the newsfeed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
When are you going to start working on it? ... or are you asking others to do free programming for you, to work around your unique problem? Maybe I deserve that flame for having ranted a bit, but I hardly think the problem of clock time that won't behave within a linux guest VM is 'unique'. Do a google search on it, I'm clearly not the only one with this problem. And are you saying that the mentality of the open source world ought to be one of 'no one is allowed to complain about anything because they ought to code the fix themselves'? I've participated in many open source projects and I enjoy contirbuting to the community, but I don't think that one ought to have to be a contributor to be a user. If open source isn't supposed to have consumers that aren't contributors from a coding perspective, then it is most certainly a doomed concept - and I sincerly hope that is not the case. If you have never had a problem, what are you complaining about? I've never had a problem with a Windows guest. I'm complaining about it being so difficult to find the answer to getting a properly running clock with a linux guest. Nothing that can't be fixed by the VM ware vendors, I'm sure. And if they gave a flying flip about the many different flavor of linux, I'm sure the world would be a better place. But in the meantime, since I'm not running one of the very few flavors that they actually support, I have to find other solutions. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Well it started out as NTP's problem because apparently the clock instability makes it so NTP can't run right on the guest. I understand this isn't so much an NTP problem if the expectation is that NTP can't run on a guest OS, but since everyone seemed to state so matter of factly that the guest should be able get the time from the host, I thought someone here might be able to provide a lead on how that is achieved. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph ra...@depth.net wrote in message news:c5b90638-395f-4e77-8761-f99c25343...@glegroupsg2000goo.googlegroups.com... Ok. The host OS time is fine so I'd have no problem using that as the source for my linux guest. What no one has provided yet is an answer to 'how' to get the linux guest VM to get the proper time from the host? How is that NTP's problem? I would have thought the task should be performed by the virtual machine you are using, and you would not need to run NTP on the guest OS. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Host OS is windows (2008 if we want to get specific) nose and corkskrew is nessecary because frankly I'm not accustomed to there being any difference between a guest OS and a physical OS in most cases and even when there is it hasn't been relevant what the host OS is. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Sorry if the formatting is bad. I don't have a local newsfeed (ISPs seems to have abonded providing that) so I have to post via google. I wraps fine on their editor but I can see where it might not format well in the newsfeed. Ralph, You may be able to use one of the free news services instead, for example: http://www.eternal-september.org/ David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Ralph ra...@depth.net wrote in message news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com... Well it started out as NTP's problem because apparently the clock instability makes it so NTP can't run right on the guest. I understand this isn't so much an NTP problem if the expectation is that NTP can't run on a guest OS, but since everyone seemed to state so matter of factly that the guest should be able get the time from the host, I thought someone here might be able to provide a lead on how that is achieved. I think you need to as the VM vendor about that. Did the VMWare paper help at all? VMware advises to run ntpd in the guest. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph ra...@depth.net wrote in message news:d695207e-04ec-4664-8580-35bc25806...@glegroupsg2000goo.googlegroups.com... Well it started out as NTP's problem because apparently the clock instability makes it so NTP can't run right on the guest. I understand this isn't so much an NTP problem if the expectation is that NTP can't run on a guest OS, but since everyone seemed to state so matter of factly that the guest should be able get the time from the host, I thought someone here might be able to provide a lead on how that is achieved. I think you need to as the VM vendor about that. Did the VMWare paper help at all? Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: Host OS is windows (2008 if we want to get specific) nose and corkskrew is nessecary because frankly I'm not accustomed to there being any difference between a guest OS and a physical OS in most cases and even when there is it hasn't been relevant what the host OS is. Hi Ralph, You are talking about windows as host OS. imho broken by design. Linux on occasion changes too fast for ntp, a known issue. But Windows seems to be a constantly changing but unimprooving PITA going by what percolated through this ng. so it would have ben a nice thing to have started your initial post with : Running ntv v4.2 on Mandriva $mversion linux kernel 2.6... in aVM from $vendor hosted on $windows_version. from my vantage point having new problems inside a VM has a good chance of being caused by the VM and nothing else. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 3/8/2011 4:16 AM, Miroslav Lichvar wrote: On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote: Ralph wrote: filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, Your frequency error is way outside any reasonable bounds, which is reflecting in a very high jitter, which is probably the ultimate cause of rejection. This system is not savable by NTP. This seems to be a common problem and with virtual machines getting everywhere it will probably only get worse. I'm wondering how hard it would be for ntpd to detect that the clock frequency is outside the acceptable range and write a your clock is broken message to syslog? NTP should be able to detect the problem without to much trouble. Fixing the problem will most likely prove to be more difficult. The political issues are likely to be most difficult of all. I wouldn't want to be the one to persuade Dave Mills to permit the necessary modifications to the code. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Tue, Mar 8, 2011 at 1:16 AM, Miroslav Lichvar mlich...@redhat.com wrote: On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote: This seems to be a common problem and with virtual machines getting everywhere it will probably only get worse. I'm wondering how hard it would be for ntpd to detect that the clock frequency is outside the acceptable range and write a your clock is broken message to syslog? It's the old joke again: Man who has one clock knows what time it is. A man with two clocks is not sure. How is ntpd to know the PCs clock is not good unless there are enough clocks that it can apply something like it's clock selection algorithm. You need a minimum of two lus the PC's ntpd would need to see a set of servers that track each other well but as a group bounce around. Then it could deduce that it was bouncing, not the set. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-08, Ralph ra...@depth.net wrote: When are you going to start working on it? ... or are you asking others to do free programming for you, to work around your unique problem? Maybe I deserve that flame for having ranted a bit, but I hardly think the problem of clock time that won't behave within a linux guest VM is 'unique'. Do a google search on it, I'm clearly not the only one with this problem. Of course it is not unique. It is also unsolveable. A VM simply does not run in a way that it can keep accurate time. the only way to do it is to have the underlying OS that runs the VM keep accurate time and to have the VM gets its time from there. think about it-- there is no clock tha tthe VM can discipline to keep accurate time. Clocks based on CPU cannot work because the VM can be interrupted at will and stopped. Clocks based on hardware cannot work because you would run into the problem of 5 different VM all fighting over the same hardware and constantly changing what the other had done. And are you saying that the mentality of the open source world ought to be one of 'no one is allowed to complain about anything because they ought to code the fix themselves'? I've No. It is because you believe that there is a solution-- so impliment it. People have thought about it, and come to the conclusion that it is really hard to do. You walk in and state it is not. Prove it-- or was that just hot air. participated in many open source projects and I enjoy contirbuting to the community, but I don't think that one ought to have to be a contributor to be a user. If open source isn't supposed to have consumers that aren't contributors from a coding perspective, then it is most certainly a doomed concept - and I sincerly hope that is not the case. But it also means that you have to put up with what others have done, and you then should not sit there ranting about what they have not done. And you are ranting again. If you have never had a problem, what are you complaining about? I've never had a problem with a Windows guest. I'm complaining about it being so difficult to find the answer to getting a properly running clock with a linux guest. Nothing that can't be fixed by the VM ware vendors, I'm sure. And if they gave a flying flip about the many different flavor of linux, I'm sure the world would be a better place. But in the meantime, since I'm not running one of the very few flavors that they actually support, I have to find other solutions. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-08, Ralph ra...@depth.net wrote: Host OS is windows (2008 if we want to get specific) nose and corkskrew is nessecary because frankly I'm not accustomed to there being any difference between a guest OS and a physical OS in most cases and even when there is it hasn't been relevant what the host OS is. It is when the underlying os has only a vague grasp on reality as far as timing is concerned, and what you want is timing. Time is not something ammenable to software control. It is an external. Isn't it good that you have learned something, that there are some things where the underlying OS does make a difference? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
I'm going to end this particular line of discussion because it is clear that this is a fruitless conversation and arguing back and forth about my personal ability to code a solution for VM time syncronization doesn't do anything for the problem at hand. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-08, Richard B. Gilbert rgilber...@comcast.net wrote: On 3/8/2011 4:16 AM, Miroslav Lichvar wrote: On Sun, Mar 06, 2011 at 11:22:34AM +, David Woolley wrote: Ralph wrote: filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, Your frequency error is way outside any reasonable bounds, which is reflecting in a very high jitter, which is probably the ultimate cause of rejection. This system is not savable by NTP. This seems to be a common problem and with virtual machines getting everywhere it will probably only get worse. I'm wondering how hard it would be for ntpd to detect that the clock frequency is outside the acceptable range and write a your clock is broken message to syslog? NTP should be able to detect the problem without to much trouble. Fixing the problem will most likely prove to be more difficult. The political issues are likely to be most difficult of all. I wouldn't want to be the one to persuade Dave Mills to permit the necessary modifications to the code. Not at all sure how Mills comes into the picture. On a system where the frequency fluctuates wildly, ntpd is not the right answer, nor is any system. I suspect that the best you could do would be to run something like ntpdate often and jump the clock around. At least it would probably always jump in a positive direction, since the clock is most liable to loose, not gain. And these frequency jumps ( which ntpd handles particularly badly) are not gaussian at all. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Well along those lines, what about creating a driver or deamon (for lack of something better to call it) that provides time to ntpd that gets that time from the host machine? Similar to the local clock setting but somehow trusting the host. Or would that still have the problems with high jitter where ntpd would reject the time source? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote: filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, Not at all sure how Mills comes into the picture. On a system where the frequency fluctuates wildly, ntpd is not the right answer, nor is any system. I suspect that the best you could do would be to run something like ntpdate often and jump the clock around. The frequency offset in this case seems to be around 2% which is still well below the 10% maximum Linux can adjust. I'd try chrony before resorting to ntpdate, the timekeeping probably won't be very good, but at least the clock won't be stepped. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-08, Ralph ra...@depth.net wrote: Well along those lines, what about creating a driver or deamon (for lack of something better to call it) that provides time to ntpd that gets that time from the host machine? Similar to the local clock setting but somehow trusting the host. Or would that still have the problems with high jitter where ntpd would reject the time source? Yes. the virtual clock is not a very good clock. Instead when the virtual OS reads the clock, it should be asking the underlying OS what the time is, rather than reading its own clock. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Tue, Mar 8, 2011 at 9:04 AM, Ralph ra...@depth.net wrote: I'm going to end this particular line of discussion because it is clear that this is a fruitless conversation and arguing back and forth about my personal ability to code a solution for VM time syncronization doesn't do anything for the problem at No, the problem is not that no one can/will write the code. Lets step away from computers and go back 300 years. We'd have the same problem if I had a clock that was so poor it would stop at random times or even run backwards or instantly jump ahead. Now I tell you to look out the window at the big clock on the church tower and adjust fast/slow lever on my poor clock. OK so you do it as best you can but then the clock stops for 5 minutes, so you push the lever to full-speed fast then it catches up and over runs so you slow it again only to find my cheap clock jumps 2 minutes ahead.. You will never win. We have the same EXACT problem. If you can solve the above mechanical clock problem then explain your solution to someone who CAN code in C and he will be very happy to do it. But so far most people think that if the old clock is bad enough there is no possible solution. So I'll raise my hand. I'll do it. I right software like this all day, every day 20+ years and counting. You give me a fool-proof solution to the 300 year old mechanical clock problem. Tell me how to adjust the fast/slow lever, prove that you are right and I'll write the software. We will both become heroes but I will give credit to you. OK there is a method that works on that old 300 year old clock. Let the spring wind doown so the clock stops. Then every minute look out the window and move the hands on my clock to match those on the clock tower. Yes you will keep busy but this works. This is the method you must use on your VM. Just what everyone is saying -- you need to get the time from the host OS and not try to let NTP adjust the rate of the VM's clock as NTP will never win. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Mar 8, 2011, at 9:13 AM, Ralph wrote: Well along those lines, what about creating a driver or deamon (for lack of something better to call it) that provides time to ntpd that gets that time from the host machine? I still haven't been able to figure out which virtualization system you are using, but normally it is better to run ntpd only in the host ESX for VMware, Dom0 for Xen, etc. The strong recommendation is to only run ntpd in Dom0 using independent_wallclock set to 0, *unless* your DomU's then fail to keep sane time. See: http://xen.epiuse.com/xen-faq.txt http://www.nabble.com/Unable-to-set-system-clock-on-domU-td22042252.html Q: Where does a domain get its time from? A: Briefly, Xen reads the RTC at start of day and by default will track that with the precision of the periodic timer crystal. Xen's estimate of the wall-clock time can only be updated by domain 0. If domain 0 runs ntpdate, ntpd, etc. then the synchronised time will automatically be pushed down to Xen every minute (and written to the RTC every 11 minutes, just as normal x86 Linux does). All other domains always track Xen's wall-clock time: setting the date, or running ntpd, on these domains will not affect their wall-clock time. Note that the wall-clock time exported by Xen is UTC --- all domains must have appropriate timezone handling (i.e. a correct /etc/localtime file). The same thing applies to VMWare, as discussed in: http://www.vmware.com/pdf/vmware_timekeeping.pdf ...except it is controlled by a .vmx config option called tools.syncTime = true, or possibly vmware-guestd --cmd 'vmx.set_option synctime 1 1' in the guest VM. VMWare sometimes seems to encourage people to run ntpd in guest VMs, but I think that is badly flawed advice. Seriously, each physical machine only has one RTC and crystal oscillator. It's useful to run one instance of ntpd in the Dom0 (or host ESX) context where it can actually work and keep this real hardware clock in sync. Running ntpd's in the other DomUs/guest VMs is almost entirely pointless; it might be useful only if Dom0-DomU time is busted, and even in that case, ntpd is unlikely to ever obtain good time synchronization running in a DomU. You are better off running ntpdate (or sntp) periodically via cron in the DomUs. Regards, -- -Chuck ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-08, Miroslav Lichvar mlich...@redhat.com wrote: On Tue, Mar 08, 2011 at 05:00:44PM +, unruh wrote: filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, Not at all sure how Mills comes into the picture. On a system where the frequency fluctuates wildly, ntpd is not the right answer, nor is any system. I suspect that the best you could do would be to run something like ntpdate often and jump the clock around. The frequency offset in this case seems to be around 2% which is still well below the 10% maximum Linux can adjust. I'd try chrony before resorting to ntpdate, the timekeeping probably won't be very good, but at least the clock won't be stepped. The problem on a VM system is that the frequency jumps around. Ie, when the VM is running, its frequency should be very close to the fundamental clock frequency, and when it is not running, its freq is 0. Thus the time is a staircase, with the steps depending on how busy the VM is vs how busy the other stuff on that computer is. This means that chrony's frequency estimate also jumps around like mad (and means it is almost always down around its 3data point level in estimating frequency). Now it certainly would be capable of adjusting a 2% frequency shift, if that were consistant, but I am not sure how it would behave with the inconsistant type of jumps you get in a VM. But I agree it would be worth trying. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-08, Chuck Swiger cswi...@mac.com wrote: Seriously, each physical machine only has one RTC and crystal oscillator. It's useful to run one instance of ntpd in the Dom0 (or host ESX) context where it can actually work and keep this real hardware clock in sync. NTP disciplines the system (i.e. kernel) clock, not the hardware clock on the mother board. Running ntpd's in the other DomUs/guest VMs is almost entirely pointless; it might be useful only if Dom0-DomU time is busted, and even in that case, ntpd is unlikely to ever obtain good time synchronization running in a DomU. That's debatable. I have a Debian 6.0 system running as a VMWare guest. ntpd on this system has no problem disciplining the clock. Recent peer billboard snapshot: steve@www:/var/log/ntpstats$ ntpq -p remote refid st t when poll reach delay offset jitter +ntp.my.isp .GPS. 1 u 34 1024 377 60.6651.623 1.617 -enob... .PPS. 1 u 1041 1024 377 39.552 -8.220 2.120 *emit... .PPS. 1 u 184 1024 377 27.4043.936 1.347 +yamo... [snip] 2 u 768 1024 377 33.565 -1.757 2.256 -3snd... [snip] 2 u 102 1024 377 26.2947.261 1.179 Peerstats summary (last 10 days): steve@www:/var/log/ntpstats$ (cat peerstats; zcat peerstats*.gz) | wc -l 2682 steve@www:/var/log/ntpstats$ (cat peerstats; zcat peerstats*.gz) | awk -f /root/peer.awk identcnt mean rms max delay dist disp [snip] 516 -1.5021.4666.665 38.392 960.567 24.501 [snip] 535 -7.2441.5158.454 41.862 962.327 23.952 [snip] 5322.8201.7608.235 28.227 956.364 23.869 [snip] 521 -0.6731.3898.210 54.179 968.552 24.196 [snip] 5348.5651.7417.829 28.114 955.486 24.080 You are better off running ntpdate (or sntp) periodically via cron in the DomUs. Perhaps in certain cases, but not across the board. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Mar 8, 2011, at 1:18 PM, Steve Kostecke wrote: On 2011-03-08, Chuck Swiger cswi...@mac.com wrote: Seriously, each physical machine only has one RTC and crystal oscillator. It's useful to run one instance of ntpd in the Dom0 (or host ESX) context where it can actually work and keep this real hardware clock in sync. NTP disciplines the system (i.e. kernel) clock, not the hardware clock on the mother board. That's right, although in reasonably common for platforms to periodically write the system clock time back to the hardware clock-- variously called the RTC/TOD/TOY clock which is in the BIOS/EFI/firmware and keeps time when the system is off. The kernel/system clock is typically based off of a timer source like ACPI or HPET, which in turn uses a crystal oscillator running at some fairly rapid rate (HPET provides 10 MHz interrupts, for example), rather than the ~32kHz frequency of a classic RTC. It generates interrupts at kern.hz (or a multiple, perhaps, if you're doing a separate profile or stats clock for profiling or process usage) which invoke the scheduler and call hardclock or equivalent. Anyway, there isn't a separate RTC *or* timer crystal driving ACPI/HPET/etc for each VM. Running ntpd's in the other DomUs/guest VMs is almost entirely pointless; it might be useful only if Dom0-DomU time is busted, and even in that case, ntpd is unlikely to ever obtain good time synchronization running in a DomU. That's debatable. Evidently. :-) I have a Debian 6.0 system running as a VMWare guest. ntpd on this system has no problem disciplining the clock. OK. Does it do any better than using VMWare's tools.syncTime = true? Recent peer billboard snapshot: steve@www:/var/log/ntpstats$ ntpq -p remote refid st t when poll reach delay offset jitter +ntp.my.isp .GPS. 1 u 34 1024 377 60.6651.623 1.617 -enob... .PPS. 1 u 1041 1024 377 39.552 -8.220 2.120 *emit... .PPS. 1 u 184 1024 377 27.4043.936 1.347 +yamo... [snip] 2 u 768 1024 377 33.565 -1.757 2.256 -3snd... [snip] 2 u 102 1024 377 26.2947.261 1.179 Your jitter values are well over an order of magnitude worse than that of ntpd running on a non-virtualized machine, and your offsets are nearly an order of magnitude worse: % ntpq -p -c rv remote refid st t when poll reach delay offset jitter == -ntp.pbx.org 192.5.41.40 2 u 119 256 377 22.0760.946 0.027 *bonehed.lcs.mit .PPS.1 u 183 256 377 23.741 -0.079 0.027 +hickory.cc.colu 128.59.39.48 2 u 138 256 377 22.427 -0.210 0.049 +time1.apple.com 17.107.131.112 u 168 256 377 55.8280.315 0.202 [ ... ] associd=0 status=0694 leap_none, sync_ntp, 9 events, freq_mode, version=ntpd 4.2.4p5-a Wed Feb 16 17:12:20 EST 2011 (1), processor=i386, system=FreeBSD/7.4-PRERELEASE, leap=00, stratum=2, precision=-19, rootdelay=23.741, rootdispersion=25.764, peer=5314, refid=18.26.4.105, reftime=d1212f3d.75251aea Tue, Mar 8 2011 17:42:05.457, poll=8, clock=d1213495.8f71f337 Tue, Mar 8 2011 18:04:53.560, state=4, offset=-0.079, frequency=19.348, jitter=0.167, noise=0.032, stability=0.001, tai=0 For all of that, your VM is doing pretty well running ntpd compared to others I'd seen. I'd imagine the host running the VM isn't especially busy; if it was, I wouldn't be surprised if ntpd can't manage to discipline the clock without tinker panic 0. Seriously, even VMware documents this, for example see http://kb.vmware.com/kb/1006427: The configuration directive tinker panic 0 instructs NTP not to give up if it sees a large jump in time. This is important for coping with large time drifts and also resuming virtual machines from their suspended state. Note: The directive tinker panic 0 must be at the top of the ntp.conf file. It is also important not to use the local clock as a time source, often referred to as the Undisciplined Local Clock. NTP has a tendency to fall back to this in preference to the remote servers when there is a large amount of time drift. You are better off running ntpdate (or sntp) periodically via cron in the DomUs. Perhaps in certain cases, but not across the board. I'd be happy to review counterexamples to my generalization Regards, -- -Chuck PS: I'd just updated this system a two weeks ago, but it's running the system-provided /usr/sbin/ntpd. At least this thread has reminded me to switch to the 4.2.6p2 in /usr/local. :-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-08, Chuck Swiger cswi...@mac.com wrote: On Mar 8, 2011, at 1:18 PM, Steve Kostecke wrote: On 2011-03-08, Chuck Swiger cswi...@mac.com wrote: Seriously, each physical machine only has one RTC and crystal oscillator. It's useful to run one instance of ntpd in the Dom0 (or host ESX) context where it can actually work and keep this real hardware clock in sync. NTP disciplines the system (i.e. kernel) clock, not the hardware clock on the mother board. That's right, although in reasonably common for platforms to periodically write the system clock time back to the hardware clock-- variously called the RTC/TOD/TOY clock which is in the BIOS/EFI/firmware and keeps time when the system is off. The RTC is _updated_, not synced, by the kernel. Anyway, there isn't a separate RTC *or* timer crystal driving ACPI/HPET/etc for each VM. Plus the VMs likely don't receive consistant time-slices. I have a Debian 6.0 system running as a VMWare guest. ntpd on this system has no problem disciplining the clock. OK. Does it do any better than using VMWare's tools.syncTime = true? I don't have access to the host. Your jitter values are well over an order of magnitude worse than that of ntpd running on a non-virtualized machine, and your offsets are nearly an order of magnitude worse: You're comparing apples and oranges. For all of that, your VM is doing pretty well running ntpd compared to others I'd seen. I'd imagine the host running the VM isn't especially busy; if it was, I wouldn't be surprised if ntpd can't manage to discipline the clock without tinker panic 0. The default panic threshold is 1024 seconds. You are better off running ntpdate (or sntp) periodically via cron in the DomUs. Perhaps in certain cases, but not across the board. I'd be happy to review counterexamples to my generalization... There's my example. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
@Richard I know that one shapshot is very early on but if you look at the start of the thread you can see information on what things look like after it has been running a while and in that second output of the two in that last post you can see that it is quickly headed in that direction after a restart. I can tell you for sure that the falsh=400 error code isn't going to go away by waiting longer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Can it even be fixed? Well I hope so. Not to bash on the linux world, but I don't get why this timing thing is so hard... I mean I understand it from a techinical perspective because I've read all about how the hardware and timers and stuff work, but practically speaking, somebody needs to get with the program and find a solution. I've done many, many windows installs in Virtual PC, VMWare, Hyper-V, and others and even without the VM tools installed in the guest I've never had a clock problem that was big enough to worry about. Sorry about the rant here but when all you want is for the machine to do something basic like keep time and you can't get it to work, it gets really frustrating. And we can't blame it on the host machine because the time on the host machine marches along accurately all day long. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Yes this is a VM (see other ealier posts about that). I've been trying to get the clock to behave but haven't found the solution. Some people seem to think there isn't an answer. I'm not after super accurate time here, I just want my clock to stay within a minute or two of what actual time is. I'm certainly willing to turn off the panic 0 directive, but before I had it turned on ntpd wasn't making adjustments to the clock (I think because it was exceeding it's panic threshold all the time). Is the newer version going to help? And if so, has anyone rpm'd it up? Maybe I lack coolness factor for saying this, but I'm not really into compiling my own software or manually deploying by hand. ntpq -p looks like the following ntpq -p remote refid st t when poll reach delay offset jitter == rdns01.nexcess. 66.219.116.140 2 u 44 64 377 28.107 982913. 88317.2 mirror 204.9.54.119 2 u6 64 377 28.574 1106774 124694. clock.trit.net 192.43.244.182 u 46 64 337 10.098 1120629 154394. mailserv1.phoen .LCL.1 u 34 64 377 17.445 1127424 156997. louie.udel.edu 128.175.60.175 2 u 57 64 377 40.732 1114835 156655. ns.unc.edu 204.34.198.402 u 39 64 377 50.814 1020974 89826.4 ntp-3.cns.vt.ed 198.82.247.164 2 u6 64 377 52.976 1143785 155905. ntp-2.cns.vt.ed 198.82.247.164 2 u 18 64 377 38.473 1067816 102721. clock.isc.org .GPS.1 u 34 64 377 18.472 1128019 158703. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Any idea how to get a clock correction on a MS Virtual PC / Virtual Server? Last time I tried to install the MS VPC tools for linux on a machine it thoroughly hosed things up; so unless there is a new an improved version I'm a little hesitant to go there agian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: Can it even be fixed? Well I hope so. Not to bash on the linux world, but I don't get why this timing thing is so hard... I mean I understand it from a techinical perspective because I've read all about how the hardware and timers and stuff work, but practically speaking, somebody needs to get with the program and find a solution. I've done many, many windows installs in Virtual PC, VMWare, Hyper-V, and others and even without the VM tools installed in the guest I've never had a clock problem that was big enough to worry about. Virtual machines do not normally run in real time. The host speeds up and slows down the time seen by the guest so that time appears to flow almost normally, but the VM may actually be locked out of the processor for longish intervals. If you try and run a network time protocol, it sees true time and can't reconcile it with the fiction that is being fed to it by the host. This can also cause very large interrupt latencies. Run as a real machine, Linux ntpd, out of the box, will outperform nearly any Windows machine, but run on a VM, one needs to turn all the right knobs and the best option is often to synchronise the host and then occasionally run ntpdate, etc., in case the host has got its bookkeeping wrong. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 3/6/2011 4:48 PM, Chris Albertson wrote: On Sun, Mar 6, 2011 at 12:18 PM, Ralphra...@depth.net wrote: It is a VM, which I'm sure is why the clock isn't playing nice but I haven't found the right solution to fix it.. Can it even be fixed? I'd guess maybe not. Has anyone here run ntpd on a virtual machine? = Chris Albertson Redondo Beach, California The customary solution is to run ntpd on the host machine and let the virtual machines ask the host for the correct time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 3/7/2011 3:00 AM, Ralph wrote: Yes this is a VM (see other ealier posts about that). I've been trying to get the clock to behave but haven't found the solution. Some people seem to think there isn't an answer. I'm not after super accurate time here, I just want my clock to stay within a minute or two of what actual time is. I'm certainly willing to turn off the panic 0 directive, but before I had it turned on ntpd wasn't making adjustments to the clock (I think because it was exceeding it's panic threshold all the time). Is the newer version going to help? And if so, has anyone rpm'd it up? Maybe I lack coolness factor for saying this, but I'm not really into compiling my own software or manually deploying by hand. ntpq -p looks like the following ntpq -p remote refid st t when poll reach delay offset jitter == rdns01.nexcess. 66.219.116.140 2 u 44 64 377 28.107 982913. 88317.2 mirror 204.9.54.119 2 u6 64 377 28.574 1106774 124694. clock.trit.net 192.43.244.182 u 46 64 337 10.098 1120629 154394. mailserv1.phoen .LCL.1 u 34 64 377 17.445 1127424 156997. louie.udel.edu 128.175.60.175 2 u 57 64 377 40.732 1114835 156655. ns.unc.edu 204.34.198.402 u 39 64 377 50.814 1020974 89826.4 ntp-3.cns.vt.ed 198.82.247.164 2 u6 64 377 52.976 1143785 155905. ntp-2.cns.vt.ed 198.82.247.164 2 u 18 64 377 38.473 1067816 102721. clock.isc.org .GPS.1 u 34 64 377 18.472 1128019 158703. It's rare but sometimes a computer's clock keeps time so badly that NTPD can't correct the clock. If your clock gains or loses more than 43 seconds per day, get it fixed! It's more than NTPD can handle. BTW, please use your Return key from time to time. The first line of your message is about three screens wide! I just rewrapped' the text. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-06, Ralph ra...@depth.net wrote: It is a VM, which I'm sure is why the clock isn't playing nice but I haven't found the right solution to fix it... The clock was running fast until I added the divider=10 option and now it runs slow - but I rather have ntp have to move the clock forward than have it moving backwards. When it was running fast and ntpd had to move the clock backwards it was killing amavisd all the time. Are there other tweaks I can do to try to get the clock running properly on a VM? Why are you trying to discipline the clock on a VM-- that should be the job of the underlying OS that runs the VM and you should be getting your time from it. A VM cannot properly discipline a clock. Can you imagine 5 different VM all trying? And then the OS suspends the sessionfor a couple of second. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-07, Ralph ra...@depth.net wrote: Can it even be fixed? Well I hope so. Not to bash on the linux world, but I don't get why this timing thing is so hard... I mean I understand it from a techinical perspective because I've read all about how the hardware and timers and stuff work, but practically speaking, somebody needs to get with the program and find a solution. I've done many, many windows installs in Virtual PC, VMWare, Hyper-V, and others and even without the VM tools installed in the guest I've never had a clock problem that was big enough to worry about. Sorry about the rant here but when all you want is for the machine to do something basic like keep time and you can't get it to work, it gets really frustrating. And we can't blame it on the host machine because the time on the host machine marches along accurately all day long. The host machine is where the timing info should be kept, and the VM should be getting its time from there, not from its own attempts at running a clock. It is impossible for a ssytem which is randomly interrupted and suspended to keep accurate time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: Not to bash on the linux world, but I don't get why this timing thing is so hard... I mean I understand it from a techinical perspective because I've read all about how the hardware and timers and stuff work, but practically speaking, somebody needs to get with the program and find a solution. When are you going to start working on it? ... or are you asking others to do free programming for you, to work around your unique problem? I've done many, many windows installs in Virtual PC, VMWare, Hyper-V, and others and even without the VM tools installed in the guest I've never had a clock problem that was big enough to worry about. If you have never had a problem, what are you complaining about? Sorry about the rant here but when all you want is for the machine to do something basic like keep time and you can't get it to work, it gets really frustrating. Nothing that can't be fixed by the VM ware vendors, I'm sure. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: Can it even be fixed? Well I hope so. Not to bash on the linux world, but I don't get why this timing thing is so hard... I mean I understand it from a techinical perspective because I've read all about how the hardware and timers and stuff work, but practically speaking, somebody needs to get with the program and find a solution. I've done many, many windows installs in Virtual PC, VMWare, Hyper-V, and others and even without the VM tools installed in the guest I've never had a clock problem that was big enough to worry about. Sorry about the rant here but when all you want is for the machine to do something basic like keep time and you can't get it to work, it gets really frustrating. And we can't blame it on the host machine because the time on the host machine marches along accurately all day long. What is your host OS ? Windows? Why does one have to extract all that informtion via the nose and per corkskrew ? uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-06, Ralph ra...@depth.net wrote: I'm trying to get my ntpd configuration to work and no matter what I try nothing seems to work. Is this in a VM? I have numerous servers configured (and have tried various ones) in addition to pool servers and still can't get a configuration that works cleanly. When I run the peer command, all the servers display a condition of 'reject' and a status of 9014. If I run a pstatus on them I get a flash value of 400 and results that look like this: [snip] filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, Your offset for this association is between 58,156 and 67,671 milliseconds. If your other remote time servers are showing a similarly large offset then ntpd will not use any of them. I've tried removing all the restrict statements from my config to no avail. When I run peer my reach values are at 377 which I am to understand is an indication that things are ok in one respect. Yet I seem to be stuck in this status where I'm getting time information but not able to get a status that is 'happy'. My rv results always look something like this... What does your 'ntpq -p' look like? Now I know the clock on this machine isn't very accurate and I've had to set the tinker panic 0 in my config so that ntp can move the clock forward by large chunks, but does that prevent my ntpd from working cleanly? You could try disabling that configuration directive. I'm on ntp-4.2.2pl-9 on CentOS. This version is likely much older than you realize; you're using NTP4 v2.2. The current stable release is ntp-4.2.6p3 (NTP4 v2.6.3). See http://www.ntp.org/downloads.html or http://support.ntp.org/download for download links. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, Your frequency error is way outside any reasonable bounds, which is reflecting in a very high jitter, which is probably the ultimate cause of rejection. This system is not savable by NTP. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: I'm trying to get my ntpd configuration to work and no matter what I try nothing seems to work. I have numerous servers configured (and have tried various ones) in addition to pool servers and still can't get a configuration that works cleanly. When I run the peer command, all the servers display a condition of 'reject' and a status of 9014. If I run a pstatus on them I get a flash value of 400 and results that look like this: assID=39606 status=9014 reach, conf, 1 event, event_reach, srcadr=caprica.lerfjhax.com, srcport=123, dstadr=192.168.45.25, dstport=123, leap=00, stratum=2, precision=-20, rootdelay=36.652, rootdispersion=24.139, refid=209.51.161.238, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0, offset=67671.865, delay=79.190, dispersion=8.719, jitter=4952.046, You have a very high initial offset so first I'd shutdown ntpd then use ntpdate to set the time to a reasonable value or use 'ntpd -g -q'. With such a large offset you might need a few tries at setting the clock to within a few milliseconds. If you have a lot of services running it may also be a good idea to shut them down first as stepping the clock by large amounts might cause problems. What is the value in your current driftfile? You might want to remove your driftfile (save it somewhere) and then start ntpd with a clean sheet. David reftime=d11d6afb.4a911fc6 Sat, Mar 5 2011 18:07:55.291, org=d11d6cd3.7ddf634b Sat, Mar 5 2011 18:15:47.491, rec=d11d6c8f.dc02f227 Sat, Mar 5 2011 18:14:39.859, xmt=d11d6c8f.c7bb6eea Sat, Mar 5 2011 18:14:39.780, filtdelay=79.19 76.16 78.87 78.78 79.87 77.11 82.28 77.33, filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, filtdisp= 7.818.779.75 10.74 11.73 12.67 13.62 14.56 I've tried removing all the restrict statements from my config to no avail. When I run peer my reach values are at 377 which I am to understand is an indication that things are ok in one respect. Yet I seem to be stuck in this status where I'm getting time information but not able to get a status that is 'happy'. My rv results always look something like this... assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version=ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1), processor=i686, system=Linux/2.6.18-194.32.1.el5, leap=11, stratum=16, precision=-7, rootdelay=0.000, rootdispersion=30.540, peer=0, refid=INIT, reftime=. Wed, Feb 6 2036 22:28:16.000, poll=6, clock=d11d6d3b.ea5a48ed Sat, Mar 5 2011 18:17:31.915, state=1, offset=0.000, frequency=8.747, jitter=7.812, noise=7.812, stability=0.000, tai=0 Now I know the clock on this machine isn't very accurate and I've had to set the tinker panic 0 in my config so that ntp can move the clock forward by large chunks, but does that prevent my ntpd from working cleanly? I'm on ntp-4.2.2pl-9 on CentOS. Thanks in advance to anyone that can offer assistance. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Ralph wrote: If that is the case, is there anything that can be done to the system to make it 'behave'? Assuming that was in response to mine. Find out what is wrong with the system and repair or replace it, up to and including the mother board, if that is where the problem lies. Something is seriously broken. It could be hardware or it might be a competing time discipline program. I'm assuming that this is not a VM which is another possible cause. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
If that is the case, is there anything that can be done to the system to make it 'behave'? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
It is a VM, which I'm sure is why the clock isn't playing nice but I haven't found the right solution to fix it... The clock was running fast until I added the divider=10 option and now it runs slow - but I rather have ntp have to move the clock forward than have it moving backwards. When it was running fast and ntpd had to move the clock backwards it was killing amavisd all the time. Are there other tweaks I can do to try to get the clock running properly on a VM? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
I have done what you suggested in terms of setting the clock with services shutdown and then starting ntpd back up and I still end up in this state. Every time ntpd adjusts the clock it has to add around 190s; looks like it's doing it every hour or so... The driftfile has 8.747 in it. I have deleted it an let a new one generate and that is the one I have now. Prior to that the number was much much larger and ntpd wasn't keeping the clock in sync at all. One more piece of information I just noticed while looking through the system log; I repeatedly get a log entry from ntpd that says: ntpd[20111]: sendto([ip address]) (fd=-1): Bad file descriptor It looks like I getting one of these entries per time server I have configured and it looks like it's happening about every 15 minutes. Google search on this makes it sound like this would be caused by multiple instances of ntpd running, but checking my system monitor shows only one running. Is there something else that could cause this? And is this the source of my problem? Or is this just a red-herring? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Did another complete shutdown of ntpd, made suere there were no ntpd processes running, set the time with ntpd -q -g, and then started it back up. Here is what things look like shortly after startup... ntpq -c peer -c as -c rl remote refid st t when poll reach delay offset jitter == rdns01.nexcess. 64.113.32.5 2 u 59 641 62.831 913.967 7.812 mirror 128.138.140.44 2 u 59 641 71.406 915.138 7.812 clock.trit.net 192.43.244.182 u 58 6418.913 907.267 7.812 ntp1.phoenixpub .LCL.1 u 57 641 18.362 911.807 7.812 louie.udel.edu 128.4.1.12 u 56 641 91.502 898.406 7.812 ns.unc.edu 204.34.198.402 u 55 641 113.150 897.946 7.812 ntp-3.cns.vt.ed 198.82.247.164 2 u 55 641 103.533 935.682 7.812 ntp-2.cns.vt.ed 198.82.247.164 2 u 54 641 109.392 927.838 7.812 clock.isc.org .GPS.1 u 53 641 21.831 931.162 7.812 ind assID status conf reach auth condition last_event cnt === 1 56602 9014 yes yes nonereject reachable 1 2 56603 9014 yes yes nonereject reachable 1 3 56604 9014 yes yes nonereject reachable 1 4 56605 9014 yes yes nonereject reachable 1 5 56606 9014 yes yes nonereject reachable 1 6 56607 9014 yes yes nonereject reachable 1 7 56608 9014 yes yes nonereject reachable 1 8 56609 9014 yes yes nonereject reachable 1 9 56610 9014 yes yes nonereject reachable 1 assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version=ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1), processor=i686, system=Linux/2.6.18-194.32.1.el5, leap=11, stratum=16, precision=-7, rootdelay=0.000, rootdispersion=0.915, peer=0, refid=INIT, reftime=. Wed, Feb 6 2036 22:28:16.000, poll=6, clock=d11e68fd.1cd5690b Sun, Mar 6 2011 12:11:41.112, state=1, offset=0.000, frequency=8.747, jitter=7.812, noise=7.812, stability=0.000, tai=0 And then not long later it goes back to... ntpq -c peer -c as -c rl remote refid st t when poll reach delay offset jitter == rdns01.nexcess. 64.113.32.5 2 u1 64 17 60.673 7090.71 9486.71 mirror 128.138.140.44 2 u2 64 17 71.406 915.138 14064.5 clock.trit.net 192.43.244.182 u- 64 17 10.914 21512.2 15276.9 ntp1.phoenixpub .LCL.1 u1 64 17 18.362 911.807 14098.2 louie.udel.edu 128.4.1.12 u 62 647 90.110 12974.6 9407.68 ns.unc.edu 204.34.198.402 u- 64 17 101.525 7375.44 9512.29 ntp-3.cns.vt.ed 198.82.247.164 2 u 60 647 99.461 13937.7 10291.4 ntp-2.cns.vt.ed 198.82.247.164 2 u 58 647 101.434 14540.0 10868.6 clock.isc.org .GPS.1 u 59 647 20.526 14434.1 10759.7 ind assID status conf reach auth condition last_event cnt === 1 56602 9014 yes yes nonereject reachable 1 2 56603 9014 yes yes nonereject reachable 1 3 56604 9014 yes yes nonereject reachable 1 4 56605 9014 yes yes nonereject reachable 1 5 56606 9014 yes yes nonereject reachable 1 6 56607 9014 yes yes nonereject reachable 1 7 56608 9014 yes yes nonereject reachable 1 8 56609 9014 yes yes nonereject reachable 1 9 56610 9014 yes yes nonereject reachable 1 assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version=ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1), processor=i686, system=Linux/2.6.18-194.32.1.el5, leap=11, stratum=16, precision=-7, rootdelay=0.000, rootdispersion=2.940, peer=0, refid=INIT, reftime=. Wed, Feb 6 2036 22:28:16.000, poll=6, clock=d11e6983.d2a089fd Sun, Mar 6 2011 12:13:55.822, state=1, offset=0.000, frequency=8.747, jitter=7.812, noise=7.812, stability=0.000, tai=0 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
Davd write: You have a very high initial offset so first I'd shutdown ntpd then use ntpdate to set the time to a reasonable value or use 'ntpd -g -q'. With such a large offset you might need a few tries at setting the clock to within a few milliseconds. That might be an issue for ancient ntpd, but for anything recent there is no longer a need to set the time before starting ntpd. Just use the -g option to ntpd. http://support.ntp.org/Support/StartingNTP4 talks about this. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On Sun, Mar 6, 2011 at 12:18 PM, Ralph ra...@depth.net wrote: It is a VM, which I'm sure is why the clock isn't playing nice but I haven't found the right solution to fix it.. Can it even be fixed? I'd guess maybe not. Has anyone here run ntpd on a virtual machine? = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 2011-03-06, Ralph ra...@depth.net wrote: It is a VM, which I'm sure is why the clock isn't playing nice but I haven't found the right solution to fix it... [snip] Are there other tweaks I can do to try to get the clock running properly on a VM? For Xen: Run 'echo 1 /proc/sys/xen/independent_wallclock' in domU to allow ntpd to set the clock. Add 'xen.independent_wallclock = 1' to /etc/sysctl.conf to make the setting permanent. For WMWare: See http://www.vmware.com/pdf/vmware_timekeeping.pdf -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 3/6/2011 3:18 PM, Ralph wrote: It is a VM, which I'm sure is why the clock isn't playing nice but I haven't found the right solution to fix it... The clock was running fast until I added the divider=10 option and now it runs slow - but I rather have ntp have to move the clock forward than have it moving backwards. When it was running fast and ntpd had to move the clock backwards it was killing amavisd all the time. Are there other tweaks I can do to try to get the clock running properly on a VM? Try running NTP on the *physical* machine! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
On 3/6/2011 3:14 PM, Ralph wrote: Did another complete shutdown of ntpd, made suere there were no ntpd processes running, set the time with ntpd -q -g, and then started it back up. Here is what things look like shortly after startup... ntpq -c peer -c as -c rl remote refid st t when poll reach delay offset jitter == rdns01.nexcess. 64.113.32.5 2 u 59 641 62.831 913.967 7.812 mirror 128.138.140.44 2 u 59 641 71.406 915.138 7.812 clock.trit.net 192.43.244.182 u 58 6418.913 907.267 7.812 ntp1.phoenixpub .LCL.1 u 57 641 18.362 911.807 7.812 louie.udel.edu 128.4.1.12 u 56 641 91.502 898.406 7.812 ns.unc.edu 204.34.198.402 u 55 641 113.150 897.946 7.812 ntp-3.cns.vt.ed 198.82.247.164 2 u 55 641 103.533 935.682 7.812 ntp-2.cns.vt.ed 198.82.247.164 2 u 54 641 109.392 927.838 7.812 clock.isc.org .GPS.1 u 53 641 21.831 931.162 7.812 ind assID status conf reach auth condition last_event cnt === 1 56602 9014 yes yes nonereject reachable 1 2 56603 9014 yes yes nonereject reachable 1 3 56604 9014 yes yes nonereject reachable 1 4 56605 9014 yes yes nonereject reachable 1 5 56606 9014 yes yes nonereject reachable 1 6 56607 9014 yes yes nonereject reachable 1 7 56608 9014 yes yes nonereject reachable 1 8 56609 9014 yes yes nonereject reachable 1 9 56610 9014 yes yes nonereject reachable 1 assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version=ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1), processor=i686, system=Linux/2.6.18-194.32.1.el5, leap=11, stratum=16, precision=-7, rootdelay=0.000, rootdispersion=0.915, peer=0, refid=INIT, reftime=. Wed, Feb 6 2036 22:28:16.000, poll=6, clock=d11e68fd.1cd5690b Sun, Mar 6 2011 12:11:41.112, state=1, offset=0.000, frequency=8.747, jitter=7.812, noise=7.812, stability=0.000, tai=0 And then not long later it goes back to... ntpq -c peer -c as -c rl remote refid st t when poll reach delay offset jitter == rdns01.nexcess. 64.113.32.5 2 u1 64 17 60.673 7090.71 9486.71 mirror 128.138.140.44 2 u2 64 17 71.406 915.138 14064.5 clock.trit.net 192.43.244.182 u- 64 17 10.914 21512.2 15276.9 ntp1.phoenixpub .LCL.1 u1 64 17 18.362 911.807 14098.2 louie.udel.edu 128.4.1.12 u 62 647 90.110 12974.6 9407.68 ns.unc.edu 204.34.198.402 u- 64 17 101.525 7375.44 9512.29 ntp-3.cns.vt.ed 198.82.247.164 2 u 60 647 99.461 13937.7 10291.4 ntp-2.cns.vt.ed 198.82.247.164 2 u 58 647 101.434 14540.0 10868.6 clock.isc.org .GPS.1 u 59 647 20.526 14434.1 10759.7 This looks very much like NTPQ output taken far too early to be meaningful. I suggest that you start NTPD and let it run for TWENTY-FOUR HOURS. THEN issue ntpq and post the results. If you are really in a rush, you can issue NTPQ after twelve hours; NTPD needs at least that long to get tight synchronization! It's a big help if you can keep the temperature constant. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Flash 400 on all peers; can't get ntpd to be happy
I'm trying to get my ntpd configuration to work and no matter what I try nothing seems to work. I have numerous servers configured (and have tried various ones) in addition to pool servers and still can't get a configuration that works cleanly. When I run the peer command, all the servers display a condition of 'reject' and a status of 9014. If I run a pstatus on them I get a flash value of 400 and results that look like this: assID=39606 status=9014 reach, conf, 1 event, event_reach, srcadr=caprica.lerfjhax.com, srcport=123, dstadr=192.168.45.25, dstport=123, leap=00, stratum=2, precision=-20, rootdelay=36.652, rootdispersion=24.139, refid=209.51.161.238, reach=377, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0, offset=67671.865, delay=79.190, dispersion=8.719, jitter=4952.046, reftime=d11d6afb.4a911fc6 Sat, Mar 5 2011 18:07:55.291, org=d11d6cd3.7ddf634b Sat, Mar 5 2011 18:15:47.491, rec=d11d6c8f.dc02f227 Sat, Mar 5 2011 18:14:39.859, xmt=d11d6c8f.c7bb6eea Sat, Mar 5 2011 18:14:39.780, filtdelay=79.19 76.16 78.87 78.78 79.87 77.11 82.28 77.33, filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6, filtdisp= 7.818.779.75 10.74 11.73 12.67 13.62 14.56 I've tried removing all the restrict statements from my config to no avail. When I run peer my reach values are at 377 which I am to understand is an indication that things are ok in one respect. Yet I seem to be stuck in this status where I'm getting time information but not able to get a status that is 'happy'. My rv results always look something like this... assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart, version=ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:58:16 UTC 2009 (1), processor=i686, system=Linux/2.6.18-194.32.1.el5, leap=11, stratum=16, precision=-7, rootdelay=0.000, rootdispersion=30.540, peer=0, refid=INIT, reftime=. Wed, Feb 6 2036 22:28:16.000, poll=6, clock=d11d6d3b.ea5a48ed Sat, Mar 5 2011 18:17:31.915, state=1, offset=0.000, frequency=8.747, jitter=7.812, noise=7.812, stability=0.000, tai=0 Now I know the clock on this machine isn't very accurate and I've had to set the tinker panic 0 in my config so that ntp can move the clock forward by large chunks, but does that prevent my ntpd from working cleanly? I'm on ntp-4.2.2pl-9 on CentOS. Thanks in advance to anyone that can offer assistance. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
