Date: Wed, 25 Aug 1999 18:06:28 +0200 From: Martin Cracauer <cracauer@cons.org> To: liudong <shift@263.net> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: The I/O is too slow than linux Message-ID: <19990825180628.B66149@cons.org> In-Reply-To: <199908240727.CAA14695@db.geocrawler.com>; from Geocrawler.com on Tue, Aug 24, 1999 at 02:27:44AM -0500 References: <199908240727.CAA14695@db.geocrawler.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199908240727.CAA14695@db.geocrawler.com>, Geocrawler.com wrote: > # time dd if=/dev/da0 of=/dev/null count=200000 > 200000+0 records in > 200000+0 records out > 102400000 bytes transferred in 36.852771 secs (2778624 bytes/sec) > > real 0m36.911s > user 0m0.372s > sys 0m5.982s > > The same computer in linux(2.2.5): > # time dd if=/dev/sda of=/dev/null count=200000 > 200000+0 records in > 200000+0 records out > 0.52user 2.29system 0:09.05elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (89major+13minor)pagefaults 0swaps > > What is the problem!!?? In addition to what other said, don't use /dev/null in benchmarks. Speed varies greatly over different operating systems (Ultrix on MIPS Decstations is real fun here). A dd replacement that can discard (or generate) data is in ports/misc/cstream. In fact, one of the major reasons to roll that tool is benchmarking and the /dev/null variances. You can use cstream to "benchmark" /dev/null: Linux: /home/cracauer(oskar)3% cstream -n 50m -o/dev/null -v1 -i- 52428800 B 50.0 MB 0.04 s 1220098940 B/s 1.14 GB/s FreeBSD: ~(knight)20% cstream -n 50m -o/dev/null -v1 -i- 52428800 B 50.0 MB 0.11 s 456219899 B/s 435.09 MB/s Both are 486/DX-100 256 KB cache. Blocksize 8k. I would also recommend testing through the filesystem, as amount of readahead and other parameters of the block devices may have different best values for direct block devices or when using a filesystem, especially one that isn't fresh or when using other patterns than sequential read. Not to speak of simultaneous access from several applications. When I switched a major application of my employer from a linear (complete) read of a file to mmapp()ing, FreeBSD looked even better than before. FreeBSD could take advantage of the fact that the application runs didn't touch every block of the file, just most. We originally found that complete reading was better than partly reading (we touch about than 30-70% of the file's blocks), but that data was gathered from pre-FreeBSD operating systems, which filled the holes with readahead anyway, hence no speedup from jumping and part-reading. Or in other words, don't benchmark, measure real applications and redo the measurement when the OS changes. And don't speculate about what the OS might be doing. If if you figure out what the OS does, you usually don't have experience to translate that behaviour into performance. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990825180628.B66149>