Yesterday on my comp two separate running images are hung simultaneously, while i were doing something completely outside of them. And now during reading the sqUnixHeartBeat.c: /* The native clock may go backwards, e.g. due to NTP adjustments, although * why it can't avoid small backward steps itself, I don't know. Simply * ignore backward steps and wait until the clock catches up again. Of * course this will cause problems if the clock is manually adjusted. To * which the doctor says, "don't do that". */ i start recalling that yesterday i adjusted clock back by 1 hour, because after installing a windoze in dual boot it was set it wrongly. But of course it could be anything else :) -- Best regards, Igor Stasenko AKA sig. |
Every time I jump back and forth from Windows to Linux on my primary laptop, the clock is wrong... On Tue, Jan 11, 2011 at 4:37 PM, Igor Stasenko <[hidden email]> wrote: > > Yesterday on my comp two separate running images are hung > simultaneously, while i were doing something completely outside of > them. > > And now during reading the sqUnixHeartBeat.c: > > > /* The native clock may go backwards, e.g. due to NTP adjustments, although > * why it can't avoid small backward steps itself, I don't know. Simply > * ignore backward steps and wait until the clock catches up again. Of > * course this will cause problems if the clock is manually adjusted. To > * which the doctor says, "don't do that". > */ > > i start recalling that yesterday i adjusted clock back by 1 hour, > because after installing a windoze in dual boot it was set it wrongly. > > But of course it could be anything else :) > > -- > Best regards, > Igor Stasenko AKA sig. > |
Some images grind logic thru the locale plugin to set the current time/date based on UTC & locale's viewpoint of time zone. You should peer deeper to understand exactly who/where the printed time is coming from... On 2011-01-11, at 5:18 PM, Chris Muller wrote: > > Every time I jump back and forth from Windows to Linux on my primary > laptop, the clock is wrong... > > On Tue, Jan 11, 2011 at 4:37 PM, Igor Stasenko <[hidden email]> wrote: >> >> Yesterday on my comp two separate running images are hung >> simultaneously, while i were doing something completely outside of >> them. >> >> And now during reading the sqUnixHeartBeat.c: >> >> >> /* The native clock may go backwards, e.g. due to NTP adjustments, although >> * why it can't avoid small backward steps itself, I don't know. Simply >> * ignore backward steps and wait until the clock catches up again. Of >> * course this will cause problems if the clock is manually adjusted. To >> * which the doctor says, "don't do that". >> */ >> >> i start recalling that yesterday i adjusted clock back by 1 hour, >> because after installing a windoze in dual boot it was set it wrongly. >> >> But of course it could be anything else :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
In reply to this post by Chris Muller-3
Yes, Windows like to set the CMOS clock to local time, and Linux likes to use UTC. My brother recently ran into a similar problem with a FreeBSD machine running as a guest inside a Windows host. He had to touch /etc/wall_cmos_clock to fix it. From the adjkerntz man page: If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps local time (MS-DOS and MS-Windows compatible mode). If that file does not exist, it means that the CMOS clock keeps UTC time. Maybe there's a similar Linux/Mac fix? frank On 2011/01/12 01:18, Chris Muller wrote: > > Every time I jump back and forth from Windows to Linux on my primary > laptop, the clock is wrong... > > On Tue, Jan 11, 2011 at 4:37 PM, Igor Stasenko<[hidden email]> wrote: >> >> Yesterday on my comp two separate running images are hung >> simultaneously, while i were doing something completely outside of >> them. >> >> And now during reading the sqUnixHeartBeat.c: >> >> >> /* The native clock may go backwards, e.g. due to NTP adjustments, although >> * why it can't avoid small backward steps itself, I don't know. Simply >> * ignore backward steps and wait until the clock catches up again. Of >> * course this will cause problems if the clock is manually adjusted. To >> * which the doctor says, "don't do that". >> */ >> >> i start recalling that yesterday i adjusted clock back by 1 hour, >> because after installing a windoze in dual boot it was set it wrongly. >> >> But of course it could be anything else :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > |
On Wed, 12 Jan 2011, Frank Shearar wrote: > > Yes, Windows like to set the CMOS clock to local time, and Linux likes to use > UTC. > > My brother recently ran into a similar problem with a FreeBSD machine running > as a guest inside a Windows host. He had to touch /etc/wall_cmos_clock to fix > it. > > From the adjkerntz man page: > > If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps local > time (MS-DOS and MS-Windows compatible mode). If that file does not exist, > it means that the CMOS clock keeps UTC time. > > Maybe there's a similar Linux/Mac fix? Yes, there is, but different linux distributions have different files IIRC. Btw, if you tell linux to assume that the hardware clock stores the local time, you'll still have problems after daylight saving related time changes, because both OSs will adjust the clock. Levente > > frank > > On 2011/01/12 01:18, Chris Muller wrote: >> >> Every time I jump back and forth from Windows to Linux on my primary >> laptop, the clock is wrong... >> >> On Tue, Jan 11, 2011 at 4:37 PM, Igor Stasenko<[hidden email]> wrote: >>> >>> Yesterday on my comp two separate running images are hung >>> simultaneously, while i were doing something completely outside of >>> them. >>> >>> And now during reading the sqUnixHeartBeat.c: >>> >>> >>> /* The native clock may go backwards, e.g. due to NTP adjustments, >>> although >>> * why it can't avoid small backward steps itself, I don't know. >>> Simply >>> * ignore backward steps and wait until the clock catches up >>> again. Of >>> * course this will cause problems if the clock is manually >>> adjusted. To >>> * which the doctor says, "don't do that". >>> */ >>> >>> i start recalling that yesterday i adjusted clock back by 1 hour, >>> because after installing a windoze in dual boot it was set it wrongly. >>> >>> But of course it could be anything else :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> > > |
Well, putting the CMOS stuff aside, i really don't like that VM could hang indefinitely if user will adjust the clock settings. On 12 January 2011 13:22, Levente Uzonyi <[hidden email]> wrote: > > On Wed, 12 Jan 2011, Frank Shearar wrote: > >> >> Yes, Windows like to set the CMOS clock to local time, and Linux likes to >> use UTC. >> >> My brother recently ran into a similar problem with a FreeBSD machine >> running as a guest inside a Windows host. He had to touch >> /etc/wall_cmos_clock to fix it. >> >> From the adjkerntz man page: >> >> If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps >> local time (MS-DOS and MS-Windows compatible mode). If that file does not >> exist, it means that the CMOS clock keeps UTC time. >> >> Maybe there's a similar Linux/Mac fix? > > Yes, there is, but different linux distributions have different files IIRC. > Btw, if you tell linux to assume that the hardware clock stores the local > time, you'll still have problems after daylight saving related time changes, > because both OSs will adjust the clock. > > > Levente > >> >> frank >> >> On 2011/01/12 01:18, Chris Muller wrote: >>> >>> Every time I jump back and forth from Windows to Linux on my primary >>> laptop, the clock is wrong... >>> >>> On Tue, Jan 11, 2011 at 4:37 PM, Igor Stasenko<[hidden email]> >>> wrote: >>>> >>>> Yesterday on my comp two separate running images are hung >>>> simultaneously, while i were doing something completely outside of >>>> them. >>>> >>>> And now during reading the sqUnixHeartBeat.c: >>>> >>>> >>>> /* The native clock may go backwards, e.g. due to NTP >>>> adjustments, although >>>> * why it can't avoid small backward steps itself, I don't know. >>>> Simply >>>> * ignore backward steps and wait until the clock catches up >>>> again. Of >>>> * course this will cause problems if the clock is manually >>>> adjusted. To >>>> * which the doctor says, "don't do that". >>>> */ >>>> >>>> i start recalling that yesterday i adjusted clock back by 1 hour, >>>> because after installing a windoze in dual boot it was set it wrongly. >>>> >>>> But of course it could be anything else :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >> >> > -- Best regards, Igor Stasenko AKA sig. |
So what's the algorithm? If the time changes by more than half an hour (between the heartbeat sampling the clock) it's a clock change but if its less than half an hour its clock drift. What threshold value would you use? 10 minutes? Half an hour? A minute? I'm interested in opinions here This is easy to add and a good idea, but getting that magic constant right is important. On Wed, Jan 12, 2011 at 4:24 AM, Igor Stasenko <[hidden email]> wrote:
|
On 12.01.2011, at 19:17, Eliot Miranda wrote: > So what's the algorithm? If the time changes by more than half an hour (between the heartbeat sampling the clock) it's a clock change but if its less than half an hour its clock drift. What threshold value would you use? 10 minutes? Half an hour? A minute? I'm interested in opinions here This is easy to add and a good idea, but getting that magic constant right is important. The smallest legitimate difference due to timezone adjustment is 15 minutes (e.g. when you travel between Nepal and India). That should not get ignored, so it is a hard upper bound. But you want to go as low as possible. When my computer's clock has drifted more than a minute I might want to adjust it, and I'd expect Squeak to catch up. So going below a minute would be good. Do we have evidence what deltas you actually get for a drifting clock? - Bert - |
Free forum by Nabble | Edit this page |