If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
Clocks going forward
NY wrote:
"Paul" wrote in message news A tiny tidbit people might not be getting here, is how OS time works. System boots OS copies RTC_time (i.e. BIOS time) to software clock. OS increments software clock based on hardware interrupts (clock_tick or similar). During the day, the software clock "drifts" with respect to the RTC. System needs to shut down. OS can copy the software clock, back into the RTC. And a given OS assumes its choice of hours-keeping, is the only choice, so if it uses LocalTime, every OS is using LocalTime. (RTC runs on the CMOS clock battery if all power is lost. RTC runs on +5VSB if you leave PC power ON at the back. RTC "keeps the time", when the OS is not available to do it.) While NTP is an additional variable, the polling rate of NTP is on purpose, way too low, to be used as a "crutch" to fix this LocalTime issue. For example, my current OS only checks in with NTP once a week, so if I had a LocalTime/UTC issue, it would take a week without intervention, to get some sort of correction. Following an earlier discussion on this thread a week or so, I've now tweaked my registry so the PC polls its NTP server every 24 hours rather than every week to bring it back into sync. Before I did this, I found that my desktop PC which remains on 24/7 as a server, video recorder and weather-station data-acquisition, was getting out of sync with my laptop which gets put to sleep and woken up fairly frequently and so is relying on accuracy of RTC more than the desktop which relies entirely on OS clock. The difference was sometimes as much as a couple of minutes, which I cured either by forcing an unscheduled NTP sync with the internet server, or else by "net time \\server-PC /set /y" from a elevated DOS prompt, as and when I noticed it. Now it's rare for me to see the two PCs displaying a different time. Just now, I noticed the difference was about 10 seconds, and both PCs are probably due to resync fairly soon. The time.is website has just shown that the laptop is 11 seconds slow and the desktop is bang on. A drift of 10 seconds or so per day (as long as it's not cumulative!) is something I can live with. You can improve on this. As far as I know, the Windows implementation of NTP, doesn't "dribble out" first order corrections. Say, for example, the clock is off by 24 seconds per day. I could, if I had the right software, automatically adjust the software clock once an hour, removing a second. (And do this, *without* pestering an NTP server in the process.) And perhaps bringing me back into perfect sync. And because I was doing the "dribbling" regularly, the apparent time difference between machines is quite small. Drift on real quartz crystals, is not first order, and so dribbling out a 1 second correction every hour, doesn't guarantee 1 second accuracy. Windows, on the other hand, if you set it to "check in" every 24 hours, only notices the time is off by 24 seconds, and makes one huge 24 second correction. I'm not aware of any attempt by Windows to "dribble", even though the Windows time log shows the Windows service "wakes up and thinks" every fifteen minutes. It just doesn't seem to do anything when it wakes up, and it goes back to sleep. It's a free third-party NTP implementation, that implements the dribbling method. And the dribbling method is probably part of a standard, and it's a behavior Microsoft didn't bother to include. So it is possible, to "pull in" the error a tiny bit, and make it look apparently better. But the dribbling method assumes the clock drift is a static frequency offset in the quartz crystal. For example, if the quartz crystal is nominally 1,000,000 Hz but instead runs at 1,000,050, then you could compensate for the speedup, by once an hour, adjusting the seconds on the time, according to the historic drift seen. If the quartz crystal was always fast, you could do a better job of eliminating the static error by dribbling. Good NTP software keeps track of the apparent drift, over many NTP server checks, so it can predict what the static error on the quartz crystal is. This is an example of an NTP program. https://www.meinbergglobal.com/english/sw/ntp.htm I don't use any of these methods, and the above is included only if you're an "obsessive" time person :-) With the right third-party software, you can do a little bit better, and without raising the polling rate. ******* You can run your own reference clock at home, and you can also nominate one machine in your home to "serve" time via NTP, to the other machines. Damn good clocks have dropped to the $1000 level in price. This is not a survey attempt at finding the cheapest one, and just illustrates that you don't have to pay a quarter million any more to have tech like this. https://www.popsci.com/technology/ar...-ever-now-sale We had a rack-mount version at work, that was GPS disciplined, and it was all in aid of having a reference grade 10MHz clock for a bench full of test equipment. And the engineer doing the work, wanted a proper reference, so the boss forked over for a "good" rack mount clock. "You could set your watch by it" :-) And the other engineers used to make a joke of this, by standing near the equipment, and pretending to set their watches :-) You need a nerd sense of humor for this. Paul |
Ads |
#17
|
|||
|
|||
Clocks going forward
On 02/04/2018 22:11, VanguardLH wrote:
[a load of needlessly confusing and irrelevant information] VanguardLH, FFS read other people's posts! At least two other people have already answered this question perfectly satisfactorily, without all this irrelevant verbage. The one thing missing is that the OP has not come back to tell us that he's seen the solutions offered, applied them, and thereby solved the problem. However, this may well be because he hasn't even seen them, as his original post was in uk.tech.broadcast, but it came here when a reply was copied here ... On 01/04/2018 13:01, J. P. Gilliver (John) wrote: (Crossposted to a Windows 'group - may not be the right one, don't know which one you're using - as someone there is likely to know the correct incantations.) .... but actually he'd've done better to crosspost to a Linux ng, because that's where the simplest solution lies. |
#18
|
|||
|
|||
Clocks going forward
In message , Paul
writes: [] It's a free third-party NTP implementation, that implements the dribbling method. And the dribbling method is probably part of a standard, and it's a behavior Microsoft didn't bother to include. [] What, Microsoft not bothering with part of a standard? (-: -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Everyone learns from science. It all depends how you use the knowledge. - "Gil Grissom" (CSI). |
#19
|
|||
|
|||
Clocks going forward
J. P. Gilliver (John) wrote:
In message , Paul writes: [] It's a free third-party NTP implementation, that implements the dribbling method. And the dribbling method is probably part of a standard, and it's a behavior Microsoft didn't bother to include. [] What, Microsoft not bothering with part of a standard? (-: I'm not an NTP expert, but I notice other people seem to like the third-party implementations. As long as my computer clock shows the right day of the week, I'm pretty happy. I think it would be fun to have a ridiculously accurate time piece in the computer room here (so I could compete with Jeff Bezos), but I don't have $1000+ kicking around. Paul |
#20
|
|||
|
|||
Clocks going forward
On Mon, 02 Apr 2018 23:45:59 -0400, Paul wrote:
J. P. Gilliver (John) wrote: In message , Paul writes: [] It's a free third-party NTP implementation, that implements the dribbling method. And the dribbling method is probably part of a standard, and it's a behavior Microsoft didn't bother to include. [] What, Microsoft not bothering with part of a standard? (-: I'm not an NTP expert, but I notice other people seem to like the third-party implementations. As long as my computer clock shows the right day of the week, I'm pretty happy. I think it would be fun to have a ridiculously accurate time piece in the computer room here (so I could compete with Jeff Bezos), but I don't have $1000+ kicking around. NTP can get to within a few thousandths of a second, so that's close enough to "ridiculously accurate" to satisfy me. The latest update here was +0.006 seconds. -- Char Jackson |
#21
|
|||
|
|||
Clocks going forward
Char Jackson wrote:
On Mon, 02 Apr 2018 23:45:59 -0400, Paul wrote: J. P. Gilliver (John) wrote: In message , Paul writes: [] It's a free third-party NTP implementation, that implements the dribbling method. And the dribbling method is probably part of a standard, and it's a behavior Microsoft didn't bother to include. [] What, Microsoft not bothering with part of a standard? (-: I'm not an NTP expert, but I notice other people seem to like the third-party implementations. As long as my computer clock shows the right day of the week, I'm pretty happy. I think it would be fun to have a ridiculously accurate time piece in the computer room here (so I could compete with Jeff Bezos), but I don't have $1000+ kicking around. NTP can get to within a few thousandths of a second, so that's close enough to "ridiculously accurate" to satisfy me. The latest update here was +0.006 seconds. Well, the ridiculous option, would probably add another five or six digits to that :-) And that was part of making fun of the instrument (the absurdity of setting your watch by it). It was purchased for the 10MHz reference on the back, rather than for the time piece on the front. But the clock display on the front, was what attracted visitors to the lab. It's basically an atomic clock. It would have these kinds of properties, at a guess. As ours did use GPS, and we ran an antenna up to the roof of the office building for it. http://www.synreference.net/atomic "To achieve even greater long-term stability, the Rubidium reference is locked to the GPS/GNSS. This combination gives you the best of three technologies - the stability of Rubidium, the low noise of an OCXO and the long-term stability of GPS/GNSS." The OCXO is an Oven controlled crystal oscillator. I doubt we'd be so lucky, as to have the Rubidium output a signal which is a multiple of 10MHz. And the lab standard for frequency is 10MHz, and quite a few instruments have an input for that on the back. The cheapest instrument that accepts 10MHz on the back, is a frequency counter. But that's not why we bought that piece of kit. Paul |
#23
|
|||
|
|||
Clocks going forward
On 01/04/2018 13:01, J. P. Gilliver (John) wrote:
In message , Roderick Stewart writes: [] For the next six months or so I'll have to remember to correct the time on my computer every time I boot it into Windows after using Linux. It's not difficult - I just go to the settings page that has the little switch for "Set time automatically" and follow the traditional procedure of switching it off and switching it on again - but I always have to remember to do it, so the sooner this nonsense ends permanently, the better. Since it looks unlikely that it will )-:, can't you put a batch file to do that off-and-then-on-again into your startup folder? I'd be surprised if there isn't a command line version of "go to the settings page and ... switching it off and switching it on again". (Crossposted to a Windows 'group - may not be the right one, don't know which one you're using - as someone there is likely to know the correct incantations.) Rod. John I thought many Linux distros had the option to set the hardware clock to local time rather than to UTC. You could also install this on your Windows: https://www.meinbergglobal.com/english/sw/ntp.htm It's much better than the built in Windows NTP client. Why can't I see the OP's original message? -- Brian Gregory (in England). |
#24
|
|||
|
|||
Clocks going forward
On 03/04/2018 17:24, Brian Gregory wrote:
I thought many Linux distros had the option to set the hardware clock to local time rather than to UTC. If you know how, you can both tell Linux to set the BIOS clock to local time or Windows to set it to UTC. As far as programs and users are concerned, the system clock is set to local time in both cases, updated to match the BIOS clock at boot time, with the appropriate offset applied. -- Tciao for Now! John. |
#25
|
|||
|
|||
Clocks going forward
On 03/04/2018 17:30, John Williamson wrote:
On 03/04/2018 17:24, Brian Gregory wrote: I thought many Linux distros had the option to set the hardware clock to local time rather than to UTC. If you know how, you can both tell Linux to set the BIOS clock to local time or Windows to set it to UTC. As far as programs and users are concerned, the system clock is set to local time in both cases, updated to match the BIOS clock at boot time, with the appropriate offset applied. Excellent. Then setting Windows to expect the hardware clock to be UTC is definitely the way to go. That would avoid the weirdness at the time changes where both OSs change the time, not knowing the other has already done or will do it. I found this explaining how to do it: https://superuser.com/questions/185773/does-windows-7-support-utc-as-bios-time/1263384 -- Brian Gregory (in England). |
#26
|
|||
|
|||
Clocks going forward
On Sun, 01 Apr 2018 13:01:42 +0100, J. P. Gilliver (John) wrote:
In message , Roderick Stewart writes: [] For the next six months or so I'll have to remember to correct the time on my computer every time I boot it into Windows after using Linux. It's not difficult - I just go to the settings page that has the little switch for "Set time automatically" and follow the traditional procedure of switching it off and switching it on again - but I always have to remember to do it, so the sooner this nonsense ends permanently, the better. Since it looks unlikely that it will )-:, can't you put a batch file to do that off-and-then-on-again into your startup folder? I'd be surprised if there isn't a command line version of "go to the settings page and ... switching it off and switching it on again". (Crossposted to a Windows 'group - may not be the right one, don't know which one you're using - as someone there is likely to know the correct incantations.) Rod. John Since you are only 1 hour off I assume that has something to do with DST. Linux by default uses UTC and adjusts the display time after booting. The bios clock is set to the UST time. Windows sets the bios to local time. A google search turns up some explanation that this somehow makes it easier for Linux machines to be relocated and recommends leaving Linux alone and fiddling with the windows registry. I neither like or understand that and set Linux to use local time this works for me on Linux Mint using: timedatectl set-local-rtc 1 Eventually whatever settings are used, the system will eventually fix itself assuming you have it update from an Internet standard. I don't know how long this might be in Linux, but it's fairly quick. Windows is much longer wait. Prior to that it will display the bios time. Personally, I think the bios should show me the current local time, although I doubt any of us actually check the setting. |
#27
|
|||
|
|||
Clocks going forward
On Thu, 05 Apr 2018 15:20:12 +0000, Dave wrote:
On Sun, 01 Apr 2018 13:01:42 +0100, J. P. Gilliver (John) wrote: In message , Roderick Stewart writes: [] For the next six months or so I'll have to remember to correct the time on my computer every time I boot it into Windows after using Linux. It's not difficult - I just go to the settings page that has the little switch for "Set time automatically" and follow the traditional procedure of switching it off and switching it on again - but I always have to remember to do it, so the sooner this nonsense ends permanently, the better. Since it looks unlikely that it will )-:, can't you put a batch file to do that off-and-then-on-again into your startup folder? I'd be surprised if there isn't a command line version of "go to the settings page and ... switching it off and switching it on again". (Crossposted to a Windows 'group - may not be the right one, don't know which one you're using - as someone there is likely to know the correct incantations.) Rod. John Since you are only 1 hour off I assume that has something to do with DST. Linux by default uses UTC and adjusts the display time after booting. The bios clock is set to the UST time. Windows sets the bios to local time. A google search turns up some explanation that this somehow makes it easier for Linux machines to be relocated and recommends leaving Linux alone and fiddling with the windows registry. I neither like or understand that and set Linux to use local time this works for me on Linux Mint using: timedatectl set-local-rtc 1 Eventually whatever settings are used, the system will eventually fix itself assuming you have it update from an Internet standard. I don't know how long this might be in Linux, but it's fairly quick. Windows is much longer wait. Prior to that it will display the bios time. Personally, I think the bios should show me the current local time, although I doubt any of us actually check the setting. When I installed Linux Mint 17.1 just on 3 years ago, I chose to go with the "set the RTC to UTC" option since I was never ever going to be using dual/multiboot, preferring to run any windows OSen as virtual machines under Oracle's VirtualBox. I run this desktop setup 24/7 most of the time and, likewise the winXP VM. both the host and the guest OSes handle the DST changes seamlessly (presumably VBox virtualises the RTC as well. :-) -- Johnny B Good |
#28
|
|||
|
|||
Clocks going forward
On 04/05/2018 11:20 AM, Dave wrote:
Personally, I think the bios should show me the current local time, although I doubt any of us actually check the setting. I've got a 55" smart TV and for the heck of it I looked at the update setting but it bulked that I didn't have time set. I've been using it over 18 months and never had the time set OR EVEN looked at it! Not that it's used in any way I use the TV. |
#29
|
|||
|
|||
Clocks going forward
On 05/04/2018 16:20, Dave wrote:
Since you are only 1 hour off I assume that has something to do with DST. Linux by default uses UTC and adjusts the display time after booting. The bios clock is set to the UST time. Windows sets the bios to local time. A google search turns up some explanation that this somehow makes it easier for Linux machines to be relocated and recommends leaving Linux alone and fiddling with the windows registry. I neither like or understand that and set Linux to use local time this works for me on Linux Mint using: timedatectl set-local-rtc 1 Eventually whatever settings are used, the system will eventually fix itself assuming you have it update from an Internet standard. I don't know how long this might be in Linux, but it's fairly quick. Windows is much longer wait. Prior to that it will display the bios time. Personally, I think the bios should show me the current local time, although I doubt any of us actually check the setting. One beauty of computers is that there is always more than one way of doing any given job. In this case, at least three fairly simple ways have been detailed in this thread, so choose the one that suits you. -- Tciao for Now! John. |
#30
|
|||
|
|||
Clocks going forward
On 04/05/2018 10:33 AM, Johnny B Good wrote:
[snip] When I installed Linux Mint 17.1 just on 3 years ago, I chose to go with the "set the RTC to UTC" option since I was never ever going to be using dual/multiboot, preferring to run any windows OSen as virtual machines under Oracle's VirtualBox. I run this desktop setup 24/7 most of the time and, likewise the winXP VM. both the host and the guest OSes handle the DST changes seamlessly (presumably VBox virtualises the RTC as well. :-) That's what I do on my main machine (Linux host, Windows in VM). I never have any DST-related problems. Hardware RTC is set to UTC. BTW, I have 4 versions of Windows here (2000, XP, 7, 10) in separate VMs. -- Mark Lloyd http://notstupid.us/ "And lo, Jesus did say unto the soldiers 'Not the OTHER hand. Ow ****, that hurts! You assholes!' " [2 Kinison 3:45] |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|