[9fans] nsec limits?

[9fans] nsec limits?

[EBo]

 I am setting up some timing tests and am currently dumping the
 timestamps using nsec().  When I post-process the data I find that the
 it is wrapping around, but I have not found anything that clearly states
 when it does that.  From the code I am guessing that is on the second
 boundary.  Is that correct?

   EBo --

Re: [9fans] nsec limits?

[erik quanstrom]

On Mon Aug  1 08:19:23 EDT 2011, ebo@sandien.com wrote:
>  I am setting up some timing tests and am currently dumping the
>  timestamps using nsec().  When I post-process the data I find that the
>  it is wrapping around, but I have not found anything that clearly states
>  when it does that.  From the code I am guessing that is on the second
>  boundary.  Is that correct?

if nsec(2) is wrapping around then time(2) will also wrap around.
i have not seen nsec do anything like that.  it sounds to me like
you may be having integer truncation problems.  are you using a
(u)vlong variable to store the results of nsec?

- erik

---

; cat > nsec.c
#include <u.h>
#include <libc.h>

void
main(void)
{
	print("%llud\n", nsec());
	sleep(10000);
	print("%llud\n", nsec());
}
<eot>; tmk nsec.c
8c -FVTw nsec.c
8l -o 8.nsec nsec.8
; 8.nsec
1312201920700241540
1312201930703219588
; hoc
(1312201930703219588 - 1312201920700241540)/1e9
10.002978048

Re: [9fans] nsec limits?

[EBo]

 On Mon, 1 Aug 2011 08:36:22 -0400, erik quanstrom wrote:
>
> if nsec(2) is wrapping around then time(2) will also wrap around.
> i have not seen nsec do anything like that.  it sounds to me like
> you may be having integer truncation problems.  are you using a
> (u)vlong variable to store the results of nsec?

 Thanks, I had all the variables defined as vlongs, but read it back in
 later as a long... oops.

 Thanks again,

   EBo --

Re: [9fans] nsec limits?

[ron minnich]

What kind of timing tests? What kind of accuracy are you looking for?
What platform?

ron

Re: [9fans] nsec limits?

[EBo]

 On Mon, 1 Aug 2011 08:57:13 -0700, ron minnich wrote:
> What kind of timing tests? What kind of accuracy are you looking for?
> What platform?

 It is for the HARE project (Plan 9 on the BG/P).  I am basically
 running direct comparisons against Brazil, which also used nsec.  I need
 to calc the time used in each of several steps in starting, stopping,
 and running tasks as well as the time it takes to distribute input data
 and accumulate the results.  From the published results I'm guessing
 that I need millisecond resolution, but not sure of the requirements.

 At this point I am following after Brazil's original implementation,
 however I also built a little tool to cache timestamps in memory and
 grab them from anywhere in the code.  If you have other suggestions I
 would love to hear them.

   EBo --

Re: [9fans] nsec limits?

[ron minnich]

if nsec on whatever platform reads from /dev/bintime, my suggestion is
you not use it. Read from the processor counter instead.

ron

Re: [9fans] nsec limits?

[EBo]

 On Mon, 1 Aug 2011 10:17:13 -0700, ron minnich wrote:
> if nsec on whatever platform reads from /dev/bintime, my suggestion
> is
> you not use it. Read from the processor counter instead.

 Yes, nsec does call bintime from devcons.  Can you point to an example
 that uses the process counter?  I was trying to avoid using
 gettimeofday, and rereading through the devcons code I see that it
 sneaks in a call to todget() which IS gettomeofday.

   EBo --

Re: [9fans] nsec limits?

[Charles Forsyth]

what are you measuring? i suspect you don't need the processor counter.
(you're anyway not going to be wired to a single processor.)

Re: [9fans] nsec limits?

[EBo]

 On Mon, 1 Aug 2011 23:25:34 +0100, Charles Forsyth wrote:
> what are you measuring? i suspect you don't need the processor
> counter.
> (you're anyway not going to be wired to a single processor.)

 I'm measuring how much time it takes for the system to come up, reserve
 a number of tasks, run them, collect the output, and shut down.  I think
 the duration of the test for Brazil for 2048 tasks was ~12 seconds.
 OMMV..

   EBo --

Re: [9fans] nsec limits?

[ron minnich]

For 12 seconds, nsec is fine. I'm with charles on this one.

ron

Re: [9fans] nsec limits?

[EBo]

 On Mon, 1 Aug 2011 16:06:11 -0700, ron minnich wrote:
> For 12 seconds, nsec is fine. I'm with charles on this one.

 Even if/when I scale up to the entire machine I doubt that it will be
 more a minute.

 Eric was concerned about using get time of day because it can skew the
 results.  For now I'll just get the timing tests working and rerun them
 if there is an issue.

   EBo --

Re: [9fans] nsec limits?

[Charles Forsyth]

12 seconds is rather bigger in magnitude than a nanosecond,
so i think you're fairly safe. or, as wikipedia more poetically
puts it ``One nanosecond is to one second as one second is to 31.7 years.''
if you get to the stage where it's a matter of nanoseconds between the
systems, there's not much between them.

Re: [9fans] nsec limits?

[Charles Forsyth]

ron, by contrast, was timing a particular short interaction, which might be repeated
a great many times (and thus mount up),
where non-trivial overhead of taking the measurement could easily hide significant differences
between two implementations, hence the use of a timer provided directly by hardware.

Re: [9fans] nsec limits?

[EBo]

 On Tue, 2 Aug 2011 00:19:32 +0100, Charles Forsyth wrote:
> ron, by contrast, was timing a particular short interaction, which
> might be repeated
> a great many times (and thus mount up),
> where non-trivial overhead of taking the measurement could easily
> hide significant differences
> between two implementations, hence the use of a timer provided
> directly by hardware.

 With the course timing I am currently doing this should be OK, but if I
 end up doing finer scale testing it will probably be in the us range.
 So, I would like to figure out how to do low overhead measurements if it
 will not take a lot of my time to get it working.

Re: [9fans] nsec limits?

[erik quanstrom]

> puts it ``One nanosecond is to one second as one second is to 31.7 years.''

it would be somewhat less poetic if we kept time in metric.  :-)

- erik