thorpej@nas.nasa.gov writes:
> On Wed, 19 Nov 97 13:22:57 -0600 
>  Greg Oster <oster@cs.usask.ca> wrote:
> 
>  > Hi folks
> 
> Hiya Greg...
> 
>  > Can someone with a NetBSD-1.3_Alpha/hp300 box run this little proggy to se
> e 
>  > if they get the same behaviour I'm seeing under 1.2E on the HP300 port?  
> 
> Hmm... first guess is that you have 68030s in your hp300s? 

In this particular one, it's actually an '040.
NetBSD 1.2E (MOB2) #23: Tue Jul  8 12:42:30 GMT+6 1997
    wlm125@darlene:/usr/local/home/wlm125/src/sys/arch/hp300/compile/MOB2
HP 9000/433 (33MHz MC68040 CPU+MMU+FPU, 4k on-chip physical I/D caches)

I just tried it on a:  HP 9000/400 (50MHz MC68030 CPU+MMU, 50MHz MC68882
 FPU, 32K physical-address cache)
and I got:
0 + 142694
0 + 142384
0 + 143371
0 + 140227
0 + 141160
0 + 142096
0 + 143038
0 + 140001
0 + 140910
0 + 141818

> One my
> 25MHz 68040 hp380:
> 
> basalt:thorpej 256$ ./a.out
> 0 + 54520
> 0 + 50062
> 0 + 50358
> 0 + 57603
> 0 + 57942
> 0 + 58283
> 0 + 58619
> 0 + 58960
> 0 + 56348
> 0 + 56707
> basalt:thorpej 257$ 
> 
> It's important to note that sleep(3) actually _suspends_ execution; the
> process will not accumulate user time during that call.  It _will_,
> however, accumulate user time while user code is executing, and
> on slower processors, that takes longer.  

Sure... but then how does the total accumlated time manage to decrease? 

> Thus you will see "inflated"
> values for ru_utime as compared to systems with faster processors.

That's what I was wondering... Except on my Sun 3/50 I saw:
0 + 415849
0 + 425743
0 + 425745
0 + 425747
0 + 425748
0 + 425750
0 + 425752
0 + 425754
0 + 425755
0 + 425757

(Unfortunatly I only ran a single test last night, but a similar program
which did repeated gettimeofday() (and which I'll post in a subsequent 
message) calls also produced a "good" result)

> I'm guessing that the i386 that you ran this program on is a faster box
> than your hp300s :-)

'Tis in deed... :-) And that was my initial reaction to this problem... 
I'm not convinced, however, that speed alone should make the difference 
here... (and although NetBSD is most wonderful, I don't think there's anything 
in the kernel such that "if we run it just a little bit longer, it will 
acutually take less time" :) )

Later...

Greg Oster

oster@cs.usask.ca
Department of Computer Science
University of Saskatchewan, Saskatoon, Saskatchewan, CANADA