Smalltalk › Squeak › Squeak VM

Fwd: [Pharo-project] System time

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

stephane ducasse-2

Fwd: [Pharo-project] System time

Begin forwarded message:

> From: Jimmie Houchin <[hidden email]>
> Date: May 1, 2011 4:15:40 AM GMT+02:00
> To: [hidden email]
> Subject: Re: [Pharo-project] System time
> Reply-To: [hidden email]
>
> Hello,
>
> My OS for this application is Windows. On a freshly opened image, the image and OS time are in sync. Over a period of time the image drifted 34 seconds away from OS time. I do not know how long I had this image open, but it has been a number of days, possibly a week plus.
>
> I saved the image and quit. I reopened the image and did DateAndTime now and it was in sync with the OS once again. Same image, vm and OS that was out of sync by 34 seconds only one minute before.
>
> I have opened an image on my server which is also running the latest cog vm, the current Pharo 1.3 and Windows Vista. I am going to periodically do a DateAndTime now to log the drift if any. Prior to opening this image I updated the OS system clock with time.nist.gov which is about 1000 miles away.
>
> I know that within a second or so it can be subject to my coordination of doing DateAndTime now while watching my OS system clocks seconds. But 34 seconds is beyond any subjective standards.
>
> The only reason I discovered this was while exploring how I want to retrieve my data, act upon my data and then pause (Delay wait) until time to repeat.
> dtnow := DateAndTime now.
> dtnext := DateAndTime year: 2011 month: 4 day: 30 hour: 11 minute: i second: 5. "The next minute in the future"
> (Delay forDuration: (dtnext - dtnow)) wait.
>
> I got an error, that Duration cannot be a negative number. As I processed the debugger, I saw that dtnow was greater than dtnext. I watched the OS clock and manually selected the next minute before I executed. However, I was within that 34 second window.
>
> So now I am exploring the problem.
>
> Thanks.
>
> Jimmie
>
> On 4/30/2011 5:06 PM, Alexandre Bergel wrote:
>> 'Time now' gives me the same result than OSX
>>
>> Alexandre
>>
>>
>> On 30 Apr 2011, at 16:15, Jimmie Houchin wrote:
>>
>>> On 4/30/2011 11:50 AM, Stéphane Ducasse wrote:
>>>>> I am developing a time sensitive application. I poll a server every minute for new data. The data is time sensitive and the sooner I can get the data to the release of the data the better.
>>>>>
>>>>> I have noticed that Pharo's system time drifts away from the OS system time. I would really like the Pharo system time to be the correct time.
>>>> do you have a repeatable scenario?
>>>> VM
>>>> Image information.
>>> Pharo 1.3 and the latest Cog.
>>>
>>>>> I have not been able to find where in Pharo I can call to update the System clock to the correct time.
>>>> you can use OSProcess (only mac and linux)
>>> No, that's not the problem. The OS clock is right. It's Pharo that has drifted away from correct time. Regardless it would be nice if I have to correct the OS clock, it would still be nice to resync Pharo with the OS, keep both in sync and correct. What I am wanting is simply to resync the Pharo clock with the OS clock.
>>>
>>> It seems that when the Pharo image is started that it gets the OS System time, but keeps its own time after that. Now I do not know the consequences of Pharo adjusting its time backward. If this isn't possible, then I might have to do some workarounds to insure that I get my data in a timely manner.
>>>
>>> The image I have been developing in is currently about 30 seconds ahead of the OS clock. It is on my laptop. It might be due to the laptops sleep and hibernation. I have not tested this on my server.
>>>
>>> That is the situation as best I know it.
>>>
>>> Thanks.
>>>
>>> Jimmie
>>>
>
>

David T. Lewis

Re: Fwd: [Pharo-project] System time

I have not looked at this carefully, but I suspect an issue in Chronology
(as opposed to a VM or primitive issue). DateAndTime initializes some cached
values at image startup time, and thereafter calculates things based on the
millisecond clock. If the millisecond clock drifts with respect to system time
on the underlying platform (as presumably would be the case if the system clock
is synchronized using ntp), then DateAndTime's opinion about current time will
drift with respect to the underlying platform.

Dave

On Sun, May 01, 2011 at 08:24:49AM +0200, stephane ducasse wrote:

