Here's yet another patch (this will be the last tonight, I promise ;)
). It makes links with RNDIS framing named "rndis%d" instead of
"eth%d". This is a change that would be much appreciated by the SynCE
project, but it's perfectly understandable if you don't like it. :)
Cheers,
Ole André
On 12/16/06, Ole André Vadla Ravnås <[EMAIL PROTECTED]> wrote:
Here's another patch to be applied after the previous two. I have a
feeling you won't like it, but I'm sending it just for the record. It
makes rndis_host query the device for the MTU and update net->mtu etc.
accordingly. The Axim reports 8050, the Wizard reports 1500, so it
depends on the device what it's set to by default. (I haven't tried
changing the default, not sure if the OID is read-write.)
Doesn't seem to improve the IN performance much, but for OUT it
results in 269262 bytes/s instead of 244783 bytes/s, meaning a
performance boost of ~9%.
This is still only about 50% of the OUT performance delivered by the
Windows driver. My theory here is that this is because we don't batch
multiple packets per transfer and the devices are optimized for
infrequent big transfers instead of frequent smaller ones.
Ole André
On 12/16/06, Ole André Vadla Ravnås <[EMAIL PROTECTED]> wrote:
> Hi again,
>
> Here's two patches against the latest revision.
>
> The first patch restores the rx_urb_size, which makes my devices work
> again and results in quite acceptable performance for device to host
> transfers:
> $ pcp ":/My Documents/nightwish - angels fall first - angels fall
> first.mp3" "foo.mp3"
> File copy of 5385245 bytes took 0 minutes and 8 seconds, that's 673155
bytes/s.
> This is equivalent to the Windows driver, if not faster (the fastest I
> got there was 625 kB/s, though that was testing against an FTP server
> on the device instead of the native RPC API and thus not very
> scientifically correct).
>
> The second patch makes rndis_host work with PXA27x-based devices.
> (Time to open those champagne bottles! :D)
> The fix is simply not setting an alternate setting -- SET_INTERFACE
> makes these devices behave strangely ("hanging" the status and bulk
> endpoints), leaving this out makes it all work as it should.
>
> Cheers,
> Ole André
>
>
> On 12/16/06, Ole André Vadla Ravnås <[EMAIL PROTECTED]> wrote:
> > On 12/15/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > > On Wednesday 13 December 2006 2:17 pm, Ole André Vadla Ravnås wrote:
> > (...)
> > > > After debugging this issue further I discovered that RNDIS_MSG_INIT's
> > > > MaxTransferSize, sent by the host, is the value that
> > > > usbnet.rx_urb_size should be set to. If this is set to something lower
> > > > the device will (obviously) prepare larger URB payloads than what we
> > > > expect, and thus we'll fetch partial ones. This results in horrible
> > > > performance and makes the device stop responding after attempting a
> > > > few transfers.
> > > >
> > > > Patch (attached): linux-2.6.19-git-rndis_host-rx_usb_size-fix.patch
> > >
> > > This patch looks wrong. Instead, how about this theory: the peripheral
> > > is using the "pad with zeroes to end of packet" option on packets it
> > > sends, but the rndis_host code wasn't expecting that. The reason your
> > > patch worked was because it was creating HUGE rx buffers, which also
> > > coincidntally happened to allow that padding.
> > >
> > > I've updated the patch to allow padded RX buffers like that.
> >
> > Well, I tried with the revised patch and that seems to have broken it
> > completely.
> > My theory here is that the MaxTransferSize you specify in the
> > RNDIS_MSG_INIT is the maximum size you're able to read (IN) in one
> > transfer (one URB in the USB context). My devices here (HTC Wizard,
> > HTC TyTN and Dell Axim X51) all batch multiple RNDIS_MSG_PACKET
> > messages per transfer. So, what happens if you generate sufficient
> > traffic from the device to the host is that the device batches
> > multiple packets in each transfer, typically 13-14 kB worth of
> > packets. When you do one read with the buffer-size set to for instance
> > 8 kB, the device will (obviously) give you the first 8 kB, and the
> > rest in the next read. So, by stating 16 kB in MaxTransferSize we
> > oblige to have an rx buffer at least that big. And when sending URBs
> > to the device, we should never do bigger (OUT) transfers than what the
> > device reports as MaxTransferSize in the RNDIS_MSG_INIT reply.
> >
> > Ole André
> >
>
>
>
Index: usbnet.c
===================================================================
--- usbnet.c (revision 2707)
+++ usbnet.c (revision 2708)
@@ -1181,10 +1181,13 @@
// NOTE net->name still not usable ...
if (info->bind) {
status = info->bind (dev, udev);
- // heuristic: "usb%d" for links we know are two-host,
- // else "eth%d" when there's reasonable doubt. userspace
- // can rename the link if it knows better.
- if ((dev->driver_info->flags & FLAG_ETHER) != 0
+ // heuristic: "rndis%d" for links with RNDIS framing,
+ // "usb%d" for links we know are two-host, else "eth%d" when
+ // there's reasonable doubt. userspace can rename the link
+ // if it knows better.
+ if ((dev->driver_info->flags & FLAG_FRAMING_RN) != 0)
+ strcpy (net->name, "rndis%d");
+ else if ((dev->driver_info->flags & FLAG_ETHER) != 0
&& (net->dev_addr [0] & 0x02) == 0)
strcpy (net->name, "eth%d");
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
