Closed thomas725 closed 1 year ago
I have the same issue on QNAP. It looks like mbit/s is printed instead MB/s
I had the same problem (and it's not only disks, it's also network). It's because the defaults were changed (see e860706dda71498f1d8fa4fa10f3f05322837f45 and also first as driveby here: 573843108557f260d0e657c6cf4fec8bf66b5ef8), dstat used bytes by default (and has a --bits
option to change that), dool now uses bits by default and has an undocumented --bytes
option to switch back to bytes. The help still only lists the --bits
option to force to bits.
I don't know why this was changed (I didn't find more background information about that change), I personally found the bytes-default much more useful.
I can confirm the issue, and it seems the network transfer speed is also affected. The option --bytes
indeed solves this, but I would love for this option to be the default as well, since that was the case of dstat
.
@scottchiefbaker Could you elaborate on the reason for switching the default from bytes to bits?
All the network speeds I deal with on a regular basis are reported in bits. It only made sense for my fork to make --bits
the default. Since I primarily use Dool to report on network usage, and it's impact on disk performance it made sense.
The --bytes
option is available if you need output in XB/s.
bits/s are very practical at these times when my home NAS does 8589934592 bits per second in peak. It feels more satisfying, more powerful then small numbers using such insignificant units like Bytes. And especially its delightful to practice calculations when you interested to read-out size of your IO operations. Its easy. Just divide by 2 and 2 and ... 2 again and all is just fine. Only small kids can't do that on the fly watching columns of numbers rolling...
I know only one better unit to use. Sectors of preferably unknown size and let anyone look it-up how many bytes/sector do we talk about. Like memory pages in OS.
End of sarcasm - in 2022 hardly anyone need to measure bits/second, because we are dealing with hundreds of millions of Bytes/second way, way more often, then bits/second. Networking is using bits, because serial communication 40Y ago and because its cooler when IS offers 40mbit connection then 5MB connection. Bigger numbers sell better, right. Please, consider that. If you in doubt what people prefer, there is always https://doodle.com And if you don't care well - then you don't ;)
@scottchiefbaker Thanks for updating the doc on --bytes
.
I'm grateful for your contributions here.
All the network speeds I deal with on a regular basis are reported in bits.
While network speeds are often advertised in bits, that's not the case for disk speeds, and having the disk speeds reported in bits by default is very confusing and unexpected (and the fact that an issue like this exists proves that there are multiple people confused by this). Also, most UIs also report network speeds (download speeds for example) in bytes, so most people should be used to see speeds in bytes. That's why I think bytes would still be the better default. I think way more people would need to use a --bytes
parameter to switch back to the old default, than people had to use a --bits
parameter before.
Also, the manpage still only talks about the --bits
parameter and doesn't mention --bytes
.
Personally, I also like network speeds in bits but disk I/O in bytes. That would be my ideal.
Another vote for bytes being the default, as it is in line with the long-standing expected behavior and confuses those moving from dstat to dool. No other disk monitoring tool defaults to bits per second.
For now I'm going to leave bits as the default. The --bytes
option is documented and an easy alternative.
SUMMARY
packaged dstat reports correctly between 106-122mb/s for my usb3 disk under load. dool installed via AUR package dool-git reports 857-1030mb/s which is clearly not the rate the actual copy process is going.
ISSUE TYPE
DSTAT VERSION
DOOL VERSION
OS / ENVIRONMENT
Manjaro (Arch based)
STEPS TO REPRODUCE
run dstat and dool (with parameters that make it show disk transfer rates) and compare their outputs, for example:
dool -tafys
anddstat -tafmspl
EXPECTED RESULTS
matching realistic values for disk read/write rates
ACTUAL RESULTS