>
> Begin forwarded message:
>
> > From: Jimmie Houchin <[hidden email]>
> > Date: May 1, 2011 4:15:40 AM GMT+02:00
> > To: [hidden email]
> > Subject: Re: [Pharo-project] System time
> > Reply-To: [hidden email]
> >
> > Hello,
> >
> > My OS for this application is Windows. On a freshly opened image, the image and OS time are in sync. Over a period of time the image drifted 34 seconds away from OS time. I do not know how long I had this image open, but it has been a number of days, possibly a week plus.
> >
> > I saved the image and quit. I reopened the image and did DateAndTime now and it was in sync with the OS once again. Same image, vm and OS that was out of sync by 34 seconds only one minute before.
> >
> > I have opened an image on my server which is also running the latest cog vm, the current Pharo 1.3 and Windows Vista. I am going to periodically do a DateAndTime now to log the drift if any. Prior to opening this image I updated the OS system clock with time.nist.gov which is about 1000 miles away.
> >
> > I know that within a second or so it can be subject to my coordination of doing DateAndTime now while watching my OS system clocks seconds. But 34 seconds is beyond any subjective standards.
> >
> > The only reason I discovered this was while exploring how I want to retrieve my data, act upon my data and then pause (Delay wait) until time to repeat.
> > dtnow := DateAndTime now.
> > dtnext := DateAndTime year: 2011 month: 4 day: 30 hour: 11 minute: i second: 5. "The next minute in the future"
> > (Delay forDuration: (dtnext - dtnow)) wait.
> >
> > I got an error, that Duration cannot be a negative number. As I processed the debugger, I saw that dtnow was greater than dtnext. I watched the OS clock and manually selected the next minute before I executed. However, I was within that 34 second window.
> >
> > So now I am exploring the problem.
> >
> > Thanks.
> >
> > Jimmie
> >
> > On 4/30/2011 5:06 PM, Alexandre Bergel wrote:
> >> 'Time now' gives me the same result than OSX
> >>
> >> Alexandre
> >>
> >>
> >> On 30 Apr 2011, at 16:15, Jimmie Houchin wrote:
> >>
> >>> On 4/30/2011 11:50 AM, St?phane Ducasse wrote:
> >>>>> I am developing a time sensitive application. I poll a server every minute for new data. The data is time sensitive and the sooner I can get the data to the release of the data the better.
> >>>>>
> >>>>> I have noticed that Pharo's system time drifts away from the OS system time. I would really like the Pharo system time to be the correct time.
> >>>> do you have a repeatable scenario?
> >>>> VM
> >>>> Image information.
> >>> Pharo 1.3 and the latest Cog.
> >>>
> >>>>> I have not been able to find where in Pharo I can call to update the System clock to the correct time.
> >>>> you can use OSProcess (only mac and linux)
> >>> No, that's not the problem. The OS clock is right. It's Pharo that has drifted away from correct time. Regardless it would be nice if I have to correct the OS clock, it would still be nice to resync Pharo with the OS, keep both in sync and correct. What I am wanting is simply to resync the Pharo clock with the OS clock.
> >>>
> >>> It seems that when the Pharo image is started that it gets the OS System time, but keeps its own time after that. Now I do not know the consequences of Pharo adjusting its time backward. If this isn't possible, then I might have to do some workarounds to insure that I get my data in a timely manner.
> >>>
> >>> The image I have been developing in is currently about 30 seconds ahead of the OS clock. It is on my laptop. It might be due to the laptops sleep and hibernation. I have not tested this on my server.
> >>>
> >>> That is the situation as best I know it.
> >>>
> >>> Thanks.
> >>>
> >>> Jimmie
> >>>
> >
> >

Levente Uzonyi-2

Re: Fwd: [Pharo-project] System time

On Mon, 2 May 2011, David T. Lewis wrote:

>
> I have not looked at this carefully, but I suspect an issue in Chronology
> (as opposed to a VM or primitive issue). DateAndTime initializes some cached
> values at image startup time, and thereafter calculates things based on the
> millisecond clock. If the millisecond clock drifts with respect to system time
> on the underlying platform (as presumably would be the case if the system clock
> is synchronized using ntp), then DateAndTime's opinion about current time will
> drift with respect to the underlying platform.

The amount of the drift seems to be 1 millisecond every 14-16 seconds on
my pc. I wrote some code to get the system time via FFI[1], then ran the
following:

| data |
data := (1 to: 100) collect: [ :run |
1 seconds asDelay wait.
{ DateAndTime now. Win32SystemTime localDateAndTime } ].
(data collect: [ :each | each first - each second ] as: Set) sorted explore

Levente

[1] http://leves.web.elte.hu/squeak/Win32SystemTime.st

>
> Dave
>
> On Sun, May 01, 2011 at 08:24:49AM +0200, stephane ducasse wrote:
>>
>> Begin forwarded message:
>>
>>> From: Jimmie Houchin <[hidden email]>
>>> Date: May 1, 2011 4:15:40 AM GMT+02:00
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] System time
>>> Reply-To: [hidden email]
>>>
>>> Hello,
>>>
>>> My OS for this application is Windows. On a freshly opened image, the image and OS time are in sync. Over a period of time the image drifted 34 seconds away from OS time. I do not know how long I had this image open, but it has been a number of days, possibly a week plus.
>>>
>>> I saved the image and quit. I reopened the image and did DateAndTime now and it was in sync with the OS once again. Same image, vm and OS that was out of sync by 34 seconds only one minute before.
>>>
>>> I have opened an image on my server which is also running the latest cog vm, the current Pharo 1.3 and Windows Vista. I am going to periodically do a DateAndTime now to log the drift if any. Prior to opening this image I updated the OS system clock with time.nist.gov which is about 1000 miles away.
>>>
>>> I know that within a second or so it can be subject to my coordination of doing DateAndTime now while watching my OS system clocks seconds. But 34 seconds is beyond any subjective standards.
>>>
>>> The only reason I discovered this was while exploring how I want to retrieve my data, act upon my data and then pause (Delay wait) until time to repeat.
>>> dtnow := DateAndTime now.
>>> dtnext := DateAndTime year: 2011 month: 4 day: 30 hour: 11 minute: i second: 5. "The next minute in the future"
>>> (Delay forDuration: (dtnext - dtnow)) wait.
>>>
>>> I got an error, that Duration cannot be a negative number. As I processed the debugger, I saw that dtnow was greater than dtnext. I watched the OS clock and manually selected the next minute before I executed. However, I was within that 34 second window.
>>>
>>> So now I am exploring the problem.
>>>
>>> Thanks.
>>>
>>> Jimmie
>>>
>>> On 4/30/2011 5:06 PM, Alexandre Bergel wrote:
>>>> 'Time now' gives me the same result than OSX
>>>>
>>>> Alexandre
>>>>
>>>>
>>>> On 30 Apr 2011, at 16:15, Jimmie Houchin wrote:
>>>>
>>>>> On 4/30/2011 11:50 AM, St?phane Ducasse wrote:
>>>>>>> I am developing a time sensitive application. I poll a server every minute for new data. The data is time sensitive and the sooner I can get the data to the release of the data the better.
>>>>>>>
>>>>>>> I have noticed that Pharo's system time drifts away from the OS system time. I would really like the Pharo system time to be the correct time.
>>>>>> do you have a repeatable scenario?
>>>>>> VM
>>>>>> Image information.
>>>>> Pharo 1.3 and the latest Cog.
>>>>>
>>>>>>> I have not been able to find where in Pharo I can call to update the System clock to the correct time.
>>>>>> you can use OSProcess (only mac and linux)
>>>>> No, that's not the problem. The OS clock is right. It's Pharo that has drifted away from correct time. Regardless it would be nice if I have to correct the OS clock, it would still be nice to resync Pharo with the OS, keep both in sync and correct. What I am wanting is simply to resync the Pharo clock with the OS clock.
>>>>>
>>>>> It seems that when the Pharo image is started that it gets the OS System time, but keeps its own time after that. Now I do not know the consequences of Pharo adjusting its time backward. If this isn't possible, then I might have to do some workarounds to insure that I get my data in a timely manner.
>>>>>
>>>>> The image I have been developing in is currently about 30 seconds ahead of the OS clock. It is on my laptop. It might be due to the laptops sleep and hibernation. I have not tested this on my server.
>>>>>
>>>>> That is the situation as best I know it.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Jimmie
>>>>>
>>>
>>>
>

David T. Lewis

Re: Fwd: [Pharo-project] System time

On Tue, May 03, 2011 at 04:02:04AM +0200, Levente Uzonyi wrote:

>
> On Mon, 2 May 2011, David T. Lewis wrote:
> >
> >I have not looked at this carefully, but I suspect an issue in Chronology
> >(as opposed to a VM or primitive issue). DateAndTime initializes some
> >cached
> >values at image startup time, and thereafter calculates things based on the
> >millisecond clock. If the millisecond clock drifts with respect to system
> >time
> >on the underlying platform (as presumably would be the case if the system
> >clock
> >is synchronized using ntp), then DateAndTime's opinion about current time
> >will
> >drift with respect to the underlying platform.
>
> The amount of the drift seems to be 1 millisecond every 14-16 seconds on
> my pc. I wrote some code to get the system time via FFI[1], then ran the
> following:
>
> | data |
> data := (1 to: 100) collect: [ :run |
> 1 seconds asDelay wait.
> { DateAndTime now. Win32SystemTime localDateAndTime } ].
> (data collect: [ :each | each first - each second ] as: Set) sorted explore
>
>
> Levente
>
> [1] http://leves.web.elte.hu/squeak/Win32SystemTime.st

