Typo, in Box 5. Wrong kernel version Box 5, RHEL 5.4, 2.6.36, dd bs=1024 count=1000000 if=/dev/zero bs=4096k of=/dev/null Anyone had a chance to try this? :-) On Thu, Jan 20, 2011 at 8:16 PM, Mag Gam <magawake@xxxxxxxxx> wrote: > Greg, > > Yes, I did one very big like 100TB and I still see the regression. ÂI > even tried it with your extra dd option. > I am wondering if the new kernel (2.6.36) introduced an options I need to set ? > > Can someone else try this? > > To reiterate the test scenario, > Box 1, RHEL 5.1, stock kernel, dd bs=1024 count=1000000 if=/dev/zero > bs=4096k of=/dev/null > Box 2, RHEL 5.2, stock kernel,dd bs=1024 count=1000000 if=/dev/zero > bs=4096k of=/dev/null > Box 3, RHEL 5.3, stock kernel, dd bs=1024 count=1000000 if=/dev/zero > bs=4096k of=/dev/null > Box 4, RHEL 5.4, stock kernel, dd bs=1024 count=1000000 if=/dev/zero > bs=4096k of=/dev/null > Box 5, RHEL 5.4, 2.6.35, dd bs=1024 count=1000000 if=/dev/zero > bs=4096k of=/dev/null > > Box 5 takes much much longer. > > And all of these boxes are the same model and specs... > > > > > > > On Thu, Jan 20, 2011 at 9:29 AM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: >> Mulyadi, >> >> You disappoint me. ;( >> >> Just kidding, but discussing dd throughput without the >> "conv=fdatasync" parameter is just a waste of everyone's time. >> >> And Mag, use a big enough count that it at least takes a few seconds >> to complete. ÂA tenth of a second or less is just way to short to use >> as a benchmark. >> >> Greg >> >> On Thu, Jan 20, 2011 at 12:28 AM, Mulyadi Santosa >> <mulyadi.santosa@xxxxxxxxx> wrote: >>> Hi... >>> >>> On Thu, Jan 20, 2011 at 10:36, Mag Gam <magawake@xxxxxxxxx> wrote: >>>> Running on Redhat 5.1 if I do, >>> >>> Are you sure you're using that archaic distro? Or are you talking >>> about RHEL 5.1? >>> >>>> dd bs=1024 count=1000000 if=/dev/zero of=/dev/null >>>> >>>> I get around 30Gb/sec >>> >>> Hm, mine is: >>> $ dd bs=1024 count=1000000 if=/dev/zero of=/dev/null >>> 1000000+0 records in >>> 1000000+0 records out >>> 1024000000 bytes (1.0 GB) copied, 1.12169 seconds, 913 MB/s >>> >>> This is on 2.6.36 SMP kernel compiled with gcc version 4.1.2 20080704 >>> (Red Hat 4.1.2-48). >>> >>>> >>>> However, when I do this with 2.6.37 I get close to 5GB/sec >>> >>> what if you use another blocksize, let's say 4K or even 32K? here's >>> mine (again): >>> $ dd bs=4K count=1000000 if=/dev/zero of=/dev/null >>> 1000000+0 records in >>> 1000000+0 records out >>> 4096000000 bytes (4.1 GB) copied, 1.31167 seconds, 3.1 GB/s >>> >>> $ dd bs=32K count=1000000 if=/dev/zero of=/dev/null >>> 1000000+0 records in >>> 1000000+0 records out >>> 32768000000 bytes (33 GB) copied, 4.91775 seconds, 6.7 GB/s >>> >>> see the difference? >>> >>> IMHO it's a matter of what I call "block merge efficiency"....the more >>> you stuff pages (that fits into a "magic" number), the faster I/O you >>> got. >>> >>> -- >>> regards, >>> >>> Mulyadi Santosa >>> Freelance Linux trainer and consultant >>> >>> blog: the-hydra.blogspot.com >>> training: mulyaditraining.blogspot.com >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies@xxxxxxxxxxxxxxxxx >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> >> >> >> -- >> Greg Freemyer >> Head of EDD Tape Extraction and Processing team >> Litigation Triage Solutions Specialist >> http://www.linkedin.com/in/gregfreemyer >> CNN/TruTV Aired Forensic Imaging Demo - >> ÂÂ http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/ >> >> The Norcross Group >> The Intersection of Evidence & Technology >> http://www.norcrossgroup.com >> > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
