System class>>timeNs

[Jesse Cooke]

I'm working on getting nanosecond resolution in the Time class for hitimes[1] and it looks like the only way I can get that precision out of GemStone/S is by exposing System class>>timeNs. However, the description I found in GemTools is a bit puzzling:

timeNs

"Returns a SmallInteger representing the current high-resolution
 real time in nanoseconds since some arbitrary time in the past.  The 
 result is not correlated in any way with the time of day."
 
^ self _zeroArgPrim: 95

So I guess this is directed at Allen, Tim, or any other VM developer that might be on the list, but is that comment right? When I print `System timeNs.` it looks to me to be the number of nanoseconds since the epoch.

If exposing `timeNs` ends up being the right way to go, I think I'll end up making a new class instead of trying to get it into `RubyTime` since we only have microsecond resolution in `RubyTime` (and I'd guess the Time class in Smalltalk too.)

Jesse

[1] https://github.com/copiousfreetime/hitimes/issues/16

[Norm Green]

Jesse,

The implementation of fetching the ns timestamp is platform-dependent.  On Linux, we call:

clock_gettime(CLOCK_REALTIME, &tp);

which I think is ns since the epoch as you said.  However on other platforms (Solaris, for example) we call gethrtime() which has no relation to the epoch.  From the solaris man page:

     The gethrtime() function returns the current high-resolution
     real time. Time is expressed as nanoseconds since some arbi-
     trary time in the past; it is not correlated in any  way  to
     the  time  of  day,  and thus is not subject to resetting or
     drifting by way of adjtime(2) or settimeofday(3C).

On Darwin, we call gettimeofday(), which only has microsecond resolution.

Hope this helps.

Norm

--
You received this message because you are subscribed to the Google Groups "MagLev Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maglev-discuss...@googlegroups.com.
To post to this group, send email to maglev-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/maglev-discussion.
For more options, visit https://groups.google.com/d/optout.

[Richard Sargent]

On Apr 21, 2014 11:01 AM, "Jesse Cooke" <je...@jc00ke.com> wrote:

> If exposing `timeNs` ends up being the right way to go, I think I'll end up making a new class instead of trying to get it into `RubyTime` since we only have microsecond resolution in `RubyTime` (and I'd guess the Time class in Smalltalk too.)

In my opinion, a new class is they way to go. Since the value of #timeNs is not intended to correspond to a time per se, it seems inappropriate to add it to a time-like class.

There may be a utility class in ruby like System in GemStone which could tolerate the addition of another wart.

[Tim Felgentreff]

Maglev::System could do?

---

From: Richard Sargent
Sent: ‎21/‎04/‎2014 20:21
To: maglev-d...@googlegroups.com
Subject: Re: [maglev-discussion] System class>>timeNs

[Jesse Cooke]

Thanks Norm, that helps.

My feedback is that I don't think Rubyists use Solaris much, so I wouldn't be too concerned with changes there. OSX, however... that's necessary :)

Is there a reason the VM uses gettimeofday() and not something with higher resolution, like clock_get_time()[1] or mach_absolute_time()?

Would there be any reservation in changing the VM if that sounded reasonable?

There's a chance Jeremy can get the C-ext to compile too. I haven't tried, and I'm not sure if he had either. Personally I'd like to see `timeNs` have the nanosecond precision like the name suggests.

Thanks!
Jesse

[1] https://gist.github.com/jbenet/1087739

[Jesse Cooke]

Yeah, that'd be the easiest spot to put it. Makes sense.

[Jesse Cooke]

On Apr 21, 2014 11:51 PM, "Jesse Cooke" <je...@jc00ke.com> wrote:
>
> Thanks Norm, that helps.
>
> My feedback is that I don't think Rubyists use Solaris much, so I wouldn't be too concerned with changes there. OSX, however... that's necessary :)

After a little googling it looks like clock_gettime() is available on Solaris. I'm curious, is there a historical reason for using gethrtime ()?

[Norm Green]

Yes, we can look into that.  I've filed bug 44142 on the issue. 

One concern is that clock_get_time() is not monotonic if someone calls clock_set_time().  However the chances of that happening might be low.  And I agree it would be good to have true nanosecond resolution instead of the microsecond resolution provided by gettimeofday().

Norm