I am now running a similar test (attached) on Linux. I was expecting
to see clock drift exactly the same as that reported on Windows, but
so far after about 15 minutes I see no obvious signs of drift. I
cannot explain this but I'll leave it running for a while and see
if anything interesting happens.

Dave

sample output:

=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:46.01
OS time now: 2011-05-03T20:40:21.039466-04:00
Squeak time now: 2011-05-03T20:40:21.04-04:00
Difference: 0:00:00:00.000534
Drift: 0:00:00:00.000075
=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:49.072
OS time now: 2011-05-03T20:40:24.101675-04:00
Squeak time now: 2011-05-03T20:40:24.102-04:00
Difference: 0:00:00:00.000325
Drift: -0:00:00:00.000134
=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:52.102
OS time now: 2011-05-03T20:40:27.131382-04:00
Squeak time now: 2011-05-03T20:40:27.132-04:00
Difference: 0:00:00:00.000618
Drift: 0:00:00:00.000159
=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:55.136
OS time now: 2011-05-03T20:40:30.165711-04:00
Squeak time now: 2011-05-03T20:40:30.166-04:00
Difference: 0:00:00:00.000289
Drift: -0:00:00:00.00017

CheckTimeDrift.st (2K) Download Attachment

Eliot Miranda-2

Re: Fwd: [Pharo-project] System time

On Tue, May 3, 2011 at 5:44 PM, David T. Lewis <[hidden email]> wrote:

On Tue, May 03, 2011 at 04:02:04AM +0200, Levente Uzonyi wrote:
>
> On Mon, 2 May 2011, David T. Lewis wrote:
> >
> >I have not looked at this carefully, but I suspect an issue in Chronology
> >(as opposed to a VM or primitive issue). DateAndTime initializes some
> >cached
> >values at image startup time, and thereafter calculates things based on the
> >millisecond clock. If the millisecond clock drifts with respect to system
> >time
> >on the underlying platform (as presumably would be the case if the system
> >clock
> >is synchronized using ntp), then DateAndTime's opinion about current time
> >will
> >drift with respect to the underlying platform.
>
> The amount of the drift seems to be 1 millisecond every 14-16 seconds on
> my pc. I wrote some code to get the system time via FFI[1], then ran the
> following:
>
> | data |
> data := (1 to: 100) collect: [ :run |
> 1 seconds asDelay wait.
> { DateAndTime now. Win32SystemTime localDateAndTime } ].
> (data collect: [ :each | each first - each second ] as: Set) sorted explore
>
>
> Levente
>
> [1] http://leves.web.elte.hu/squeak/Win32SystemTime.st

I am now running a similar test (attached) on Linux. I was expecting
to see clock drift exactly the same as that reported on Windows, but
so far after about 15 minutes I see no obvious signs of drift. I
cannot explain this but I'll leave it running for a while and see
if anything interesting happens.

Its because on linux & mac the clock is derived from gettimeofday which is wall time but on Windows it is derived from timeGetTime which isn't. The problem is the lack of a high-resolution wall time on Windows. GetSystemTimeAsFileTime et al have something like 16 ms resolution whereas timeGetTime has 1ms resolution.

Dave

sample output:

=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:46.01
OS time now: 2011-05-03T20:40:<a href="tel:21.039466-04" value="+12103946604">21.039466-04:00
Squeak time now: 2011-05-03T20:40:21.04-04:00
Difference: 0:00:00:00.000534
Drift: 0:00:00:00.000075
=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:49.072
OS time now: 2011-05-03T20:40:24.101675-04:00
Squeak time now: 2011-05-03T20:40:24.102-04:00
Difference: 0:00:00:00.000325
Drift: -0:00:00:00.000134
=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:52.102
OS time now: 2011-05-03T20:40:27.131382-04:00
Squeak time now: 2011-05-03T20:40:27.132-04:00
Difference: 0:00:00:00.000618
Drift: 0:00:00:00.000159
=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:00:15:55.136
OS time now: 2011-05-03T20:40:<a href="tel:30.165711-04" value="+13016571104">30.165711-04:00
Squeak time now: 2011-05-03T20:40:30.166-04:00
Difference: 0:00:00:00.000289
Drift: -0:00:00:00.00017

Levente Uzonyi-2

Re: Fwd: [Pharo-project] System time

On Tue, 3 May 2011, Eliot Miranda wrote:

