[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Timestamp representation and CLOCK

(General agreement to the various proposals :)

On 9 July 2015 at 15:04, David Sheets <sheets@xxxxxxxxxxxx> wrote:
> 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?

One "standard" (used by a class of network monitoring hardware,
supported by wireshark etc, with some accessor functions implemented
-- albeit probably quite poorly and with terrible taste -- in my
branch of pcap-format,
https://github.com/mor1/ocaml-pcap/blob/master/lib/erf.ml) is the ERF
timestamp. Single int64 representation, accurate to 233 ps.


"The time of arrival of the cell, a ERF 64-bit timestamp. Single
little-endian 64-bit fixed point number. The high 32-bits contain the
integer number of seconds since the start of time (unix epoch time).
The lower 32-bits contain the binary fraction of the second allowing
an ultimate resolution of approximately 233 picoseconds."

Not clear this is really what we'd want but something along those
lines (fixed point, binary fractions) might work out sensibly if the
accessors can be efficient.

What range and precision do we want?

(I don't have any real intuition about space or time costs in OCaml at
this level unfortunately, so hard for me to say.)

Richard Mortier

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.