Windows vs Linux time of day [modified]
-
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.