Neither the time executable from the GNU time package work completely
correctly, nor does the GNU Bash built-in one.
tschwinge@flubber:~ $ \time sleep 2
0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ \time sleep 4
0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ \time sleep 6
0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
tschwinge@flubber:~ $ time sleep 2
real 0m2.093s
user 0m0.000s
sys 0m0.011s
tschwinge@flubber:~ $ time sleep 4
real 0m4.083s
user 0m0.000s
sys 0m0.010s
tschwinge@flubber:~ $ time sleep 6
real 0m6.164s
user 0m0.000s
sys 0m0.010s
GNU time's elapsed value is off by some factor.
$ \time factor 1111111111111111111
1111111111111111111: 1111111111111111111
0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
$ time factor 1111111111111111111
1111111111111111111: 1111111111111111111
real 0m11.424s
user 0m0.000s
sys 0m0.010s
As above; also here all the running time should be attributed to user time. This is probably a open issue gnumach.
2011-09-02
Might want to revisit this, and take Xen into account -- I believe flubber has already been Xenified at that time.
IRC, freenode, #hurd, 2011-09-02
While testing some IPC virtual copy performance issues:
<tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k
running, a parallel sleep 10 takes about 20 s (on strauss).
2013-03-30/31
Investigating time's configure, a difference of the output between Linux and
Hurd shows:
-checking for wait3 that fills in rusage... yes
+checking for wait3 that fills in rusage... no
This causes a different code path in resuse.c to be used; such code path does
not get a define for HZ, which is then defined with a fallback value of 60.
Debian bug #704283 has been filed with a fix for this no-wait3 case.
