[Vm-dev] Re: Use of UTC and offset for system clock

Tue Aug 24 17:41:42 UTC 2010

On Tue, Aug 24, 2010 at 10:18 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
> On 8/24/2010 9:43 AM, Eliot Miranda wrote:
>
>> With these four one has a non-wrapping synchronised timebase with
>> potentially microsecond resolution that marries well with Squeak's
>> 64-bit integer support.  This approach worked very well for VisualWorks
>> where we got rid of lots of customer problems every 49.7 days (2^32
>> milliseconds).  There has been some concern expressed about the
>> performance impact of long integers but at least in VW that simply
>> wasn't an issue.
>>
>
> For general purpose apps, sure. Remember that my concern is what the effect
> of switching to largeint arithmetic is on our routers which time-stamp in
> and outgoing packets at several points so that we can keep track of
> latencies and where they're introduced. I will absolutely believe that in
> "average" use there's not going to be an impact, but I don't think that what
> we're doing (timestamping millions of times per second) can be exactly
> considered average here :-) You'll recall that the introduction of the jiffy
> clock was in response to the server spending some 20% or so in
> gettimeofday...
>

Hmmm.  Then, given that the clock's effective resolution is around
500Hz-1KHz, and that the 64-bit result is effectively immutable, there could
be significant benefit in the primitive cacheing the current result,
instantiating a new result object only when the time actually changes.

best
Eliot

>
> Cheers,
>  - Andreas
>
>
>> best
>> Eliot
>>
>>
>>    Thanks,
>>    Dave
>>
>>
>>    On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote:
>>     >
>>     > On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis
>>    <lewis at mail.msen.com <mailto:lewis at mail.msen.com>> wrote:
>>     >
>>     > >
>>     > > Eliot,
>>     > >
>>     > > Yes, it can be retracted. I may not get to it for a few days so
>>    feel
>>     > > free to do so on my behalf. I introduced the change in trunk to
>> put
>>     > > some visibility on the new primitives, which appears to have
>>    achieved
>>     > > the intended purpose ;)
>>     > >
>>     > > With respect to the Squeak epoch, we do have an issue that needs
>> to
>>     > > be clarified. In the Squeak implementation, we have the 1901
>> epoch,
>>     > > but AFAIK there is no specification of the time zone in which
>>    the epoch
>>     > > is defined. In the Squeak implementation, local time has
>>    consistently
>>     > > been used in the platform interface, and the actual values of the
>>     > > Squeak clock for any real point in time are different depending on
>>     > > the time zone in which the image happens to be running.
>>     > >
>>     >
>>     > It's implicit that it is GMT/UTC.  So the Squeak epoch is the
>>    start of 1901
>>     > in Greenwich.
>>     >
>>     > To put it another way, there is no such thing as "UTC & local
>>     > > microseconds from the Smalltalk epoch" unless there is a clearly
>>     > > defined transformation between the Smalltalk epoch and the posix
>>     > > epoch, and in practice (in Squeak at least) this is not the case.
>>     > > Midnight on January 1, 1901 in Palo Alto, California was a
>>    different
>>     > > point in time from midnight January 1, 1901 in London, and I
>> cannot
>>     > > determine which of the two was the "real" Smalltalk epoch.
>>     > >
>>     >
>>     > The latter is the only one that makes good sense.
>>     >
>>     >
>>     > > This begs the question of why, in implementing the interface to
>>     > > the underlying platform, we would *not* want use the posix epoch
>>     > > as a reference point. The Posix epoch is well defined, well
>>    documented,
>>     > > well understood, and easily translated to any existing
>>    definition of
>>     > > the Smalltalk epoch. In contrast, the Smalltalk epoch is
>>    ambiguously
>>     > > defined, poorly documented, and widely misunderstood.
>>     > >
>>     >
>>     > I think its easy to fix; just define it to be the start of the
>>    20th century
>>     > in UTC.  That's what we did with VW and its easy to do with
>>    Squeak.  For me
>>     > backwards compatibility pushes strongly for keeping with the
>>    Squeak epoch,
>>     > i.e. Time seconds = Time milliseconds / 1000000.
>>     >
>>     > best,
>>     > Eliot
>>     >
>>     >
>>     > >
>>     > > Dave
>>     > >
>>     > > On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote:
>>     > > >
>>     > > > Hi David,
>>     > > >
>>     > > >     any chance of getting you to retract this?  The Cog VM
>>    has 64-bit UTC
>>     > > &
>>     > > > local microseconds from the Smalltalk epoch (1901), which are
>>    hence
>>     > > easier
>>     > > > to use as a basis for the Squeak clock and still last for ~
>>    54,000 years.
>>     > > >  I'd like to see the Cog and standard VMs converge on a
>>    primitive set.
>>     > >  This
>>     > > > is an issue for me since changing the epoch is, I think, an
>>    unnecessary
>>     > > > change.
>>     > > >
>>     > > > best
>>     > > > Eliot
>>     > > >
>>     > > > On Sat, Aug 14, 2010 at 4:55 PM, <commits at source.squeak.org
>>    <mailto:commits at source.squeak.org>> wrote:
>>     > > >
>>     > > > > Changes to Trunk (http://source.squeak.org/trunk.html) in
>>    the last 24
>>     > > > > hours:
>>     > > > >
>>     > > > >
>>     > > > >
>>     > >
>>
>> http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html
>>     > > > >
>>     > > > > Name: Kernel-dtl.476
>>     > > > > Ancestors: Kernel-eem.475
>>     > > > >
>>     > > > > Add Time class>>primMicrosecondClock and Time
>>    class>>primUtcWithOffset
>>     > > for
>>     > > > > access to microsecond clock primitives available in newer
>>    Squeak VMs.
>>     > > > >
>>     > > > > primMicrosecondClock provides a system clock with nominal
>>    microsecond
>>     > > > > precision.
>>     > > > >
>>     > > > > primUtcWithOffset answers UTC time as microseconds since
>>    the Posix
>>     > > epoch
>>     > > > > and offset as seconds offset from GMT. The Squeak clock is
>>     > > traditionally
>>     > > > > implemented in terms of platform local time. Use of UTC
>>    time and offset
>>     > > is
>>     > > > > advantageous if time zones and daylight saving time offsets
>>    are to be
>>     > > > > considered.
>>     > > > >
>>     > > > > Example:
>>     > > > > { Time primMillisecondClock .
>>     > > > >   Time primMicrosecondClock .
>>     > > > >   Time primUtcWithOffset } ==> #(6932757 6932757830
>>    #(1281815075538304
>>     > > > > -14400))
>>     > > > >
>>     > > > >
>>     > > > > =============================================
>>     > > > >
>>     > > > >
>>     > >
>>     > >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100824/3bd17f8a/attachment.htm