Help with slow Firewire Transfers
 

Hello!

I have a external Firewire enclosure which I have fitted with a Barracuda ATA Hard disk.

The issue I am having is to do with transfer speed. When in the firewire enclosure, the drive cannot go higher then 9MB/s. While if I install it in my PC (using the PATA interface) The drive does 45MB/s easily.

I tried a selection of drives, from maxtors to seagates and others. None of them can do more than 9MB/s transfer rate when in the firewire enclosure. Now one thing I came across is if I disable DMA when the drive is connected to the PATA interface, the max speed for all the drives is also 9MB/s.

Anyone have any idea why? It would look to me as if the drive's DMA is not enabled when in the firewire enclosure. but I have no idea how to enable firewire DMA. hdparm is rather useless when the disk is in the firewire enclosure (the disk then appears as a SCSI disk, sda).

I believe my firewire card is 400Mb/s. that should be able to do more than 9MB/s (and it would be nice, as I need it to be fast as I run vmware images from it). This is also my first experience with firewire, so any help is appreciated :)



Some stats:

OS: Gentoo linux 2007.0
Kern: 2.6.20-gentoo-r8
CPU: AMD XP (Athlon 4) 1.2GHz
Mem: 768MB PC133

lspci:

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:08.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link)
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74)
00:0b.0 RAID bus controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller (rev 02)
00:0d.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:0d.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)
00:0f.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
00:0f.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
00:11.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000] (rev a4)

dmesg from connecting enclosure (I had my usb drive connected, so the enclosure is sdb in this case):

ieee1394: Error parsing configrom for node 0-01:1023
ieee1394: Node changed: 0-01:1023 -> 0-02:1023
ieee1394: sbp2: Reconnected to SBP-2 device
ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - Max payload [2048]
ieee1394: Node added: ID:BUS[0-01:1023] GUID[0001a3000005526a]
ieee1394: sbp2: Reconnected to SBP-2 device
ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - Max payload [2048]
scsi2 : SBP-2 IEEE-1394
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node 0-01:1023: Max speed [S400] - Max payload [2048]
scsi 2:0:0:0: Direct-Access ST340016 A 0.01 PQ: 0 ANSI: 0
SCSI device sdb: 78165360 512-byte hdwr sectors (40021 MB)
sdb: Write Protect is off
sdb: Mode Sense: 03 00 00 00
sdb: got wrong page
sdb: assuming drive cache: write through
SCSI device sdb: 78165360 512-byte hdwr sectors (40021 MB)
sdb: Write Protect is off
sdb: Mode Sense: 03 00 00 00
sdb: got wrong page
sdb: assuming drive cache: write through
sdb: sdb1
sd 2:0:0:0: Attached scsi disk sdb
sd 2:0:0:0: Attached scsi generic sg2 type 0



Any help appreciated! And if you need any more info just let me know :)

Thanks!

Properly configuring the drive in an external enclosure is the job of the firmware on the interface chip in the enclosure (or rarely jumpers on the interface board in the enclosure). Check with your enclosure manufacturer for a firmware update.

Well, I checked but there are no jumpers on the interface board.

Ok, I checked and I updated the enclosure with the newest firmware available. Still not much luck, I am getting the same performance.

but as I had to boot into windows. I thought I'd test out the drive in windows. I got about 25MB/s on the transfer test. This makes me think that the problem is with the linux sbp2 driver.


Browsing around the web I came across this:

http://osdir.com/ml/linux.kernel.fir.../msg00108.html

which sounds a lot like what I am having, but I didn't understand much of it, and neither was there a fix presented.

Also I found out my chipset. It is a GL711FW (just like in the link), which seems a pretty common chipset and follows the ieee1394a (400mbit/s) standard.

You can try adding the following to /etc/modprobe.conf:

options sbp2 serialize_io=0

For some chipsets, this can cause stability problems, so the default is to serialize I/O. After making the change:

- umount any firewire drives
- modprobe -r sbp2
- modprobe sbp2
- remount the drives

Alternatively, you can just reboot.

Ok. I tried it. It gives me a little speed boost (the transfer rate hovers between 10 and 11MB/s), but after a short time hdparm locks up, and dmesg prints loads of these errors:

These just keep being repeated. And I can't close the program (hdparm) unless I physically turn off the firewire device.

Then your only option is to wait until the new Firewire stack in the kernel is stabilized. If you want to try it in it's current state, you can download a distribution like the FC7 LiveCD, which includes it.

Thanks for the tip. Where could I get the new firewire stack? Would it be in the most recent kernel.org dev tree, or would I need to patch it from somewhere else

I will try the FC7 liveCD, but I would also like to apply the new kernel to my current gentoo installation. The only reason I am hesitant to go the LiveCD route is that the only CD Drive I have is firewire and my PC can't boot from firewire drives (gaining access to my PC is a real difficulty).

It's in the -mm kernel, or you can get it from the git repo as described here at KernelTrap.