On Sun, Sep 30, 2001 at 11:07:19PM +0200, Martin Diehl wrote:
> On Fri, 28 Sep 2001, Jean Tourrilhes wrote:
>
> > Cleanup of the USB driver + the critical fix of last week.
>
> Hi Jean,
>
> as you might have noticed, I'm using the ACT-IR2000U as FIR peer device
> to test the vlsi_ir driver. I have it connected to usb-ohci (SiS onboard
> chipset). When I saw your patch to add USB_ZERO_PACKET support for
> usb-ohci on linux-usb-devel recently, I was wondering why I never
> experienced any problem.
Note : this affect only the *new* version of the USB driver
that was included in 2.4.10. The previous version used an horrible
kludge.
> I believe the reason is because with my tests it was pretty unlikely to
> hit the case where the zero-sized packet is required. With irlap-datasize
> 2048 the normal urb->transfer_length would be 2051 for example, due to
> the added irda-usb header and the irlap "A" and "C" fields. So my question
> is whether you could give me some pointer to special test cases which
> provide better coverage for paths like this, i.e. some way to control
> the raw packet size to test critical cases. Do you just use the MTU or
> some customized raw sockets?
I use the Ultra version of the eSquirt program. It send an
ultra packet of pretty much the size you want. For example, to send a
packet of 10 bytes :
> ultra_beacon 67890
You can check with irdadump, the packet is 10 bytes, therefore
the USB frame is 11 bytes. If you put enough number, you can trigger
the right case.
On top of that, I usually also do an Obex test (still using
eSquirt) and an IrNET test (netperf with both TCP and UDP).
> Another thing, I see some 8-10% gain in throughput when I completely
> disable the mtt-delay in the irda-usb driver. This should be ok, since
> irda-usb 1.0 spec requires the device to handle this by itself. My
> ACT-IR200U Rev 1.00 apparently does this well. So I'm wondering whether
> there are other devices requiring this or I might simply not have hit the
> case where it breaks (yes, I know, all the irda-usb dongles seem to
> violate the spec, at least wrt. when to apply speed changes...).
> However, I have not analyzed the USB traffic - chances are the 1 msec
> mtt-delay (sufficient for the OB800) is always achieved due to USB
> latencies, when the newly submitted URB will not be processed before the
> next USB frame starts. Comments?
mtt-delay is disabled by default in the *new* driver, and may
be re-enabled via the dongle option IUC_NO_TURN. I've been using the
new driver without the mtt-delay for more than 6 month with nsc-ircc
and irtty+actisys without any trouble (I mean, apart from the various
patches I sent to the list).
But I'm like you : I don't know...
> Martin
Have fun...
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
