Re: pitiful performance of an SATA150 drive
Am Montag, den 26.03.2007, 14:36 -0400 schrieb Mikhail Teterin: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! FWIW: You could try cleaning the connectors and use a fresh new cable for the connection (the spec has a very small value for plugging the connectors at the cable). I had massive problems and got rid of them that way ... Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
- Original Message - From: Marc Santhoff [EMAIL PROTECTED] To: Mikhail Teterin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 8:22 AM Subject: Re: pitiful performance of an SATA150 drive Am Montag, den 26.03.2007, 14:36 -0400 schrieb Mikhail Teterin: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! FWIW: You could try cleaning the connectors and use a fresh new cable for the connection (the spec has a very small value for plugging the connectors at the cable). I had massive problems and got rid of them that way ... Marc Personally, I think the SATA cables are the biggest load of rubbish ever invented. They give endless headaches, always come lose, prone to vibration and are not strong enough to support the weight of the SATA cable itself. The ones that come with the Areca cards have clips that help a little. They should have used a FCH connector or something like that that has been proven in the field for years instead of inventing some flimsy rubbish that isn't reliable. If you can, glue the cables on the drive side at least so that they don't give you headaches. -Clay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
Marc Santhoff wrote: Am Montag, den 26.03.2007, 14:36 -0400 schrieb Mikhail Teterin: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! FWIW: You could try cleaning the connectors and use a fresh new cable for the connection (the spec has a very small value for plugging the connectors at the cable). Are you referring to how many time the cable can be plugged in and removed? If so what is the number? Thanks, Steve I had massive problems and got rid of them that way ... Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
Am Dienstag, den 27.03.2007, 08:58 -0400 schrieb Stephen Clark: Marc Santhoff wrote: Am Montag, den 26.03.2007, 14:36 -0400 schrieb Mikhail Teterin: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! FWIW: You could try cleaning the connectors and use a fresh new cable for the connection (the spec has a very small value for plugging the connectors at the cable). Are you referring to how many time the cable can be plugged in and removed? If so Yes, sorry for my lousy english ... what is the number? I don't remember the exakt count but it has only two digits. Expect 15 or 50 or so. But IIRC this was SATA 1 and may have changed with SATA 2 having a locking clip at the plug. Marc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! -mi On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote: = On Wednesday 01 March 2006, SЬren Schmidt wrote: = = dd if=/dev/ad8 of=/dev/null bs=1m = = Well, as I said, there is no obvious problems with _reading_. The above = command reads at well over 60Mb/s: = = 1638924288 bytes transferred in 25.374856 secs (64588516 bytes/sec) = = _Writing_, however, remains pathetic: = = dd of=/dev/ad8 if=/dev/zero bs=1m = 631242752 bytes transferred in 91.039066 secs (6933757 bytes/sec) = = = The problem is the blocksize that gets in the way of utilizing full = = transfer speed. = = Did you really expect the blocksize to make an order of (decimal) magnitude = difference? :-) It made no difference at all :-( = = Brian Candler asked: = = Just to be clear: this is Knoppix running on the *same* machine as you've = = been testing FreeBSD? = = Correct. = = = Aside: why are you using cat under FreeBSD, but dd under Knoppix? I'd use dd = = everywhere for consistency. = = Cat was slightly faster in my tests on FreeBSD. I used dd under Knoppix for = dd's throughput reporting -- I'm not aware of a monitoring tool like `systat' = under Linux. = = Yours, = = -mi = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Mon, Mar 26, 2007 at 02:36:27PM -0400, Mikhail Teterin wrote: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. I can't reproduce the corruption you report. I run massive backups (7 levels; level 0 on Sunday, 1-6 on Mon-Sat) in our co-location facility and have always had success with restore(8). We use gzip -2 not bzip2, for what it's worth. The dumps are done over SSH. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). See below for some of my stats for comparison. As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! Let's compare numbers and devices, since I use SATA devices exclusively on my own home network, as well as in both of my production co-los. I'll use my home network for the below tests. Here's the SATA controller I'm using (on-board nVidia): atapci2: nVidia nForce CK804 SATA300 controller port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3001000-0xd3001fff irq 21 at device 8.0 on pci0 ata4: ATA channel 0 on atapci2 ata5: ATA channel 1 on atapci2 ad8: 190782MB WDC WD2000JD-00HBB0 08.02D08 at ata4-master SATA150 ad10: 476940MB Seagate ST3500630AS 3.AAD at ata5-master SATA300 The motherboard itself is an Asus A8N-E with an AMD Athlon 64 X2 3800+ in it. Kernel is built with SMP. No overclocking. Data taken from smartctl (ports/sysutils/smartmontools); I'm including this because it shows general information about the drives. === START OF INFORMATION SECTION === Model Family: Western Digital Caviar SE (Serial ATA) family Device Model: WDC WD2000JD-00HBB0 Serial Number:WD-WCAL73023909 Firmware Version: 08.02D08 User Capacity:200,049,647,616 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Mon Mar 26 11:47:50 2007 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3500630AS Serial Number:3QG00GQ7 Firmware Version: 3.AAD User Capacity:500,107,862,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Mon Mar 26 11:48:09 2007 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Filesystems: icarus# df -k Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ad8s1a 507630 6015040687013%/ devfs 1 1 0 100%/dev /dev/ad8s1d 16244334 45706 14899082 0%/var /dev/ad8s1e 16244334 920 14943868 0%/tmp /dev/ad8s1f 32494668 1307402 28587694 4%/usr /dev/ad8s1g115577350 1793544 104537618 2%/home procfs 4 4 0 100%/proc /dev/ad10s1d 473015558 121726480 31344783428%/storage devfs 1 1 0 100%/var/named/dev Pseudo-benchmarks: icarus# time dd if=/dev/ad8s1a of=/dev/null bs=1m 512+0 records in 512+0 records out 536870912 bytes transferred in 11.292704 secs (47541396 bytes/sec) icarus# time dd if=/dev/ad10s1d of=/dev/null bs=1m ^C6798+0 records in 6798+0 records out 7128219648 bytes transferred in 92.150703 secs (77353937 bytes/sec) 0.007u 1.319s 1:32.15 1.4% 27+2956k 0+0io 0pf+0w I consider these numbers pretty decent. The WD drive isn't performing as nice as I'd expect, but the Seagate drive definitely does. Adjusting the block size in dd doesn't make any difference; I've tried 16k, 32k, 64k, and 1m. There have been discussions in the past about using dd as a disk I/O tester on FreeBSD (vs. Linux), compared to a utility like bonnie++. Those may apply here, but I think your problem is elsewhere and not with dd on Linux vs. FreeBSD. :) Regarding interrupt
Re: pitiful performance of an SATA150 drive
Mikhail Teterin wrote: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... What HW was this again, there has been alot of updates/changes over the last year ? Could you try an up to date -current kernel on this, at least to get me a decent dmesg from ? If thats impossible take ATA from current modulus the busdma changes and use that on an up to date 6-stable. I cant tell what interrupts go where without a dmesg... Other than that, single bit/byte corruption are normally HW troubles of some kind, usually involving bad/incompatible memory or bad chipsets. However, if your drive has been overheated the media might have taken permanent damage that makes it loose data. What does SMART say on corrected errors etc (if the drive has that info). -Søren Please, advise. Thanks! -mi On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote: = On Wednesday 01 March 2006, Søren Schmidt wrote: = = dd if=/dev/ad8 of=/dev/null bs=1m = = Well, as I said, there is no obvious problems with _reading_. The above = command reads at well over 60Mb/s: = = 1638924288 bytes transferred in 25.374856 secs (64588516 bytes/sec) = = _Writing_, however, remains pathetic: = = dd of=/dev/ad8 if=/dev/zero bs=1m = 631242752 bytes transferred in 91.039066 secs (6933757 bytes/sec) = = = The problem is the blocksize that gets in the way of utilizing full = = transfer speed. = = Did you really expect the blocksize to make an order of (decimal) magnitude = difference? :-) It made no difference at all :-( = = Brian Candler asked: = = Just to be clear: this is Knoppix running on the *same* machine as you've = = been testing FreeBSD? = = Correct. = = = Aside: why are you using cat under FreeBSD, but dd under Knoppix? I'd use dd = = everywhere for consistency. = = Cat was slightly faster in my tests on FreeBSD. I used dd under Knoppix for = dd's throughput reporting -- I'm not aware of a monitoring tool like `systat' = under Linux. = = Yours, = = -mi = . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Monday 26 March 2007 15:21, Søren Schmidt wrote: = What HW was this again, there has been alot of updates/changes over the = last year ? It is now a quad core (dual CPU) Opteron-275 using IWill's DK8X motherboard. http://www.google.com/search?q=iwill+dk8x The SATA controller(s) are by LSI, not NVidia's (unlike in Jeremy's case). = Could you try an up to date -current kernel on this, at least to get me = a decent dmesg from ? Not easily -- this is my main machine... But _you_ have an account here :-). Try ssh-ing to [EMAIL PROTECTED] Your ssh key (same one you use on freefall) should work... = If thats impossible take ATA from current modulus the busdma changes and = use that on an up to date 6-stable. If you create a patch, I'll apply it, and rebuild/reboot, but I'm afraid to mess it up... Since I'm not using the drive most of the time (my regular work lives on the SCSI disks), I can even build ata and atadisk as modules, so you can try different changes without rebooting (umount, kldunload, kldload, mount). = I cant tell what interrupts go where without a dmesg... Attached. = Other than that, single bit/byte corruption are normally HW troubles of = some kind, usually involving bad/incompatible memory or bad chipsets. The system uses 4Gb of registered ECC memory and is quite stable in other respects... = However, if your drive has been overheated the media might have taken = permanent damage that makes it loose data. The highest temperature the drive has recorded is 63 Celsius. = What does SMART say on corrected errors etc (if the drive has that info). Attached. Thanks! Yours, -mi Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #1: Fri Mar 2 02:11:01 EST 2007 [EMAIL PROTECTED]:/meow/obj/var/src/sys/SILVER Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 275 (2205.01-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x20f12 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x3LAHF,CMP Cores per package: 2 real memory = 4865392640 (4640 MB) avail memory = 4133154816 (3941 MB) ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-23 on motherboard ioapic1 Version 1.1 irqs 24-27 on motherboard ioapic2 Version 1.1 irqs 28-31 on motherboard acpi0: A M I OEMXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: AMD 8151 AGP graphics tunnel at device 0.0 on pci0 agp0: 0x8000 bytes of rid 0x10 res 3 failed (0, 0x). device_attach: agp0 attach returned 12 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 drm0: ATI Radeon NG R300 FireGL X1 port 0x8000-0x80ff mem 0xf000-0xf7ff,0xde2f-0xde2f irq 16 at device 0.0 on pci1 info: [drm] Initialized radeon 1.25.0 20060524 pci1: display at device 0.1 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 6.0 on pci0 pci2: ACPI PCI bus on pcib2 ohci0: OHCI (generic) USB controller mem 0xde3fd000-0xde3fdfff irq 19 at device 0.0 on pci2 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: OHCI (generic) USB controller mem 0xde3fe000-0xde3fefff irq 19 at device 0.1 on pci2 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: OHCI (generic) USB controller on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ahc0: Adaptec 2940 Ultra SCSI adapter port 0x9800-0x98ff mem 0xde3ff000-0xde3f irq 16 at device 4.0 on pci2 ahc0: [GIANT-LOCKED] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs fwohci0: Texas Instruments TSB43AB22/A mem 0xde3fc800-0xde3fcfff,0xde3f8000-0xde3fbfff irq 18 at device 6.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:f0:12 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link
Re: pitiful performance of an SATA150 drive
Mikhail Teterin wrote: On Monday 26 March 2007 15:21, Søren Schmidt wrote: = What HW was this again, there has been alot of updates/changes over the = last year ? It is now a quad core (dual CPU) Opteron-275 using IWill's DK8X motherboard. http://www.google.com/search?q=iwill+dk8x The SATA controller(s) are by LSI, not NVidia's (unlike in Jeremy's case). Nopes its the stock AMD and a SiI chip.. Anyhow there has been some changes in that area that actually might fix an interrupt routing bogon. Please try the attached patch against an up to date 6-stable source and let me know if that helps... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Monday 26 March 2007 17:35, Søren Schmidt wrote: = Nopes its the stock AMD and a SiI chip.. Yes, that's correct. Sorry for the confusion. = Anyhow there has been some changes in that area that actually might fix = an interrupt routing bogon. Please try the attached patch against an up = to date 6-stable source and let me know if that helps... Ok, I'm certainly seeing improvement. The amount of ehci interrupts is down to hundreds (although still very high, considering, there is not USB activity). The disk's write throughput increased a little from 7.5Mb/s, and even spikes to 10Mb/s occasionally now, while averaging at about 8.3Mb/s. Curiously, the bandwidth appears BETTER (9Mb/s), when boinc (setiathome) IS RUNNING on all four cores... I'm running a compressed dump now to see, if the data corruption is still here. That said, it still sucks... The drive can read at the healthy 60Mb/s (and higher) -- I'd expect writing to average at least 20Mb/s, when recording a single stream. BTW, when I just got the drive 15 months ago, reading sucked too. But it improved over the period -- not sure, with which revision... Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Monday 26 March 2007 18:38, Mikhail Teterin wrote: = I'm running a compressed dump now to see, if the data corruption is still = here. Yes, it is still here. Although the dump/compression finished cleanly, the result is broken: # gzip -t /store/home.0.gz gzip: data stream error gzip: /store/home.0.gz: uncompress failed Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On 4/16/06, Mikhail Teterin [EMAIL PROTECTED] wrote: [Moved to -stable] On Sunday 16 April 2006 07:04, Søren Schmidt wrote: = I just tried this on a system as close to the one you have as possible You are welcome to visit my machine and take a look. Use the same ssh key as for the FreeBSD cluster and connect to aldan.algebra.com. = That makes me *seriously* doubt that ATA is at fault here... What else can it be? The main disks are SCSI and work well. The video sucks, but that's a problem common to many -- nobody can get their PCI-Radeons up with DRI. What else can be wrong? SATA HDD performance on my machine is less than stellar as well. The IRQ the SATA controller sits on is also given to the TI FireWire controller on my SB Audigy, and I haven't gotten around to putting that in a different slot and seeing if that changes anything. It would have been nice for PCs to have gone to a full 5 bits for IRQ instead of just hacking things up by adding 2^3 to the existing 2^4 as was done. Shared bus architectures, I spit on them all. Jamie Bowden -- It was half way to Rivendell when the drugs began to take hold Hunter S Tolkien Fear and Loathing in Barad Dur Iain Bowen [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
[Moved to -stable] On Sunday 16 April 2006 07:04, Søren Schmidt wrote: = I just tried this on a system as close to the one you have as possible You are welcome to visit my machine and take a look. Use the same ssh key as for the FreeBSD cluster and connect to aldan.algebra.com. = That makes me *seriously* doubt that ATA is at fault here... What else can it be? The main disks are SCSI and work well. The video sucks, but that's a problem common to many -- nobody can get their PCI-Radeons up with DRI. What else can be wrong? Thanks! Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
