On Thu, Feb 18, 2016 at 12:49 PM, Bert Freudenberg <bert at freudenbergs.de>
wrote:

>
> On 18.02.2016, at 12:33, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Marcel,
>
> On Thu, Feb 18, 2016 at 12:07 AM, marcel.taeumel <Marcel.Taeumel at hpi.de>
> wrote:
>
>> Hi, there!
>>
>> The VM seems to "cache" the wall clock. This is weird.
>>
>> Here is the story: I just booted into Windows and my time was wrong. Seems
>> to be come Surface bug. It still was at the sleep time yesterday
>> evenening,
>> 11pm.
>>
>> Squeak was already open, reporting the same.
>>
>> Then, I updated the system time by letting Windows sync with Microsofts
>> time
>> server.
>>
>> And then, the still running Squeak VM reported still the old values!!! :-/
>> How can that happen?
>>
>
> By my having coded time management in the Windows VM wrong?  Look at
> sqWin32Heartbeat.c.
> This all needs rewriting anyway given the discussion on monotonic vs wall
> time.   I'd like to have one copy of the code that computes the VM's notion
> of time, perhaps written in Smalltalk, and place that above
> platform-specific code that answers the monotonic and wall clocks.
>
> But what should the VM do if it is faced with a huge jump in the time?
> Let's say that for testing you set the clock on your machine to 1970, then
> you started Smalltalk, and then you enabled syncing with the time server
> and the clock jumped forward to 2016.  One could have the VM try to
> compensate but I think the best thing is to say "don't do that" and require
> teh user to restart their image.  It's reasonable for the VM to maintain a
> clock that undergoes ntpd-like adjustments.  It's complicated to have the
> VM try and distinguish small ntpd-like adjustments form huge adjustments in
> the clock.  And keeping it simple seems like the best solution.
>
>
> Why can’t we simply decouple the low-precision wall-clock from the
> high-precision monotonic clock used for timing? Marcel’s use case isn’t
> that unusual. I put my machine to sleep with images open all the time. That
> should work without having to restart the image.
>

I think we must be talking about two different things.  The utc coming into
the VM either changes by small ammounts (via ntp) or by huge ammounts
(programmer intervention).  The VM can easily maintain a clock that copes
with small changes to the value of utc by allowing its time, derived from
the machine's monotonic time, to drift towards utc at no more than a given
percentage of monotonic time.  If this algorithm is used (it has the nice
properties that we only need one clock for all services and that clock is
acceptably accurate for measuring durations) it can't ever catch up with
huge differences in teh value of utc, as would be caused by e.g. setting
the system clock to 1970/1/1, starting Smalltalk and setting the time to
2016/2/18.

But that's a completely different notion to saving the image and restarting
it aeons later. utc will have changed bu a huge ammount but the VM will
start from the value of utc when it starts up, and has nothing to do with
the time when the image was saved.

So I don't undersand hat you're getting at.

But for me I very much want to have *one clock* in tghe VM.  That's an
advantage of using a utc microsecond clock.  All other clocks of lesser
resolution can be derived from it.  If you look at the situation before
with a separate second clock and millisecond clock you saw absurdities like
the image spin looping for up to a second (half a second on average) just
to find out what the value of the millisecond clock is when the second
clock ticks.  Tis is absurd both because a) it wastes up to half a second
on startup, a disaster in e.g. a container farm scenario and b) because it
assumes that the second clock and millisecond clock are synchronised, which
they aren't, so in a day or so the two will have drifted so much that
timestamps will be inaccurate.


> - Bert -
>
>
>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160218/b9ebaf29/attachment.htm