Re: Slow I/O responsiveness with UDMA133
On Mon, 30 Sep 2002, Sean Farley wrote: On Thu, 26 Sep 2002 21:14, Mike Silbersack wrote: Rumor has it that newer drives cannot write a single sector at a time, and instead must read a whole cluster of sectors, add in the new sector, and write back the whole cluster. That behavior sounds like it would hurt sequentual performance substantially, as it would become a lot of read-modify-write operations. That is interesting. I had not heard of that issue, even as a rumor, before. I see this hurting byte writes, but block writes may not be hurt by it. The concept isn't that ridiculous. If the drive cannot write 1 byte at a time, why should it be able to write 4096 bytes at a time, or 8192 bytes, etc. Unfortunately, I doubt that any drive manufacturer will tell us the exact figures. :) You would not happen to have a non-RAID, UDMA100+, non-VIA system that you could run bonnie++ (-s256) on? It would at least show to me if my system is really all that far from the norm. Sean Nope, not here. Maybe someone else on the list can send you results... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Slow I/O responsiveness with UDMA133
On Thu, 26 Sep 2002 21:14, Mike Silbersack wrote: On Thu, 26 Sep 2002, Sean Farley wrote: I just do not understand how a 5400 RPM UDMA 33 drive can beat a 7200 RPM UDMA 133 drive by 33% on sequential output blocks. Rumor has it that newer drives cannot write a single sector at a time, and instead must read a whole cluster of sectors, add in the new sector, and write back the whole cluster. That behavior sounds like it would hurt sequentual performance substantially, as it would become a lot of read-modify-write operations. That is interesting. I had not heard of that issue, even as a rumor, before. I see this hurting byte writes, but block writes may not be hurt by it. Does the drive support tagged queueing? That should give you the benefits of write caching with a little bit more safety. I thought only IBM had IDE drives which supported tags. No. The specs do not mention tags. Hm, I thought other vendors had started to support them, I guess they decided not to. :| I think there are a few Maxtor SCSI drives with it, but I could not find mention on their site with regards to any IDE drives. It would be nice assuming it was done correctly. I have no idea on what BIOS settings would be optimal. I doubt that they'll make a real performance difference. None as far as I can see. You would not happen to have a non-RAID, UDMA100+, non-VIA system that you could run bonnie++ (-s256) on? It would at least show to me if my system is really all that far from the norm. Sean --- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Slow I/O responsiveness with UDMA133
On Wed, 25 Sep 2002 22:34, Mike Silbersack wrote: On Wed, 25 Sep 2002, Sean Farley wrote: With write cache enabled it does perform better, but I would like the new computer to at least equal the old system without it enabled. With all due respect, whether that's a reality isn't your choice, it's the drive's choice. :) I am sorry, but I do not give my computer components freedom of choice. :) I just do not understand how a 5400 RPM UDMA 33 drive can beat a 7200 RPM UDMA 133 drive by 33% on sequential output blocks. Does the drive support tagged queueing? That should give you the benefits of write caching with a little bit more safety. I thought only IBM had IDE drives which supported tags. No. The specs do not mention tags. Another question, I see that in the archives that enabling IDE Prefetch was not good. Has this changed? I currently have it turned off in the BIOS. Hmm, I see that Søren mentions it should be kept on: http://groups.google.com/groups?hl=enlr=lang_enie=UTF-8selm=200201091654.g09GsG703561_freebsd.dk%40ns.sol.net OTOH, he says that the ATA driver automatically turns it on. BTW, would there happen to be a preferred BIOS setup page for FreeBSD? I have already scanned through the docs. Sean --- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Slow I/O responsiveness with UDMA133
On Thu, 26 Sep 2002, Sean Farley wrote: I just do not understand how a 5400 RPM UDMA 33 drive can beat a 7200 RPM UDMA 133 drive by 33% on sequential output blocks. Rumor has it that newer drives cannot write a single sector at a time, and instead must read a whole cluster of sectors, add in the new sector, and write back the whole cluster. That behavior sounds like it would hurt sequentual performance substantially, as it would become a lot of read-modify-write operations. Does the drive support tagged queueing? That should give you the benefits of write caching with a little bit more safety. I thought only IBM had IDE drives which supported tags. No. The specs do not mention tags. Hm, I thought other vendors had started to support them, I guess they decided not to. :| I have no idea on what BIOS settings would be optimal. I doubt that they'll make a real performance difference. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Slow I/O responsiveness with UDMA133
I have a Soltek 75DRV5 (VIA 8233a) and a Maxtor 6L080L4. The problem I am having is with poor performance with ATA-133. My ATA-33 system beats it. After building a new system, I noticed that it was less responsive when it came to I/O concerning the hard drive. The standard XFree86 source extraction would slow down anything else that tried to access something off of the drive. It could take at least 10-20 seconds for a login attempt from the console to prompt for the password after I entered the user ID. On my old system this was not the case. It would slow down the system, but it would be much more responsive. In both cases the write cache was disabled. I have fiddled with the BIOS without success. I even tried changing the PCI latency on different PCI devices to see if kern/32338 may be effecting me. To imitate the problem and get some numbers as well, I have been trying things out using bonnie++. I ran bonnie++ -s 256 -d /usr/tmp/bonnie where /usr/tmp/bonnie was an empty directory. I did not have trouble with my cable being recognized, but I am beginning to wonder whether the order is impacting performance as the hard drive is on the secondary controller. I will be annoyed if that has been the problem. I still need to dig the box out and try this. With write cache enabled it does perform better, but I would like the new computer to at least equal the old system without it enabled. Here are some benchmarks on my computers. I believe the sequential output is the killer. atacontrol does show the new system to be using UDMA133. Both drives are on a controller by themselves. Before I get to the benchmarks, I have a ktrace of ls -lF of /usr/bin during bonnie++. It shows some long times during the listing. ... 410 ls 5.497238 CALL readlink(0xbfbfed20,0xbfbfe91c,0x400) 410 ls 0.096740 NAMI ./mailq 410 ls 12.262074 RET readlink 21/0x15 ... If I run it again, I can get it to wait a long time on a different call like close(). Are these times normal? For a system giving slower values from bonnie++ than a PIII 450, I would expect even better responsiveness. -- New System -- Athlon XP 2100 Maxtor (76345MB MAXTOR 6L080L4 [155114/16/63] at ata1-master UDMA133) 7200 RPM hw.ata.ata_dma: 1 hw.ata.wc: 0 hw.ata.tags: 0 hw.ata.atapi_dma: 0 Bonnie++ test (w/o write cache) --- Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.02c --Sequential Output-- -Per Chr- --Block-- -Rewrite- MachineSize K/sec %CP K/sec %CP K/sec %CP System 1 256M 10757 10 10767 3 11188 4 --Sequential Input- --Random- -Per Chr- --Block-- --Seeks-- K/sec %CP K/sec %CP /sec %CP 67468 97 468575 99 12770 29 --Sequential Create-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP 16 9880 17 + +++ + +++ Random Create -Create-- --Read--- -Delete-- /sec %CP /sec %CP /sec %CP + +++ + +++ + +++ -- Old System -- PIII 450 Seagate (27199MB ST328040A [55262/16/63] at ata0-master UDMA33) 5400RPM hw.ata.ata_dma: 1 hw.ata.wc: 0 hw.ata.tags: 0 hw.ata.atapi_dma: 0 Bonnie++ test - Writing with putc()...done Writing intelligently...done Rewriting...done Reading with getc()...done Reading intelligently...done start 'em...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.02c --Sequential Output-- -Per Chr- --Block-- -Rewrite- MachineSize K/sec %CP K/sec %CP K/sec %CP System 2 256M 16246 89 16052 24 7069 14 --Sequential Input- --Random- -Per Chr- --Block-- --Seeks-- K/sec %CP K/sec %CP /sec %CP 14597 94 17455 14 462.2 3 --Sequential Create-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP 16 5081 46 + +++ 13559 95 Random
Re: Slow I/O responsiveness with UDMA133
On Wed, 25 Sep 2002, Sean Farley wrote: With write cache enabled it does perform better, but I would like the new computer to at least equal the old system without it enabled. With all due respect, whether that's a reality isn't your choice, it's the drive's choice. :) Does the drive support tagged queueing? That should give you the benefits of write caching with a little bit more safety. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
