Søren Schmidt wrote: > Michael Nottebrock wrote: > >> On Sunday 26 September 2004 12:50, Doug Russell wrote: >> >>> On Sun, 26 Sep 2004, Michael Nottebrock wrote: >>> >>>> On Saturday 25 September 2004 23:45, Jeremy Chadwick wrote: >>>> >>>>> 6) I'm still amazed people have systems in production that use ICH2. >>>>> AFAIK, the chipset is deprecated. >>>> >>>> >>>> Eh? i845-based motherboards were not exactly a niche product and >>>> are not >>>> very ancient either. I'm surprised it surprises you to see them >>>> used. :-) >>> >>> >>> Bah! Just because some hardware is common does not mean is is good! >> >> >> >> Supporting and being used on common-but-not-so-good hardware is one >> of the best (and oldest) traditions of FreeBSD. :-) > > > Yeah, well, we try, my last ich2 based system died long ago so it > makes it harder to keep support top notch :) > > Anyhow, please try the below patch and let me know if that changes > behavior in anyway. > > BTW, you need to compare speeds of the *exact same* area of the > disk(s). Modern disk often has only half the transfer rate on the last > 1/3 of the platters.. > > diff -u -r1.88 ata-chipset.c > --- ata-chipset.c 10 Sep 2004 10:31:37 -0000 1.88 > +++ ata-chipset.c 26 Sep 2004 12:08:56 -0000 > _at__at_ -976,6 +976,8 _at__at_ > pci_write_config(parent, 0x48, reg48 & ~(0x0001 << devno), 2); > pci_write_config(parent, 0x4a, (reg4a & ~(0x3 << (devno << > 2))), 2); > } > + > + reg54 |= 0x0400; > if (mode >= ATA_UDMA2) > pci_write_config(parent, 0x54, reg54 | (0x1 << devno), 2); > else > > i) I patched ata-chipset.c. All kernel debugging options disabled. Userland: ln -s aj /etc/malloc.conf to disable malloc warning and initializations. The weird behaviour of write performance with ATA channell reiinit remains: FBSDa: before ATA channell reiinit FBSDb: after ATA channell reiinit before patch: / / -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machi MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU % FBSDa 1500 14533 12.8 14184 4.6 9360 3.2 27774 24.0 29067 5.7 119.1 0.6 % FBSDb 1500 27787 24.6 24690 8.3 12519 4.3 24487 21.4 24870 5.0 128.1 0.6 after patch/ / -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machi MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU % FBSDa 1500 15505 13.7 15126 4.9 9801 3.3 27715 24.1 29508 5.5 131.3 0.5 % FBSDb 1500 26937 23.6 24327 8.3 12368 4.2 24643 21.5 25723 5.1 130.4 0.6 that is: no appreciable change. reinit improves write performance: why? ATA channell reinit doesn't change important kernel parameters: hw.ata.ata_dma: 1 hw.ata.wc: 1 hw.ata.atapi_dma: 1 are the same before and after reinit. All the following tests are with patched ata-chipset.c. Many thanks to Stefan for the suggestions in this regard. ii) Now I tried a fair raw throughput comparison between Linux and FreeBSD. This time I read always the same whole (Linux) partition (~4GB) so that the results should be comparable. I always used native dd (FreeBSD and Linux). A measure with Linux dd under emulation in FreeBSD gave yet the same result: dd if=/dev/ad0s9 bs=nnn of=/dev/null FreeBSD: nnn=4k: 4301789184 bytes transferred in 170.031898 secs (25299895 bytes/sec) nnn=8k: 4301789184 bytes transferred in 114.446100 secs (37587905 bytes/sec) nnn=16k: 4301789184 bytes transferred in 87.794076 secs (48998627 bytes/sec) nnn=64k: 4301789184 bytes transferred in 89.515195 secs (48056525 bytes/sec) nnn=512k: 4301789184 bytes transferred in 90.357666 secs (47608458 bytes/sec) (no significant changes before or after reinit) Linux: nnn=4k: 4301789184 bytes transferred in 93 secs (~46 Mbytes/sec) nnn=8k: 4301789184 bytes transferred in 86 secs (~50 Mbytes/sec) nnn=16k: 4301789184 bytes transferred in 90 secs (~48 Mbytes/sec) nnn=64k: 4301789184 bytes transferred in 95 secs (~45 Mbytes/sec) nnn=512k: 4301789184 bytes transferred in 92 secs (~47 Mbytes/sec) I notice, that the rates are very similar if bs >= 16k. Under FreeBSD the raw throughput rate depends on the block size. Read rate under Linux is independent of the block size. Is there a special reason for that? iii) Next I tried a fair comparison with bonnie: I ran the Linux version of bonnie under emulation in FreeBSD. Bonnie writes on the (under FBSD) mounted Linux partition used in Linux bonnie test. Now the results should be at least comparable: again FBSDa is before reinit, FBSDb after reinit: ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU FBSDa 1500 14881 62.5 15025 4.9 10632 5.3 21802 82.6 46983 13.6 152.5 0.9 FBSDb 1500 22153 91.9 45304 14.8 18694 9.3 22379 84.9 46470 13.4 154.0 0.9 Linux 1500 26859 97.7 59118 14.0 22480 8.1 22508 78.9 48501 9.0 177.1 0.5 The results for FreeBSDb are now much better, due to the fact, that Bonnie reads and writes on a faster disk part. The slight performance loss in respect of Linux could be due to the ext2fs driver or because of the Linux emulation, so I can't complain here. To compare, I started Bonnie under emulation on the /usr (slow) FreeBSD partition: ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU FBSDa 1500 15519 60.5 15284 4.4 9815 3.9 23097 86.8 28838 6.5 134.5 0.6 FBSDb 1500 23743 91.8 24398 7.3 12378 5.0 20396 76.8 24830 5.9 129.7 0.6 Read results are bad, because this partition is on a slow part of the disk, as Søren pointed out. Again you have a clear drop of the write performance before ATA reinit. iv) Conclusion: read and write performance are ok and similar to Linux. It's not clear to me why I have to reinit the ATA channell to have the right write performance nor why the read performance depends on the block size in FreeBSD and is independent of it in Linux. Kind regards, MauroReceived on Sun Sep 26 2004 - 22:21:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:14 UTC