> Its because on linux & mac the clock is derived from gettimeofday which is
> wall time but on Windows it is derived from timeGetTime which isn't. The
> problem is the lack of a high-resolution wall time on Windows.
> GetSystemTimeAsFileTime et al have something like 16 ms resolution whereas
> timeGetTime has 1ms resolution.

On vista the accuracy of GetLocalTime (which is a "friend" of
GetSystemTimeAsFileTime) seems to be 1ms. E.g.:

s := Set new.
[ s size < 10 ] whileTrue: [ s add: Win32SystemTime localDateAndTime ].
s sorted

Output:
{2011-05-04T04:03:40.049+02:00 . 2011-05-04T04:03:40.05+02:00 .
2011-05-04T04:03:40.051+02:00 . 2011-05-04T04:03:40.052+02:00 .
2011-05-04T04:03:40.053+02:00 . 2011-05-04T04:03:40.054+02:00 .
2011-05-04T04:03:40.055+02:00 . 2011-05-04T04:03:40.056+02:00 .
2011-05-04T04:03:40.057+02:00 . 2011-05-04T04:03:40.058+02:00}

Levente

Eliot Miranda-2

Re: Fwd: [Pharo-project] System time

On Tue, May 3, 2011 at 7:10 PM, Levente Uzonyi <[hidden email]> wrote:

On Tue, 3 May 2011, Eliot Miranda wrote:

Its because on linux & mac the clock is derived from gettimeofday which is
wall time but on Windows it is derived from timeGetTime which isn't. The problem is the lack of a high-resolution wall time on Windows. GetSystemTimeAsFileTime et al have something like 16 ms resolution whereas timeGetTime has 1ms resolution.

On vista the accuracy of GetLocalTime (which is a "friend" of
GetSystemTimeAsFileTime) seems to be 1ms.

Good. Time to change. I'll test this on XP soon.

E.g.:

s := Set new.
[ s size < 10 ] whileTrue: [ s add: Win32SystemTime localDateAndTime ].
s sorted

Output:
{2011-05-04T04:03:40.049+02:00 . 2011-05-04T04:03:40.05+02:00 . 2011-05-04T04:03:40.051+02:00 . 2011-05-04T04:03:40.052+02:00 . 2011-05-04T04:03:40.053+02:00 . 2011-05-04T04:03:40.054+02:00 . 2011-05-04T04:03:40.055+02:00 . 2011-05-04T04:03:40.056+02:00 . 2011-05-04T04:03:40.057+02:00 . 2011-05-04T04:03:40.058+02:00}

Levente

Levente Uzonyi-2

Re: Fwd: [Pharo-project] System time

On Tue, 3 May 2011, Eliot Miranda wrote:

> Good. Time to change. I'll test this on XP soon.

It's 10 ms on XP:

{2011-05-04T12:09:59.394+02:00 . 2011-05-04T12:09:59.404+02:00 .
2011-05-04T12:09:59.414+02:00 . 2011-05-04T12:09:59.424+02:00 .
2011-05-04T12:09:59.434+02:00 . 2011-05-04T12:09:59.444+02:00 .
2011-05-04T12:09:59.454+02:00 . 2011-05-04T12:09:59.464+02:00 .
2011-05-04T12:09:59.474+02:00 . 2011-05-04T12:09:59.484+02:00}

Levente

David T. Lewis

Re: Fwd: [Pharo-project] System time

On Wed, May 04, 2011 at 12:11:46PM +0200, Levente Uzonyi wrote:

>
> On Tue, 3 May 2011, Eliot Miranda wrote:
>
> >Good. ?Time to change. ?I'll test this on XP soon.
>
> It's 10 ms on XP:
>
> {2011-05-04T12:09:59.394+02:00 . 2011-05-04T12:09:59.404+02:00 .
> 2011-05-04T12:09:59.414+02:00 . 2011-05-04T12:09:59.424+02:00 .
> 2011-05-04T12:09:59.434+02:00 . 2011-05-04T12:09:59.444+02:00 .
> 2011-05-04T12:09:59.454+02:00 . 2011-05-04T12:09:59.464+02:00 .
> 2011-05-04T12:09:59.474+02:00 . 2011-05-04T12:09:59.484+02:00}
>
> Levente

And to confirm the earlier conclusion, there is no clock drift
on Linux after running the test for 10 hours.

Dave

=== Started at 2011-05-03T20:24:35.03-04:00 ===
Test duration 0:10:50:20.549
OS time now: 2011-05-04T07:14:55.578716-04:00
Squeak time now: 2011-05-04T07:14:55.579-04:00
Difference: 0:00:00:00.000284
Drift: -0:00:00:00.000175