On Thu, Mar 24, 2016 at 7:12 AM, David T. Lewis lewis@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