Windows vs Linux time of day [modified]
-
My understanding is that both systems update the 'real time' clock time using one of many hardware sources. They may or may not actually access the hardware real-time clock. I believe Windows XP installed on an ACPI-capable machine will use an ACPI feature for running the 'real time' clock timer. The choice of which method and sources to use is up to the HAL (Hardware Abstraction Layer). Linux can use one of three different methods (depending on kernel version). I read an article[^] recently discussing this - it's actually an MS KB article about running Linux virtual machines on Virtual Server 2005 R2. Changing the method you're using may correct this clock drift problem. Stability. What an interesting concept. -- Chris Maunder
Hmmmm. That's a scary MS article. I'm on kernel 2.4. My PC is a P4 2.6GHz (??), 512Meg RAM, and all I am running is Ethereal. And it's on hardware, not a virtual machine. At least I'm not getting the 10% gains they suggest is possible in a Virtual machine. I'm doing the same test on other very similar hardware to see what the results are (except I'm using TCPDUMP instead of Ethereal on the Linux PC.) I will probably try syncing the system clock to RTC every 5 minutes via CRONTAB - nothing like a brute force approach!
-
I have a network containing Linux (RedHat 8) and Windows XP PCs. While I was logging network events simultaneously on Windows and Linux machines, I noticed that the logged times drifted out of synchronisation over the course of a day, then one (by logging on another PC I discovered it was the Linux machine) jumped by about 10 seconds back towards synchronisation at 4 am the next morning. As far as I can tell, Linux (RH8 in a standard install) updates the system clock (time of day) from the motherboard real time clock once a day, while Windows XP does it much more often. How often does Windows XP update the system clock from motherboard RTC? -- modified at 6:12 Tuesday 23rd May, 2006 OK, from initial answers, I need to be more specific! These PCs are destined to run stand-alone, with occasional (daily, maybe) synchronisation via a custom radio system. But we want to be able to synchronise events logged on the various PCs to within a few 100 milliseconds, using the system times from the individual PCs. I had the PCs on a network (but NOT using NTP) so I could see how good synchronisation using individual PC system times would be. In the final system, there will be no network connection between the machines. My observation (using the network and logging times of specific messages on the network) was that for XP PCs, the system times on different PCs drift by less than 100 milliseconds per hour. My guess is that XP updates its system clock from motherboard real time clock regularly (every second, maybe.) In contrast, RedHat Linux PC system clocks drift rapidly compared to the WinXP clocks (up to 0.5 seconds per hour), and then they jump back close to synchronisation at 4:01 am every morning. This would appear to be because Linux only resets system time according to hardware clock once a day. (CRON.DAILY must have something to do with it!) I will probably update the Linux system clock to RTC value more often - say every minute or every 5 minutes - by adding a task using crontab, but I was trying to find out how often XP does this update. Or maybe XP always uses the RTC.
Rather than relying on the WinXP's time features, I use a program, NISTime.exe, downloaded from NIST Boulder. If your separate PCs have an internet connection you can have them sync with a time server as often as once per hour. Norman, here are the time difference entries in my log for the past 24 hours for my Dell 2350; as you can see some of the hourly differences are under 100 milliseconds but some are 3, 4 and 5 times 100 milliseconds, and the cumulative drift during the 24 hour period is -0.232 seconds net ---Date--- --Time-- Difference (Sec) Year Mo Da Hr Mn Sc Incre. Cumul. 2006 05 23 00 25 13 0.144 0.144 2006 05 23 01 25 13 0.176 0.320 2006 05 23 02 25 15 -0.252 0.068 2006 05 23 03 25 17 -0.080 -0.012 2006 05 23 04 25 18 -0.235 -0.247 2006 05 23 05 25 20 0.213 -0.034 2006 05 23 06 25 22 0.146 0.112 2006 05 23 07 25 24 0.080 0.192 2006 05 23 08 25 24 0.160 0.352 2006 05 23 09 25 26 -0.224 0.128 2006 05 23 10 25 28 -0.138 -0.010 2006 05 23 11 25 29 -0.311 -0.321 2006 05 23 12 25 31 -0.032 -0.353 2006 05 23 13 25 31 -0.049 -0.402 2006 05 23 14 25 31 -0.110 -0.512 2006 05 23 15 25 33 0.039 -0.473 2006 05 23 16 25 33 0.058 -0.415 2006 05 23 17 25 34 0.081 -0.334 2006 05 23 18 25 34 0.116 -0.218 2006 05 23 19 25 36 -0.058 -0.276 2006 05 23 20 25 36 -0.123 -0.399 2006 05 23 21 25 38 0.129 -0.270 2006 05 23 22 25 40 0.093 -0.177 2006 05 23 23 25 41 0.153 -0.024 2006 05 24 00 25 43 -0.208 -0.232 HTH -- Ron McK4, Inc. Orlando, FL
-
Rather than relying on the WinXP's time features, I use a program, NISTime.exe, downloaded from NIST Boulder. If your separate PCs have an internet connection you can have them sync with a time server as often as once per hour. Norman, here are the time difference entries in my log for the past 24 hours for my Dell 2350; as you can see some of the hourly differences are under 100 milliseconds but some are 3, 4 and 5 times 100 milliseconds, and the cumulative drift during the 24 hour period is -0.232 seconds net ---Date--- --Time-- Difference (Sec) Year Mo Da Hr Mn Sc Incre. Cumul. 2006 05 23 00 25 13 0.144 0.144 2006 05 23 01 25 13 0.176 0.320 2006 05 23 02 25 15 -0.252 0.068 2006 05 23 03 25 17 -0.080 -0.012 2006 05 23 04 25 18 -0.235 -0.247 2006 05 23 05 25 20 0.213 -0.034 2006 05 23 06 25 22 0.146 0.112 2006 05 23 07 25 24 0.080 0.192 2006 05 23 08 25 24 0.160 0.352 2006 05 23 09 25 26 -0.224 0.128 2006 05 23 10 25 28 -0.138 -0.010 2006 05 23 11 25 29 -0.311 -0.321 2006 05 23 12 25 31 -0.032 -0.353 2006 05 23 13 25 31 -0.049 -0.402 2006 05 23 14 25 31 -0.110 -0.512 2006 05 23 15 25 33 0.039 -0.473 2006 05 23 16 25 33 0.058 -0.415 2006 05 23 17 25 34 0.081 -0.334 2006 05 23 18 25 34 0.116 -0.218 2006 05 23 19 25 36 -0.058 -0.276 2006 05 23 20 25 36 -0.123 -0.399 2006 05 23 21 25 38 0.129 -0.270 2006 05 23 22 25 40 0.093 -0.177 2006 05 23 23 25 41 0.153 -0.024 2006 05 24 00 25 43 -0.208 -0.232 HTH -- Ron McK4, Inc. Orlando, FL
Thanks - Unfortunately, the final computer arrangement will have no network and no internet. Synchronisation will be done once occasionally once per hour or once per day, via a radio network. How often we have to synchronise them depends on how well we can get the different PCs to keep time in stand-alone. The synchronisation on Win XP machines is pretty good (typically a relative drift of well under 100 milliseconds per hour.) My problem is a Linux PC, which drifts 500 milliseconds per hour. I am going to try updating its system clock from hardware clock every 5 minutes.
-
I have a network containing Linux (RedHat 8) and Windows XP PCs. While I was logging network events simultaneously on Windows and Linux machines, I noticed that the logged times drifted out of synchronisation over the course of a day, then one (by logging on another PC I discovered it was the Linux machine) jumped by about 10 seconds back towards synchronisation at 4 am the next morning. As far as I can tell, Linux (RH8 in a standard install) updates the system clock (time of day) from the motherboard real time clock once a day, while Windows XP does it much more often. How often does Windows XP update the system clock from motherboard RTC? -- modified at 6:12 Tuesday 23rd May, 2006 OK, from initial answers, I need to be more specific! These PCs are destined to run stand-alone, with occasional (daily, maybe) synchronisation via a custom radio system. But we want to be able to synchronise events logged on the various PCs to within a few 100 milliseconds, using the system times from the individual PCs. I had the PCs on a network (but NOT using NTP) so I could see how good synchronisation using individual PC system times would be. In the final system, there will be no network connection between the machines. My observation (using the network and logging times of specific messages on the network) was that for XP PCs, the system times on different PCs drift by less than 100 milliseconds per hour. My guess is that XP updates its system clock from motherboard real time clock regularly (every second, maybe.) In contrast, RedHat Linux PC system clocks drift rapidly compared to the WinXP clocks (up to 0.5 seconds per hour), and then they jump back close to synchronisation at 4:01 am every morning. This would appear to be because Linux only resets system time according to hardware clock once a day. (CRON.DAILY must have something to do with it!) I will probably update the Linux system clock to RTC value more often - say every minute or every 5 minutes - by adding a task using crontab, but I was trying to find out how often XP does this update. Or maybe XP always uses the RTC.
IMO without NTP you're basically out of luck, since in my experience most PC's RTC are not exactly accurate, and would drift seconds, if not minutes in a day. I don't think you will be able to keep stand-alone PCs in sync within your required limits. Your best option may be though to go for some kind of GPS-based system. There are dedicated GPS-based time-servers which you could connect to each of these PC, or another (probably cheaper) option could be Bluetotth-based GPS-receivers (such as from Holux, Garmin, Tomtom etc.) Then all you need is some utility that will take the time from the Bluetooth-GPS device and sync the PC regularly (may be included, or can be found as shareware). Accuracy of this is excelent! Good luck, Paul
-
Thanks - Unfortunately, the final computer arrangement will have no network and no internet. Synchronisation will be done once occasionally once per hour or once per day, via a radio network. How often we have to synchronise them depends on how well we can get the different PCs to keep time in stand-alone. The synchronisation on Win XP machines is pretty good (typically a relative drift of well under 100 milliseconds per hour.) My problem is a Linux PC, which drifts 500 milliseconds per hour. I am going to try updating its system clock from hardware clock every 5 minutes.
normanS wrote:
My problem is a Linux PC, which drifts 500 milliseconds per hour.
When was the system board battery last replaced? The only times I have see a clock vary that much was when the battery was dead.
normanS wrote:
How often we have to synchronise them depends on how well we can get the different PCs to keep time in stand-alone.
Why not have all the local systems sync with one system and that system sync with the radio network? That way you have have less calls for time going out over the radio network.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
-
normanS wrote:
My problem is a Linux PC, which drifts 500 milliseconds per hour.
When was the system board battery last replaced? The only times I have see a clock vary that much was when the battery was dead.
normanS wrote:
How often we have to synchronise them depends on how well we can get the different PCs to keep time in stand-alone.
Why not have all the local systems sync with one system and that system sync with the radio network? That way you have have less calls for time going out over the radio network.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
Could be the battery, but as far as I can see, my Linux systems drift wildly (3 PCs each loose 250 to 800 milliseconds per hour) while 7 similar Windows XP systems drift less than 50 milliseconds per hour. Co-incidence? Basically, it will operate as you suggest - one system will get the master time signal (daily, maybe), and it will synchronise the others via radio (hourly, maybe.) If the separate PC system clocks drift at maximum 50 mS per hour relative to my arbitrary master, this will be "good enough" (100 mSec synchronisation error.) This is what the Windows PCs do at the moment. What I have to do is get the Linux PC system clocks to drift at the Windows XP rate. I am working on that now. -- modified at 5:24 Wednesday 24th May, 2006
-
IMO without NTP you're basically out of luck, since in my experience most PC's RTC are not exactly accurate, and would drift seconds, if not minutes in a day. I don't think you will be able to keep stand-alone PCs in sync within your required limits. Your best option may be though to go for some kind of GPS-based system. There are dedicated GPS-based time-servers which you could connect to each of these PC, or another (probably cheaper) option could be Bluetotth-based GPS-receivers (such as from Holux, Garmin, Tomtom etc.) Then all you need is some utility that will take the time from the Bluetooth-GPS device and sync the PC regularly (may be included, or can be found as shareware). Accuracy of this is excelent! Good luck, Paul
The system clocks on the WinXP PCs I have checked (7 of them) all drift around 1 second per day. I can live with that, by synchronising the PCs with each other every hour or two. The system clocks on the RedHat8 Linux PCs I have checked (3 of them, same make & model as the Win XP PCs) drift from 4 to 20 seconds per day, but they jump back into synchronisation (or close) at 4:01 every morning. From what I have read, this appears to be because Linux only resets its system clock according to the PC hardware clock once a day by default. What I plan to do is force Linux to reset its system clock according to PC hardware clock every 5 minutes. I am working on that now. As for using GPS, you are absolutely correct. We are using handheld GPS receivers for primary timekeeping, but the systems are mobile, and GPS is useless in a garage, not-so-great in high-rise cities, etc. The synchronisation I am looking at is basically for backup timekeeping.
-
Could be the battery, but as far as I can see, my Linux systems drift wildly (3 PCs each loose 250 to 800 milliseconds per hour) while 7 similar Windows XP systems drift less than 50 milliseconds per hour. Co-incidence? Basically, it will operate as you suggest - one system will get the master time signal (daily, maybe), and it will synchronise the others via radio (hourly, maybe.) If the separate PC system clocks drift at maximum 50 mS per hour relative to my arbitrary master, this will be "good enough" (100 mSec synchronisation error.) This is what the Windows PCs do at the moment. What I have to do is get the Linux PC system clocks to drift at the Windows XP rate. I am working on that now. -- modified at 5:24 Wednesday 24th May, 2006
normanS wrote:
my Linux systems drift wildly
I have heard that if you threaten a Windows box with an install CD of *Nix it behaves its self. I wonder if the opposite is true? :) What may I ask are you doing that requires such precision in time keeping?
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
-
I have a network containing Linux (RedHat 8) and Windows XP PCs. While I was logging network events simultaneously on Windows and Linux machines, I noticed that the logged times drifted out of synchronisation over the course of a day, then one (by logging on another PC I discovered it was the Linux machine) jumped by about 10 seconds back towards synchronisation at 4 am the next morning. As far as I can tell, Linux (RH8 in a standard install) updates the system clock (time of day) from the motherboard real time clock once a day, while Windows XP does it much more often. How often does Windows XP update the system clock from motherboard RTC? -- modified at 6:12 Tuesday 23rd May, 2006 OK, from initial answers, I need to be more specific! These PCs are destined to run stand-alone, with occasional (daily, maybe) synchronisation via a custom radio system. But we want to be able to synchronise events logged on the various PCs to within a few 100 milliseconds, using the system times from the individual PCs. I had the PCs on a network (but NOT using NTP) so I could see how good synchronisation using individual PC system times would be. In the final system, there will be no network connection between the machines. My observation (using the network and logging times of specific messages on the network) was that for XP PCs, the system times on different PCs drift by less than 100 milliseconds per hour. My guess is that XP updates its system clock from motherboard real time clock regularly (every second, maybe.) In contrast, RedHat Linux PC system clocks drift rapidly compared to the WinXP clocks (up to 0.5 seconds per hour), and then they jump back close to synchronisation at 4:01 am every morning. This would appear to be because Linux only resets system time according to hardware clock once a day. (CRON.DAILY must have something to do with it!) I will probably update the Linux system clock to RTC value more often - say every minute or every 5 minutes - by adding a task using crontab, but I was trying to find out how often XP does this update. Or maybe XP always uses the RTC.
Hello, I have had to reset a few Linux (and Solaris) time-of-day clocks over the years, and have learned a few things about how PCs keep and maintain the time. Real-Time Clocks -- in a typical PC, the RTC hardware uses a low-frequency crystal (about 32 kilohertz) as it's time base. These crystals tend to be inexpensive, so their initial accuracy is not very good. Further, the frequency can drift with temperature and voltage changes. As far as I know, most operating systems only use the RTC to get an initial estimate of the time-of-day at boot-up. After that, they rely on other means to keep their time-of-day value close to actual time. A decent write-up on these PC RTC circuits can be found at http://www.beaglesoft.com/mainfaqclock.htm XP Time Synchronization -- if your PC clocks are staying synch'd to within 100 milliseconds, then those PCs are syncing their clocks to a master clock. It is very unlikely that they are staying in-sync using just their RTC hardware. Linux Time Synchronization -- when the Linux OS boots, it reads the hardware clock once, to initially set its time-of-day clock. (The command is "hwclock --hctosys", in recent Linux distributions.) After that, the Linux kernel maintains the time-of-day value that it uses. There are multiple ways available to maintain that value (e.g. NTP; GPS hardware; scripts that contact some other type of time server; etc). For stand-alone machines, the typical way is to run a program called "adjtimex". With this, you periodically set the kernel time-of-day value with the correct time (like, for example, using NTP while connected to a network during development). The 'adjtimex' program is told about these updates, and measures the systematic drift between the real time, and the hardware clock time. Once it has a good measurement, you can take the PC off the LAN, and re-configure it to use 'adjtimex' to adjust the kernel's time-of-day value to account for this measured drift. Naturally, if you are still sync'ing the time, but at a longer interval, you can use 'adjtimex' in-between the actual clock syncs, to maintain a more-or-less accurate time while running stand-alone.
-
Hello, I have had to reset a few Linux (and Solaris) time-of-day clocks over the years, and have learned a few things about how PCs keep and maintain the time. Real-Time Clocks -- in a typical PC, the RTC hardware uses a low-frequency crystal (about 32 kilohertz) as it's time base. These crystals tend to be inexpensive, so their initial accuracy is not very good. Further, the frequency can drift with temperature and voltage changes. As far as I know, most operating systems only use the RTC to get an initial estimate of the time-of-day at boot-up. After that, they rely on other means to keep their time-of-day value close to actual time. A decent write-up on these PC RTC circuits can be found at http://www.beaglesoft.com/mainfaqclock.htm XP Time Synchronization -- if your PC clocks are staying synch'd to within 100 milliseconds, then those PCs are syncing their clocks to a master clock. It is very unlikely that they are staying in-sync using just their RTC hardware. Linux Time Synchronization -- when the Linux OS boots, it reads the hardware clock once, to initially set its time-of-day clock. (The command is "hwclock --hctosys", in recent Linux distributions.) After that, the Linux kernel maintains the time-of-day value that it uses. There are multiple ways available to maintain that value (e.g. NTP; GPS hardware; scripts that contact some other type of time server; etc). For stand-alone machines, the typical way is to run a program called "adjtimex". With this, you periodically set the kernel time-of-day value with the correct time (like, for example, using NTP while connected to a network during development). The 'adjtimex' program is told about these updates, and measures the systematic drift between the real time, and the hardware clock time. Once it has a good measurement, you can take the PC off the LAN, and re-configure it to use 'adjtimex' to adjust the kernel's time-of-day value to account for this measured drift. Naturally, if you are still sync'ing the time, but at a longer interval, you can use 'adjtimex' in-between the actual clock syncs, to maintain a more-or-less accurate time while running stand-alone.
Sorry for the slow response - my favourite wife forced me to take leave on Thursday and Friday! Thanks for the information. Does Solaris behave similar to Linux? (I still have to tackle the time on a Solaris 9 machine.) On WinXP PCs, the drift between the "slowest" and the "fastest" PCs is around 100 milliseconds per hour - if we manually sync them every hour, we can expect to be in sync to within a quarter of a second (allowing 100 milliseconds error in the sync process.) On the Linux machine, I added a
hwclock --hctosyscommand to crontab, running every 5 minutes - this gives acceptable drift performance (not quite as good as WinXP.) Thanks for the suggestion ofadjtimex- I will have a look at it, but I have a suspicion that this is not available with Linux kernel version 2.4, which we use. Kernel 2.6 definitely supports adjtimex. -
normanS wrote:
my Linux systems drift wildly
I have heard that if you threaten a Windows box with an install CD of *Nix it behaves its self. I wonder if the opposite is true? :) What may I ask are you doing that requires such precision in time keeping?
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
Sorry for the slow response - my favourite wife forced me to take leave on Thursday and Friday! I have managed to force the Linux machine to update system time according to hardware clock every 5 minutes, which gives acceptable timing performance (but not quite as good as XP.) Regrettably, I can't give information of the application - the defence industry are touchy about these things (and the Russians, the Americans, the Chinese, and the South Africans are all monitoring every word I type, and reading my mail.)
-
Sorry for the slow response - my favourite wife forced me to take leave on Thursday and Friday! I have managed to force the Linux machine to update system time according to hardware clock every 5 minutes, which gives acceptable timing performance (but not quite as good as XP.) Regrettably, I can't give information of the application - the defence industry are touchy about these things (and the Russians, the Americans, the Chinese, and the South Africans are all monitoring every word I type, and reading my mail.)
normanS wrote:
Sorry for the slow response - my favourite wife forced me to take leave on Thursday and Friday!
Nothing wrong with taking a few days away from the computer, wish I could do the same. :~
normanS wrote:
I have managed to force the Linux machine to update system time according to hardware clock every 5 minutes, which gives acceptable timing performance (but not quite as good as XP.)
That's very strange behavior. If you ever find out the cause, please feel free to drop me an email with the cause & resolution, if you dont mind.
normanS wrote:
Regrettably, I can't give information of the application
Ah, government type work, no biggie, was idly just curious.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
-
normanS wrote:
Sorry for the slow response - my favourite wife forced me to take leave on Thursday and Friday!
Nothing wrong with taking a few days away from the computer, wish I could do the same. :~
normanS wrote:
I have managed to force the Linux machine to update system time according to hardware clock every 5 minutes, which gives acceptable timing performance (but not quite as good as XP.)
That's very strange behavior. If you ever find out the cause, please feel free to drop me an email with the cause & resolution, if you dont mind.
normanS wrote:
Regrettably, I can't give information of the application
Ah, government type work, no biggie, was idly just curious.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
-
Sorry for the slow response - my favourite wife forced me to take leave on Thursday and Friday! Thanks for the information. Does Solaris behave similar to Linux? (I still have to tackle the time on a Solaris 9 machine.) On WinXP PCs, the drift between the "slowest" and the "fastest" PCs is around 100 milliseconds per hour - if we manually sync them every hour, we can expect to be in sync to within a quarter of a second (allowing 100 milliseconds error in the sync process.) On the Linux machine, I added a
hwclock --hctosyscommand to crontab, running every 5 minutes - this gives acceptable drift performance (not quite as good as WinXP.) Thanks for the suggestion ofadjtimex- I will have a look at it, but I have a suspicion that this is not available with Linux kernel version 2.4, which we use. Kernel 2.6 definitely supports adjtimex.> Does Solaris behave similar to Linux? On the Solaris machines I have worked on (Solaris 8 and previous) they have. The commands may have different names & options, but essentially the same stuff happens. At boot-up, the hardware clock is read, and the value obtained is used as the starting OS clock time. If the hardware clock drift has already been measured, then, throughout the day, the OS will re-sync the hardware clock to the current OS clock time. (About every 11 minutes, as I recall.) I haven't used Solaris 9 or 10, so I don't know if anything has changed. On the Solaris networks I have run, the machine-to-machine clock drift was enough that I had to designate one as the time reference, and had all the others sync their OS clocks to it every hour. (I just used a crontab entry, and the rdate program.) To keep the time server itself correct, I would call a telephone time service every so often, and re-set the servers clock to it. ("At the tone, the time will be ...".) Once every few weeks was usually good enough. I don't have any Solaris machines in front of me, so I can't run down all the different commands that are used to deal with the time-of-day clocks. You'll need to browse thru the man pages (using the apropos command) to find them.
-
> Does Solaris behave similar to Linux? On the Solaris machines I have worked on (Solaris 8 and previous) they have. The commands may have different names & options, but essentially the same stuff happens. At boot-up, the hardware clock is read, and the value obtained is used as the starting OS clock time. If the hardware clock drift has already been measured, then, throughout the day, the OS will re-sync the hardware clock to the current OS clock time. (About every 11 minutes, as I recall.) I haven't used Solaris 9 or 10, so I don't know if anything has changed. On the Solaris networks I have run, the machine-to-machine clock drift was enough that I had to designate one as the time reference, and had all the others sync their OS clocks to it every hour. (I just used a crontab entry, and the rdate program.) To keep the time server itself correct, I would call a telephone time service every so often, and re-set the servers clock to it. ("At the tone, the time will be ...".) Once every few weeks was usually good enough. I don't have any Solaris machines in front of me, so I can't run down all the different commands that are used to deal with the time-of-day clocks. You'll need to browse thru the man pages (using the apropos command) to find them.
I ran 13 PCs overnight (including Solaris 9 PCs for the first time), and at the end of it, picked a WinXP as the reference, and calculated relative drift for the other PCs:
PC OS Drift (secs/hour) Gain/loss
PC1 WinXP 0.043 Loss
PC2 WinXP 0.013 Gain
PC3 WinXP 0.007 Loss
PC4 WinXP 0.044 Loss
PC5 WinXP 0.007 Loss
PC6 WinXP 0.057 GainPC7 Sol9 0.129 Gain
PC8 Sol9 0.142 Gain
PC9 Sol9 0.041 GainPC10 RH8 23.836 Loss No time update
PC11 RH8 24.128 Loss No time updatePC12 RH8 0.110 Loss Sys time update every 5 minutes using "crontab" task
Summary The Windows XP PCs drift at beween a loss of 44 milliseconds per hour and a gain of 57 milliseconds per hour, compared to the reference PC. The Solaris 9 PCs drift at between a gain of 41 milliseconds per hour and a gain of 142 milliseconds per hour, compared to the reference PC. The Red Hat 8 PCs with no time update loose 23.8 and 24.1 seconds per hour, compared to the reference PC. PC12 (Red Hat 8 PCs with crontab time update applied) lost 110 milliseconds per hour, compared to the reference PC. From these results, I think I can fix the worst problems by updating Red Hat system clock according to every hardware clock, about every minute. If necessary, I will look at the Linux adjtimex command. Solaris is probably good enough, but similar corrections are probably applicable. Thanks for your input - I will look at the Solaris commands you mentioned.
-
normanS wrote:
Sorry for the slow response - my favourite wife forced me to take leave on Thursday and Friday!
Nothing wrong with taking a few days away from the computer, wish I could do the same. :~
normanS wrote:
I have managed to force the Linux machine to update system time according to hardware clock every 5 minutes, which gives acceptable timing performance (but not quite as good as XP.)
That's very strange behavior. If you ever find out the cause, please feel free to drop me an email with the cause & resolution, if you dont mind.
normanS wrote:
Regrettably, I can't give information of the application
Ah, government type work, no biggie, was idly just curious.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
I ran 13 PCs overnight (including Solaris 9 PCs for the first time), and at the end of it, picked a WinXP as the reference, and calculated relative drift for the other PCs:
PC OS Drift (secs/hour) Gain/loss
PC1 WinXP 0.043 Loss
PC2 WinXP 0.013 Gain
PC3 WinXP 0.007 Loss
PC4 WinXP 0.044 Loss
PC5 WinXP 0.007 Loss
PC6 WinXP 0.057 GainPC7 Sol9 0.129 Gain
PC8 Sol9 0.142 Gain
PC9 Sol9 0.041 GainPC10 RH8 23.836 Loss No time update
PC11 RH8 24.128 Loss No time updatePC12 RH8 0.110 Loss Sys time update every 5 minutes using "crontab" task
Summary The Windows XP PCs drift at beween a loss of 44 milliseconds per hour and a gain of 57 milliseconds per hour, compared to the reference PC. The Solaris 9 PCs drift at between a gain of 41 milliseconds per hour and a gain of 142 milliseconds per hour, compared to the reference PC. The Red Hat 8 PCs with no time update loose 23.8 and 24.1 seconds per hour, compared to the reference PC. PC12 (Red Hat 8 PCs with crontab time update applied) lost 110 milliseconds per hour, compared to the reference PC. From these results, I think I can fix the worst problems by updating Red Hat system clock according to every hardware clock, about every minute. If necessary, I will look at the Linux
adjtimexcommand. Solaris is probably good enough, but similar corrections are probably applicable. -
I ran 13 PCs overnight (including Solaris 9 PCs for the first time), and at the end of it, picked a WinXP as the reference, and calculated relative drift for the other PCs:
PC OS Drift (secs/hour) Gain/loss
PC1 WinXP 0.043 Loss
PC2 WinXP 0.013 Gain
PC3 WinXP 0.007 Loss
PC4 WinXP 0.044 Loss
PC5 WinXP 0.007 Loss
PC6 WinXP 0.057 GainPC7 Sol9 0.129 Gain
PC8 Sol9 0.142 Gain
PC9 Sol9 0.041 GainPC10 RH8 23.836 Loss No time update
PC11 RH8 24.128 Loss No time updatePC12 RH8 0.110 Loss Sys time update every 5 minutes using "crontab" task
Summary The Windows XP PCs drift at beween a loss of 44 milliseconds per hour and a gain of 57 milliseconds per hour, compared to the reference PC. The Solaris 9 PCs drift at between a gain of 41 milliseconds per hour and a gain of 142 milliseconds per hour, compared to the reference PC. The Red Hat 8 PCs with no time update loose 23.8 and 24.1 seconds per hour, compared to the reference PC. PC12 (Red Hat 8 PCs with crontab time update applied) lost 110 milliseconds per hour, compared to the reference PC. From these results, I think I can fix the worst problems by updating Red Hat system clock according to every hardware clock, about every minute. If necessary, I will look at the Linux
adjtimexcommand. Solaris is probably good enough, but similar corrections are probably applicable.So your posts got me to Googling. Personally I have never had any issues with any OS drifting out of sync, then again most of what I run is Win2k. As it turns out your apparently not the first person to have this issue. I don’t know if it’s strictly a Redhat issue alone (I really doubt that). Here are a couple of links for you to look at. It would seem that most people just find a way to sync their clock with an external NNTP server. As you have already said that’s not really an options for you. So I'm at a bit of a loss, why would RH have such an issue keeping time. http://www.tldp.org/HOWTO/Clock-3.html[^] http://www.vanemery.com/Linux/RH-Linux-Time.html[^] It would seem you can make adjustments to hwclock to help with this issue (I wouldn’t be surprised if you hadn’t already tried this but it worth mentioning anyway). Try this: 1. Physically disconnect the system from any network. 2. Boot the box and stop these services; anacron, atd, & crond 3. Run "hwclock --systohc" and note the time. If the system still changes time after running in this state for a while, then your computer is possessed.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
-
So your posts got me to Googling. Personally I have never had any issues with any OS drifting out of sync, then again most of what I run is Win2k. As it turns out your apparently not the first person to have this issue. I don’t know if it’s strictly a Redhat issue alone (I really doubt that). Here are a couple of links for you to look at. It would seem that most people just find a way to sync their clock with an external NNTP server. As you have already said that’s not really an options for you. So I'm at a bit of a loss, why would RH have such an issue keeping time. http://www.tldp.org/HOWTO/Clock-3.html[^] http://www.vanemery.com/Linux/RH-Linux-Time.html[^] It would seem you can make adjustments to hwclock to help with this issue (I wouldn’t be surprised if you hadn’t already tried this but it worth mentioning anyway). Try this: 1. Physically disconnect the system from any network. 2. Boot the box and stop these services; anacron, atd, & crond 3. Run "hwclock --systohc" and note the time. If the system still changes time after running in this state for a while, then your computer is possessed.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
The PC clock drift differentials don't look to bad -- as long as you are just comparing them to another PC clock. A more interesting (though perhaps useless to your application) test would be to keep your reference PC sync'd to a real time server (via NTP or GPS), and then measure the drift of the others from that. Note also, that there is still a 8:1 difference in drift rates. The 'better' PCs will drift one second in about 6 days; the worst will drift 1 sec/day. Solaris 9 PCs -- I don't know how Solaris deals with PC hardware, so I don't know where these drifts come from. As for the RedHat PCs -- these drifts seem way out of whack, but you are sort-of comparing apples to donuts. The PC HW clocks have their own crystal oscillators, which have temperature & accuracy specs that are similar to each other. For Linux, after reading the HW clock, the OS uses the regular timer interrupts (those 60/sec, 100/sec, or 1000/sec interrupts), which come from a different oscillator, to update the time-of-day clock. (The programmable timer interrupt chip supplies these interrupts; Linux configures the interval it wants.) RedHat 8 may not have adjtimex, but you could always measure the drift (as you have), then have your crontab script make adjustments to counteract it.
-
So your posts got me to Googling. Personally I have never had any issues with any OS drifting out of sync, then again most of what I run is Win2k. As it turns out your apparently not the first person to have this issue. I don’t know if it’s strictly a Redhat issue alone (I really doubt that). Here are a couple of links for you to look at. It would seem that most people just find a way to sync their clock with an external NNTP server. As you have already said that’s not really an options for you. So I'm at a bit of a loss, why would RH have such an issue keeping time. http://www.tldp.org/HOWTO/Clock-3.html[^] http://www.vanemery.com/Linux/RH-Linux-Time.html[^] It would seem you can make adjustments to hwclock to help with this issue (I wouldn’t be surprised if you hadn’t already tried this but it worth mentioning anyway). Try this: 1. Physically disconnect the system from any network. 2. Boot the box and stop these services; anacron, atd, & crond 3. Run "hwclock --systohc" and note the time. If the system still changes time after running in this state for a while, then your computer is possessed.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
Thanks for the links - I had not seen the TLDP site, and that looks useful. I ran another test over the weekend, with RedHat8 PCs doing "hwclock --hctosys" every minute via crontab - the result is a drift of about 100 milliseconds per hour, which I can live with. The timing jitters a bit, but it's probably OK. I haven't got around to making HWCLOCK adjustments, since adjtimex is not part of the standard installation with redHat8. I could live with the crontab "hwclock --hctosys" solution, but I think that adjtimex will probably provide a cleaner solution, so that is my next direction to explore. The Solaris PCs wait until they think they have 2 second error in system clock, then they implement a correction over a period of a few minutes, so you get occasional steps, forward or back, depending on the PC Interesting problem, isn't it? And someone's paying me to play with this stuff - hey, I'd do this for fun!
-
The PC clock drift differentials don't look to bad -- as long as you are just comparing them to another PC clock. A more interesting (though perhaps useless to your application) test would be to keep your reference PC sync'd to a real time server (via NTP or GPS), and then measure the drift of the others from that. Note also, that there is still a 8:1 difference in drift rates. The 'better' PCs will drift one second in about 6 days; the worst will drift 1 sec/day. Solaris 9 PCs -- I don't know how Solaris deals with PC hardware, so I don't know where these drifts come from. As for the RedHat PCs -- these drifts seem way out of whack, but you are sort-of comparing apples to donuts. The PC HW clocks have their own crystal oscillators, which have temperature & accuracy specs that are similar to each other. For Linux, after reading the HW clock, the OS uses the regular timer interrupts (those 60/sec, 100/sec, or 1000/sec interrupts), which come from a different oscillator, to update the time-of-day clock. (The programmable timer interrupt chip supplies these interrupts; Linux configures the interval it wants.) RedHat 8 may not have adjtimex, but you could always measure the drift (as you have), then have your crontab script make adjustments to counteract it.
Lenny D. wrote:
Note also, that there is still a 8:1 difference in drift rates. The 'better' PCs will drift one second in about 6 days; the worst will drift 1 sec/day.
I will work with the worst case and synchronise every 2 hours, so the maximum relative drift will be in the order of 200 milliseconds (one PC loosing 50 milliseconds per hour relative to the reference PC, another gaining 50 milliseconds per hour relative to the reference.)
Lenny D. wrote:
Solaris 9 PCs -- I don't know how Solaris deals with PC hardware, so I don't know where these drifts come from.
Maybe it's coincidence, but all the Solaris PCs gain about 150 milliseconds per hour, compared to the Reference PC. I haven't got around to applying clock corrections on Solaris PCs yet. I ran a test over the weekend, with the RedHat PCs setting their system clock to hardware clock every minute. The RedHat PCs now drift about 100 milliseconds per hour, although the timing does have some jitter. I'll investigate adjtimex some more - it is probably on the RH8 installation disks. Solaris also provides ways of adjusting the system and hardware clocks, but RH8 and Solaris documentation is confusing! I guess I need to RTFM some more. Aaargh.