9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] nsec limits?
@ 2011-08-01 12:17 EBo
  2011-08-01 12:36 ` erik quanstrom
  2011-08-01 15:57 ` ron minnich
  0 siblings, 2 replies; 15+ messages in thread
From: EBo @ 2011-08-01 12:17 UTC (permalink / raw)
  To: 9Fans-list

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 12:17 [9fans] nsec limits? EBo
@ 2011-08-01 12:36 ` erik quanstrom
  2011-08-01 13:22   ` EBo
  2011-08-01 15:57 ` ron minnich
  1 sibling, 1 reply; 15+ messages in thread
From: erik quanstrom @ 2011-08-01 12:36 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 12:36 ` erik quanstrom
@ 2011-08-01 13:22   ` EBo
  0 siblings, 0 replies; 15+ messages in thread
From: EBo @ 2011-08-01 13:22 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 12:17 [9fans] nsec limits? EBo
  2011-08-01 12:36 ` erik quanstrom
@ 2011-08-01 15:57 ` ron minnich
  2011-08-01 17:12   ` EBo
  1 sibling, 1 reply; 15+ messages in thread
From: ron minnich @ 2011-08-01 15:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

ron



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 15:57 ` ron minnich
@ 2011-08-01 17:12   ` EBo
  2011-08-01 17:17     ` ron minnich
  0 siblings, 1 reply; 15+ messages in thread
From: EBo @ 2011-08-01 17:12 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 17:12   ` EBo
@ 2011-08-01 17:17     ` ron minnich
  2011-08-01 20:25       ` EBo
  0 siblings, 1 reply; 15+ messages in thread
From: ron minnich @ 2011-08-01 17:17 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

ron



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 17:17     ` ron minnich
@ 2011-08-01 20:25       ` EBo
  2011-08-01 22:25         ` Charles Forsyth
  0 siblings, 1 reply; 15+ messages in thread
From: EBo @ 2011-08-01 20:25 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 20:25       ` EBo
@ 2011-08-01 22:25         ` Charles Forsyth
  2011-08-01 22:51           ` EBo
  0 siblings, 1 reply; 15+ messages in thread
From: Charles Forsyth @ 2011-08-01 22:25 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 22:25         ` Charles Forsyth
@ 2011-08-01 22:51           ` EBo
  2011-08-01 23:06             ` ron minnich
  2011-08-01 23:14             ` Charles Forsyth
  0 siblings, 2 replies; 15+ messages in thread
From: EBo @ 2011-08-01 22:51 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 22:51           ` EBo
@ 2011-08-01 23:06             ` ron minnich
  2011-08-01 23:31               ` EBo
  2011-08-01 23:14             ` Charles Forsyth
  1 sibling, 1 reply; 15+ messages in thread
From: ron minnich @ 2011-08-01 23:06 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

ron



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 22:51           ` EBo
  2011-08-01 23:06             ` ron minnich
@ 2011-08-01 23:14             ` Charles Forsyth
  2011-08-01 23:19               ` Charles Forsyth
  2011-08-01 23:25               ` erik quanstrom
  1 sibling, 2 replies; 15+ messages in thread
From: Charles Forsyth @ 2011-08-01 23:14 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 23:14             ` Charles Forsyth
@ 2011-08-01 23:19               ` Charles Forsyth
  2011-08-01 23:49                 ` EBo
  2011-08-01 23:25               ` erik quanstrom
  1 sibling, 1 reply; 15+ messages in thread
From: Charles Forsyth @ 2011-08-01 23:19 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 23:14             ` Charles Forsyth
  2011-08-01 23:19               ` Charles Forsyth
@ 2011-08-01 23:25               ` erik quanstrom
  1 sibling, 0 replies; 15+ messages in thread
From: erik quanstrom @ 2011-08-01 23:25 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 23:06             ` ron minnich
@ 2011-08-01 23:31               ` EBo
  0 siblings, 0 replies; 15+ messages in thread
From: EBo @ 2011-08-01 23:31 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] nsec limits?
  2011-08-01 23:19               ` Charles Forsyth
@ 2011-08-01 23:49                 ` EBo
  0 siblings, 0 replies; 15+ messages in thread
From: EBo @ 2011-08-01 23:49 UTC (permalink / raw)
  To: 9fans

 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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2011-08-01 23:49 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-01 12:17 [9fans] nsec limits? EBo
2011-08-01 12:36 ` erik quanstrom
2011-08-01 13:22   ` EBo
2011-08-01 15:57 ` ron minnich
2011-08-01 17:12   ` EBo
2011-08-01 17:17     ` ron minnich
2011-08-01 20:25       ` EBo
2011-08-01 22:25         ` Charles Forsyth
2011-08-01 22:51           ` EBo
2011-08-01 23:06             ` ron minnich
2011-08-01 23:31               ` EBo
2011-08-01 23:14             ` Charles Forsyth
2011-08-01 23:19               ` Charles Forsyth
2011-08-01 23:49                 ` EBo
2011-08-01 23:25               ` erik quanstrom

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).