On Sun, 30 Sep 2001 23:07:19 +0200 (CEST), Martin Diehl wrote:

> 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?

The irda-usb spec is talking about the max. turnaround and the
half duplex nature of the IrLAP link, and why it uses two
endpoints (full duplex) for something which is half duplex
traffic. This is *very* different from, and has nothing to do
with the minimum turnaround time, and to imagine that the dongle
should handle the min. turn time itself is beyond my imagination.

There are 2 min turn times. 1) is the delay done by the irda-usb
driver when switching direction from receive to transmit (given
to us by the other device), and 2) is the mtt parameter we give
to the other device to inform it of the delay it should use when
doing the same thing. One will get better performance by
reducing both, but it could however make life hard for some
devices, and it could also limit the range. I'm not so sure it's
a good idea to distribute a driver which doesn't follow the IrDA
spec (I cannot see that the current driver cares about the mtt).
It's much better that people wanting a 10% performance increase
makes local changes. The problem with IrDA is usually not
related to performance. It's about working at all, and range.

But if things seems to work for people without using the delay,
then we should probably not use it, or limit it to lets say
500us-1ms since I agree that it's bad to busy wait in the
kernel. I just don't agree with the comment ;-)

-- Dag

> Martin 
> 
> _______________________________________________ 
> Linux-IrDA mailing list - [EMAIL PROTECTED] 
> http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda

-- 
Dag Brattli,                     Mail:  [EMAIL PROTECTED]
CEO, ObexCode AS                 Web:   http://www.obexcode.com
Tromsoe Science Park             Phone: +47 776 33 690 
Forskningsparken                 Fax:   +47 776 79 750
NO-9291 Tromsoe, NORWAY          Cell:  +47 481 06 352

_______________________________________________
Linux-IrDA mailing list  -  [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda

Reply via email to