From owner-freebsd-scsi Wed Aug 25 9: 7:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from grisu.bik-gmbh.de (grisu.bik-gmbh.de [194.233.237.82]) by hub.freebsd.org (Postfix) with ESMTP id D008F15135 for ; Wed, 25 Aug 1999 09:07:30 -0700 (PDT) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.194]) by grisu.bik-gmbh.de (8.8.8/8.6.9) with ESMTP id SAA10485; Wed, 25 Aug 1999 18:06:47 +0200 (MEST) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.3/8.7.3) id SAA69455; Wed, 25 Aug 1999 18:06:28 +0200 (MET DST) Date: Wed, 25 Aug 1999 18:06:28 +0200 From: Martin Cracauer To: liudong Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: The I/O is too slow than linux Message-ID: <19990825180628.B66149@cons.org> References: <199908240727.CAA14695@db.geocrawler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908240727.CAA14695@db.geocrawler.com>; from Geocrawler.com on Tue, Aug 24, 1999 at 02:27:44AM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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