> Imagine my suprise when I found that apparently the beast does
> infinite dhrystones per second.... some system!
Erik> We told you these Alpha's are fast!
> /usr/bin/time was returning 0 for sys and elapsed time under all
> circumstances - user time appeared OK.
> Recompiling (ie installing the SRPM and building it), fixed that.
> Presumably something in the kernel has changed???
> I am using a 1.3.46 kernel, built here.
Erik> I'm rebuilding it here as well. I'll make a new RPM available today
Erik> (time-1.6-3).
I replayed this time(1) story 2.5 months later, on my BLADE_0.3 platform.
I think it is [was] due to times(3) which uses [used] to return a
value in ~seconds, not in clock ticks unless redefining HZ to 1
(HZ is set to 1024 by <asm/param.h> for a "noname" board, & Digital Unix
uses the same setting).
Does anybody know how it has been fixed (e.g. by a change to the libraries,
to the system header files, to the kernel...) ?
I have also a question on clock_t: it's a `long' on BLADE_0.3 (<asm/types.h>)
but an `int' on Digital Unix (<sys/types.h>). While perhaps sometimes
hidden by the Alpha chip tolerant endianess, it should make a (small) hole in
binary compatibility of Linux/Alpha with Digital Unix. I'd like to
understand the advantage of preferring `long' to `int': is it because
Linux/Intel's clock_t is also `long' ?
Thanks a lot,
fred