On Thu, Mar 24, 2016 at 7:12 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> Hi Levente,
>
> On Wed, Mar 23, 2016 at 05:01:35PM +0100, Levente Uzonyi wrote:
>>
>> On Sun, 20 Mar 2016, David T. Lewis wrote:
>> >
>> >The four policies are:
>> >
>> >#acceptPlatformTime - Accept the time value provided by the system
>> >platform, even in this allows time to appear to move backwards when the
>> >clock is adjusted. Simple, fast, and no hidden side effects.
>> >
>> >#monotonicAllowDuplicates - Accept the time value provided by the system
>> >platform unless it is less that the last clock tick. This protects for
>> >system clock adjustments. Side effects unlikely. Does not ensure unique
>> >values on repeated calls.
>> >
>> >#monotonicForceMicrosecondIncrement - If the time value is less than or
>> >equal to the value from the last call, force increment by one microsecond.
>> >This ensures integral values of UTC time, but increments the time value by
>> >a full microsecond.
>> >
>> >#monotonicForceNanosecondIncrement - If the time value is less than or
>> >equal to the value from the last call, force increment by one nanosecond.
>> >This it functionally compatible with previous Squeak practice, but is
>> >computationally expensive and results in time values represented as
>> >fractions, which might be a problem for some database applications.
>>
>> I think this covers most possible use cases. What I was originally
>> thinking about was the addition of another field to hold the nanosecond
>> part, since that would have only been set by the image itself, so the
>> primitive could still have been used to initialize the rest. That we we
>> could have avoided the use of fractions at the cost of having another
>> field per object even when there's no need for high accuracy.
>
> I'm actually quite happy with the idea of the value being a Number that
> is an Integer for all reasonable values that could ever be supplied by
> the VM, but that might be a Fraction if we want to represent time values
> at some higher precision. Mainly I like it because it seems good conceptually
> to think of time as continuous, and not as discreet ticks of a clock.
>
> It also works well computationally, because the normal case uses integer
> values (immediates in 64-bit Spur), and because Fractions involve two
> integer values, which presumably would be no worse than a design that
> added another field. But given that none of our computers or VMs can
> report time to a precision greater than microseconds, I think that we
> can safely ignore the issue for another 20 years or so ;-)

Its not so far away. Three contemporary examples...

* Systems that synchronise time from GPS do so "typically well within
40 nanoseconds" [1]

* The distributed clock of EtherCAT networks synchronises nodes to
better than 100ns. See slide 23 [2] and figure 7 [3].

* IEEE 1588 provides synchronised network time "in the range of
+/-200ns between some nodes and even +/-50ns and less between the
better ones." [4]

This matters for applications like financial trading, motion control
and sequence-of-event logging on industrial plants.  Maybe not
Smalltalk's bread and butter, but the last two are areas I'd like to
use it at a co-ordinator level.

cheers -ben

[1] http://gpsinformation.net/main/gpstime.htm
[2] https://ece.uwaterloo.ca/~sfischme/rate/Joey-Stubbs-Ethercat.pdf
[3] http://www.iestcfa.org/bestpaper/wfcs10/wfcs10_bpa.pdf
[4] https://home.zhaw.ch/~wei/IEEE1588/embedded_World_05_Contribution_final.pdf