dd statistics broken

[marcusoverhagen]

The statistics that dd prints are completely wrong or random.

1GB in 20 seconds should be about 50MB/sec not 8.9 1GB in 0.6 seconds should be about 1.6GB/sec not 6.1 1.5GB in 29 seconds should be about 51MB/sec not 2.6

and finally, 1.5GB in 75 seconds might indicate that read performance suffers once the cache is full...

hrev22863, tested with the si3112 sata driver

[axeld]

It's actually the same problem that affected "seq" - src/bin/coreutils/lib/human.c uses long doubles to compute, and "%Lf" to print the value, and we apparently do not support this. Korli, do you want to fix that like you fixed the earlier problem? Or can we actually fix this for real and let printf support that type?

[korli]

Just checked again with GCC2.95.3 and Dano : long double is not well supported. The problem doesn't appear with GCC4.

[korli]

I found out the problem : the float.h header provided by gcc2.95 is not correct for long double values (which pretty much a copy-paste of double values). here is the path generated_v2/cross-tools/lib/gcc-lib/i586-pc-beos/2.95.3-beos-060710/include/float.h

Oliver, could you have a look ? To fix the problem locally, I had to copy gcc4 float.h values to this file.

[korli]

Fix applied in hrev23127.

we need to set float_format for the target i586-beos-pc to i386. If not, we default to i64, which means long double equals double.

[korli]

(clearing up) As the fix is for gcc, it should be rebuilt to have the bug fixed.