Re: "aborting sbp2 command" expected in kernel.org FireWire maybe

Stefan Richter wrote:
> Mark Knecht wrote:
>
>> The common answer around here is that:
>>
>>1) The 2.4 series 1394 drivers work better than the 2.6 series drivers
>
>
> Actually, the 1394 drivers combined with the Linux scsi subsystem and
> other Linux facilities work more reliably in 2.4 than in 2.6. The
> unreliablity of kernel 2.6 appears to be not solely related to the 1394
> drivers. With respect to this, the 2.6 kernel line may be considered an
> 'odd numbered' line for the time being.

Humm...not sure I followed that, but I think we're in violent agreement...
>
>
>>2) The 1394 drivers have never been optimized for performance
>
>
> This is not completely true. There have been a few performance tweaks,
> especially in the earlier history of the 1394 drivers.

Well sure, but...
>
> But a *very* important optimization for throughput of asyncronous
> transactions (such as used by sbp2 and eth1394) is the so-called gap
> count optimization. This optimization is described in IEEE 1394a (and,
> with mistakes, in 1394-1995). It shortens certain idle times of the bus.
> Windows and apparently MacOS implement this optimization. Gap count
> optimization is obsolete for pure 1394b buses.

True - I had forgotten that aspect of the Linux 1394 stack. Too bad that
after 5 years of development we still don't set gap count...

>
> According to
> http://marc.theaimsgroup.com/?l=linux1394-devel&m=109128028930225 ,
> raw async bandwith of an S400 bus is about 27 MByte/s without
> optimization, and with gap count optimization on a short bus 44 MByte/s.
> This sounds enormous, but consider that 1394 bus bandwith is not the
> only limiting factor for real-life disk performance. On a reiserfs
> formatted 5400 RPM drive I measured
> 21 MByte/s write, 19 MByte/s read (sbp2 normal),
> 25 MByte/s write, 24 MByte/s read (sbp2 + gap count optimization),
> 32 MByte/s write, 30 MByte/s read (same disk on internal IDE),
> for block-wise read/write operations on large files. Performance
> differences for smaller files are much less pronounced. Of course, if a
> very fast disk & bridge or more than one device is used at the same time
> on a single S400 bus, the actual bus bandwith becomes more of a limiting
> factor.

I just plugged in my main 1394 audio drive I use for work with Pro Tools
under Windows XP. The performance wasn't great, but it did work and the
numbers are reasonable for what I'd need doing similar live audio
recording under Linux:

<SNIP>
ieee1394: Host added: ID:BUS[0-00:1023] GUID[413f0200b723013d]
ip1394: $Rev: 1224 $ Ben Collins <bcollins@debian.org>
ip1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
eth0: link up, 10Mbps, half-duplex, lpa 0x0000
ieee1394: Node added: ID:BUS[0-01:1023] GUID[0001d20000030fc1]
ieee1394: The root node is not cycle master capable; selecting a new
root node and resetting...
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
   Vendor: WDC WD40 Model: 0BB-32CXA0 Rev:
   Type: Direct-Access ANSI SCSI revision: 06
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
sda: asking for cache data failed
sda: assuming drive cache: write through
  /dev/scsi/host0/bus0/target0/lun0: p1
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
root@flash ~ #
<SNIP>

root@flash ~ # uname -a
Linux flash 2.6.8-gentoo-r2 #3 Fri Aug 27 11:05:03 PDT 2004 i686 Mobile
Intel(R) Pentium(R) 4 CPU 3.06GHz GenuineIntel GNU/Linux
root@flash ~ #

root@flash ~ # hdparm -tT /dev/sda1

/dev/sda1:
  Timing buffer-cache reads: 1680 MB in 2.00 seconds = 839.71 MB/sec
  Timing buffered disk reads: 56 MB in 3.16 seconds = 17.70 MB/sec
root@flash ~ #

Respectable for a 2 year old audio drive. FAT32/32K cluster sizes. Good
1394 drive case. (Ice Case)

- Mark

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user
Received on Thu Sep 2 20:29:51 2004