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

Re: [MirageOS-devel] Mirage clock

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 

for the thread about Daniel's ptime library:

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...

MirageOS-devel mailing list



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