Dao-hui Chen wrote: > I have silimilar result, but this time the OS is 4.10-stable and 6-current > 4.10: Intel ICH4 with ST380021A, Seagate's 7200rpm hard disk > 6: Intel ICH2 with IC35L040AVER07, IBM's 7200rpm hard disk > > Both with custom kernel, soft-update and mount as async. > On 6-current I turn all debugging-related options off and using > SCHE_4BSD as default scheduler > > In sequential input (block), the 4.10 box got a incredible results > as 590747K/sec (!!!), while 6-current got only 24906K/sec > In sequential output(block), the difference is also noticable with > 37432 vs 22180. That's pretty average memory performance that you're getting. Of course, the ATA-133 and SATA-150 protocols have no possible way of transfering 590MB/sec, so you might want to look at ways to test performance that negates the common pitfalls such as OS caching, head position, etc. Also note that the large sequential access case is quite rare in real life; a more interesting and meaningful test is raw transaction/sec of small random data. I don't doubt that there is likely to be a performance difference between 4.x and 5.x, though. > > There may be some misses in sequential input, but in sequential output > the difference between 4.10 and 6 is noticable, about 15M/Sec. > Considering the > hardware difference, the difference in performance is still too large. Are you testing with identical disks and using identical locations on the disk? A common pitfall is to install multiple OS's on the same disk and then measure performance within each OS partition. Since sequential data rates change depending on whether the heads are close to the spindle or far away from the spindle, tests like this are mostly invalid. You need independent indentical disks that can be used to perform identical tests on identical absolute LBAs. You also need to confirm that things like WCE (Write Cache Enable) on the disks is set the same in all tests. Scott > > On Mon, 18 Oct 2004 16:42:55 +0200, Søren Schmidt <sos_at_deepcore.dk> wrote: > >>Kenneth Culver wrote: >> >>>Quoting fandino <fandino_at_ng.fadesa.es>: >>> >>> >>>>Hello Kevin, >>>> >>>>Kevin Oberman wrote: >>>> >>>> >>>>>>Tests were done win bonnie++ 1.93c and the results were Linux two >>>>>>times faster than FreeBSD using the same hardware. >>>>>> >>>>>>GNU/Linux 2.4.18 with ext2: 56848 K/sec >>>>>>FreeBSD 5.3b7 with default fs: 26347 K/sec >>>>>>FreeBSD 5.3b7 ata raid0* (two disks): 26131 K/sec >>>>>>FreeBSD 5.3b7 geom stripe* (two disks): 30063 K/sec >>>>> >>>>> >>>>> >>>>>Are you comparing apples with apples? I believe that Linux mounts file >>>>>systems as async by default. To compare with FreeBSD, you should use "-o >>>>>async" when you mount. Of course, this is less reliable. >>>>> >>>>>Also, make sure that disk write-cache is enabled on both or disabled on >>>>>both. >>>> >>>> >>>>write-cache was enable on all tests and disks were in UDMA5 mode. >>>> >>>>In this new round of tests I add FreeBSD witch async and OpenBSD (always >>>>using the same hardware). FreeBSD is by far, the worst throughput of all >>>>(about 50% slower than others) :-? >>>> >>>>GNU/Linux 2.4.18 with ext2: 56848 K/sec >>>>FreeBSD 5.3b7 with default fs: 26347 K/sec >>>>FreeBSD 5.3b7 with default fs(async): 26566 K/sec >>>>FreeBSD 5.3b7 ata raid0* (two disks): 26131 K/sec >>>>FreeBSD 5.3b7 geom stripe* (two disks): 30063 K/sec >>>>FreeBSD 5.3b7 geom stripe** (four disks): 31891 K/sec >>>>OpenBSD 3.5 UFS fs: 55277 K/sec >>>> >>>>* Each disk of the raid had a throughput of approx. 15000 K/sec >>>>** Each disk of the raid had a throughput of approx. 7500 K/sec >>>>Each disk of the read split the throughput by half. >>>> >>>>How is possible that FreeBSD performs as bad? >>>> >>>> >>> >>>If you're still using the GENERIC kernel, that could explain it, and >>>judging >>>from other emails I've seen from you, you're still using the GENERIC >>>kernel. >> >>Right, and you should also use -U (softupdates) on you newfs line. >> >>-- >> >>-Søren >> >> >> >> >>_______________________________________________ >>freebsd-current_at_freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >> > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Mon Oct 18 2004 - 13:53:47 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC