All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How does block size affect results of DD tests?
So it is related to my dedi with datashack but I guess it is some knowledge that is useful in general.
Here is what I have got with the dd test:
# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB) copied, 16.3408 s, 65.7 MB/s# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 57.0383 s, 18.8 MB/s
# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB) copied, 16.1923 s, 66.3 MB/s# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 28.4043 s, 37.8 MB/s`
And here is what Datashack came back to me saying my disk has no issue because they managed to get pretty dd read/writes:
# dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync 128+0 records in 128+0 records out 134217728 bytes (134 MB) copied, 2.14908 s, 62.5 MB/s# dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 1.83529 s, 73.1 MB/s
`# dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 1.7653 s, 76.0 MB/s
dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 1.86034 s, 72.1 MB/s
# dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync 128+0 records in 128+0 records out 134217728 bytes (134 MB) copied, 1.92275 s, 69.8 MB/s# dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 1.9657 s, 68.3 MB/s
# dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 13.4248 s, 80.0 MB/s# dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 15.5446 s, 69.1 MB/s
# dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 13.7851 s, 77.9 MB/s# dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 13.9589 s, 76.9 MB/s`
The only differences here is the block size, I used 64k and they used 1M.
I am just wondering which one is a better indication of the performance? Mine has a RAID 0 set up with stripe size set to either 64k or 32k.
Thanks!
Comments
sweet mother of font size
sorry for the # sign...
Use pre tags... u_u
@Pie Your image is broken...
Btw, if I use 16k or 1M I get the same results.
What are you talking about? Its coming up fine for me :P
(it was a ninja edit lol)
Picture did not come up for me as well, but my workplace block most of the image hosting sites anyways...
So anyone has a clue to my question?
block size does affect the speed on dd
the MB/s speed reported from dd is caculated from the amount of data and the time dd used to wrote it
if you choose a blocksize with an overhead on a 1sec scale, this means that dd needed to "slow down" the write
for example, let's say that your hd can't read more than 128kb/s
choosing a 128k blocksize means that every block operation fits in 1 second
if you choose a 192kb blocksize every operation then needs 1.5 second. usually this leads to 2 sec, having dd write 128k during the first one, and then 64k plus 0.5 second of idle
the speed reported is affected by that idle time
(similar if you choose a blocksize smaller than the maximum hd bandwidth)
you can do a test dd between two device with different speed: the best blocksize is something like the least common multiple of the twos. using the highest or the lowest, slows down one of the devices
i don't know about striped raid, as your raid0
in theory on a raid with parity check, every block writes has an overhead to achive the raid redudancy, more write operations you do, more overhead you get
so, yes, 64k blocksize means more writes than 1m blocksize