lkml.org 
[lkml]   [2006]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] New firewire stack - updated patches
Stefan Richter wrote:
...
>> And Windows Vista will drop the IP over 1394 functionality,
>> which is another data point about how widely used this standard is.
>
> If we cared what Windows supports or does not support, we would have gap
> count optimization by now, but no support of IEEE 1394b-2002.

Yeah, my point wasn't that we need to drop it because Windows dropped it, it
was just a data point backing up the claim that IP 1394 isn't very widely used.

And as for gap count optimization, I just added that to my git repo. I
thought about adding it before sending out these patches, but I was running
late on getting them out -- I ended up spending too much time chasing down a
stupid spinlock recursion. It is pretty simple to implement in the new stack,
since we have all the topology information available. I did a quick,
unscientific benchmark (md5summing 10 32M files) and the optimization is
definitely noticable. This is a setup where the box and the disk are both
connected to a hub so the max hops is 2, so we're using gap count 4:

real 0m10.021s
user 0m1.435s
sys 0m0.356s

compared to no optimization, ie gap count 63:

real 0m14.537s
user 0m1.390s
sys 0m0.402s

Though I see that Mac OS X uses a more conservative setting for a similiar
topology, so maybe we need to add a bit or "margin" to the numbers from the
table from 1394.

>> I'm not planning to port the pcilynx driver either. I think it's a sore
>> point for the old stack as it is - nobody uses it or tests it and it's
>> continously bit-rotting. So I'd rather not support it.
>
> Here I agree.
>
>> However, it can
>> perform as well as an OHCI card for SBP-2. If you set up a
>> self-modifying DMA program it can read and write system memory without
>> CPU intervention too.
>
> OK, I didn't know that although I suspected something like this might be
> possible. Of course this remains a potential feature as long as there is
> no manpower to actually implement it. (Nor is there a userbase to speak
> of to appreciate such an effort.)

Exactly. It's a cool hack (it's mentioned briefly in appendix E.1 of the
PCILynx functional specification) and it would be fun to make it work, but I
don't really see a userbase here. And if somebody has a PCILynx card and want
to use the new stack, I'll trade them for a OHCI controller :) I have a much
more useful way to put PCILynx cards to work using my firewire sniffer
(http://bitplanet.net/nosy).

cheers,
Kristian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-12-20 21:13    [W:0.053 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site