trunk thinks its tomorrow

On 18.02.2016, at 12:33, Eliot Miranda <[hidden email]> wrote:

Hi Marcel,

On Thu, Feb 18, 2016 at 12:07 AM, marcel.taeumel <[hidden email]> 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.

On Thu, Feb 18, 2016 at 12:49 PM, Bert Freudenberg <[hidden email]> wrote:

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.