[Vm-dev] Re: [Pharo-dev] strange time / delay problems on pharo-contribution-linux64-4.ci.inria.fr

[Eliot Miranda]

On Tue, Mar 4, 2014 at 2:37 PM, Sven Van Caekenberghe <sven at stfx.eu> wrote:

>
> On 04 Mar 2014, at 22:34, Max Leske <maxleske at gmail.com> wrote:
>
> > Phew! I already thought I was crazy :)
> >
> > In that case here are two more tidbits:
> > - I tried to log 'DateAndTime now' in a different test simultaneously.
> The timestamp produced there was different, suggesting that the clock does
> move from time to time.
> > - FileSystemTests>>testEntryAt exhibits that problem. But the tests run
> on the main Pharo machines are fine (that's why I thought it might be the
> system clock).
> > - the same test only fails in the Pharo3 image, not in Pharo2, but both
> use the stable PharoVM for building.
>
> There is a big difference in how DateAndTime class>>#now works in 2.0 vs
> 3.0. The former uses #millisecondClockValue while the latter uses
> #microsecondClockValue. Furthermore 2.0 does all kind of crazy stuff with a
> loop and Delays to try to improve the accuracy, we threw all that out.
>
> Yeah, I guess the clock is just being updated slowly, maybe under heavy
> load. The question is where that happens. I think in the virtualised OS.
>

That makes sense.  In the VM the microsecond clock is updated on every
heartbeat and the heartbeat should be running at about 500Hz.  Can anyone
with hardware confirm that in 3.0 the time on linux does indeed increase at
about 500Hz?

Note that even in 2.0 the time is being derived from the same basis.  In
Cog, the effective time basis is the 64-bit microsecond clock maintained by
the heartbeat and even the secondClock and millisecondClock are derived
from this.  So its still confusing why there should be such a difference
between 2.0 and 3.0.


>
> > Hope that helps.
> >
> > On 04.03.2014, at 22:10, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> >
> >> Hey Max,
> >>
> >> Great catch, I saw some weird stuff too, and we had this conversation :
> >>
> >>> may be just =
> >>> and time does not pass fast enough/
> >>>
> >>>> On 03 Mar 2014, at 22:22, no-reply at ci.inria.fr wrote:
> >>>>
> >>>>>
> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/962/
> >>>>>
> >>>>> 1 regressions found.
> >>>>> KernelTests.Chronology.DateAndTimeTest.testMonotonicity
> >>>>
> >>>> How the hell can this fail ?
> >>>> The clock moving backwards ??
> >>>>
> >>>> testMonotonicity
> >>>>
> >>>>    | t1 t2 t3 t4 |
> >>>>    t1 := DateAndTime now.
> >>>>    t2 := DateAndTime now.
> >>>>    (Delay forMilliseconds: 1000) wait.
> >>>>    t3 := DateAndTime now.
> >>>>    t4 := DateAndTime now.
> >>>>
> >>>>    self
> >>>>            assert: (t1 <= t2);
> >>>>            assert: (t2 < t3);
> >>>>            assert: (t3 <= t4).
> >>
> >>
> >> So you proofed Stef's assumption of time standing still ;-)
> >>
> >> But there were earlier problems as well.
> >>
> >> Thx !
> >>
> >> On 04 Mar 2014, at 21:43, Max Leske <maxleske at gmail.com> wrote:
> >>
> >>> There seems to be a problem on
> pharo-contribution-linux64-4.ci.inria.fr AFAICT. I can reproduce the
> following to phenomena:
> >>>
> >>> 1. '(Delay forSeconds: 10) wait' does not wait.
> >>> 2. 'DateAndTime now' does not change for long intervals.
> >>>
> >>> For instance, the following code:
> >>>
> >>> (FileSystem disk workingDirectory / 'foo.log') writeStreamDo: [
> :stream |
> >>>     stream nextPutAll: DateAndTime now asString;crlf.
> >>>     stream nextPutAll: ([(Delay forSeconds: 10) wait] timeToRun /
> 1000) asString; crlf.
> >>>     stream nextPutAll: DateAndTime now asString ].
> >>>
> >>> produces this output:
> >>>
> >>> 2014-03-04T21:32:21.396669+01:00
> >>> 0:00:00:00
> >>> 2014-03-04T21:32:21.396669+01:00
> >>>
> >>> Too me (and my untrained eye) this looks like a system clock problem.
> Could somebode take a look at the server in question?
> >>>
> >>> Cheers,
> >>> Max
> >>
> >>
> >
> >
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140304/5e123144/attachment.htm