Re: [MirageOS-devel] Mirage clock

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 3 Aug 2015, at 18:32, Nick Betteridge <buzzheavyyear@xxxxxxxxxxx> wrote:
> 
> 
> > >
> > > I have a use case where I need the clock resolution to be in milliseconds.
> > > Is there anyway I can get hold of the time in milli (/micro/nano) seconds
> > > from the system clock without incurring too much of a performance penalty?
> > 
> > I think Clock.time is probably as fast as it's going to get for the
> > system clock, since it just calls the platform's gettimeofday
> > function.
> > 
> > If you only want to measure an interval and you're on Xen,
> > OS.Time.Monotonic.time() might be slightly quicker, but I doubt
> > there's much in it.
> > 
> 
> Ok, after reading through mirage-bindings/platform/clock_stubs.c I can see 
> that the CLOCK.time is both the seconds and microseconds bundled together as 
> a float:
> 
> CAMLreturn(caml_copy_double((double) tp.tv_sec + (double) tp.tv_usec / 1e6));
> 
> Having tv_sec and tv_usec exposed as integers would be very useful in 
> mirageos - I'm working with integers in the time domain, and having to 
> convert an original integer to a float and then back to an integer seems a 
> little crazy.
> 
> Any chance of embellishing CLOCK with tv_sec and tv_usec? :)

Yeah, the time representation is definitely not optimal in the current CLOCK 
interface.

See: 
  
http://lists.xenproject.org/archives/html/mirageos-devel/2015-07/msg00036.html 
for the thread about Daniel's ptime library:
  http://erratique.ch/software/ptime

The intention is to use this library as the base for timestamp representation 
and adapt CLOCK to use that instead.  For now, putting in a float<->integer 
shim would get you past this, but it shouldn't be needed after the conversion 
to Ptime...

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