Re: [MirageOS-devel] Timestamp representation and CLOCK

[David Sheets <sheets@xxxxxxxxxxxx>]

On Thu, Jul 9, 2015 at 3:04 PM, David Sheets <sheets@xxxxxxxxxxxx> wrote:
> On Thu, Jul 9, 2015 at 2:47 PM, Daniel BÃnzli
> <daniel.buenzli@xxxxxxxxxxxx> wrote:
>> Hello,
>>
>> While working on ptime David Sheets suggested me that moving away from 
>> OCaml's usual representation for POSIX timestamps, namely an OCaml float 
>> representing seconds from the epoch, might be a good idea as it is nowadays 
>> possible to get nanosecond precision timestamps and those cannot be 
>> represented exactly in this representation (he also mentioned hardware not 
>> having FP support as an argument).
>>
>> I'm now quite convinced that this should be done and would like to support 
>> this both at the API level and internally in ptime (which currently only has 
>> millisecond precision). I propose that the canonical representation should 
>> be the following one which is basically what a POSIX timespec definition [1] 
>> gives us and is OCaml 32-bit clean:
>>
>>   type posix_t = int64 * int
>>
>> Understood as a signed, second precision, time span paired with a 
>> non-negative number of nano seconds ranging from 0 to 999'999'999. Formally 
>> a tuple `(s, ns)` represents the time that happens at `s + 1e-9 * ns` from 
>> the epoch.
>>
>> It also seems that there is consensus that the current CLOCK interface [2] 
>> is absurd, forcing any clock source implementer to come up with calendar 
>> field decomposition functions (gmtime). I think that the following interface 
>> would be sufficient:
>>
>> module type CLOCK = sig
>>
>>   val now_s : unit -> int64 * int
>>   (** [now_s ()] is [(s, ns)] the operating system's POSIX timestamp
>>       for the current time understood as the number of seconds [s] +
>>       1e-9 * [ns] from the epoch 1970-01-01 00:00:00 UTC. [ns] ranges
>>       from [0] to [999_999_999]. *)
>>
>>   val current_tz_offset_s : unit -> int
>>   (** [current_tz_offset_s ()] is the operating system's current local
>>       time zone offset to UTC in seconds. *)
>> end
>>
>>
>> Would people agree on such an API and change for the next major release of 
>> mirage ? If so, I'd be willing to actually delve into the various repos to 
>> make that happen.
>
> Off the top of my head I notice two things:
>
> 1. The int64 and tuple representations make a timestamp use 2*word +
> 12 bytes if I count correctly. That is 20 bytes on a 32-bit machine
> and 28 bytes on a 64-bit machine to represent 12 bytes of data. :-( If
> we represent a timestamp as int * int * int, we only use word + 12
> bytes, again hoping I can count. This would save some space but would
> make implementations significantly more complex. Maybe there is an
> even better representation?

Daniel points out that my counting was indeed wrong:
1. the int is a word, not 4 bytes
2. the int64 is a block and so also has a word header

This gives 1 word for tuple, 1 word for int64 pointer, 1 word for
int64 header, 1 word for int, 8 bytes for int64 data = 4*word + 8
bytes = 24 bytes on 32-bit = 40 bytes on 64-bit

:-( :-(

> 2. What about a function on every CLOCK which tells you what precision
> it can guarantee? It seems like it would be a potentially useful value
> that only the CLOCK implementer knows.
>
> David
>
>> Best,
>>
>> Daniel
>>
>> [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html
>> [2] 
>> https://github.com/mirage/mirage/blob/04f3ed8d983f73d59ca1dd560fc9c03f99faf331/types/V1.mli#L79-L105
>>
>>
>>
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel