Dag wrote :
> 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
Well... It's more complex than it looks like...
The exact text is :
------------------------------------------
A USB IrDA Bridge device uses two bulk endpoints (one in and one out)
to exchange IrLAP frames between the host and an IrDA device. Thus,
the half duplex IrLAP protocol is actually transmitted over what
appears to be a full duplex communications channel. Due to this fact,
the USB IrDA Bridge device optimizes turn-around time between itself
and the IrDA device. IrLAP frames are exchanged based on USB bus
availability rather than forcing the USB driver client to track IrDA
device turn-around time.
------------------------------------------
The text is sufficiently vague to be interpreted in any way
you want.
If you look at the IrDA stack, it track only a single
turnaround time, which is the min of the tunraround of both end of the
link. No stack track the turnaround of only its own side of the
link. And it then says that USB frame are exchanged based on bus
availability, which would lead to interpret it that the stack should
not bother about *any* turnaround time.
But, you are free to interpret it in any way you want.
Now, let's go to practicalities :
1) In the kernel, we don't have any timer precise enough to do
this turnaround, except the busy loop, which is *very* bad for system
performance. Most other IrDA hardware help us for doing this timeout
by having special hardware support, but not the USB dongle.
2) USB has variable latency. The USB superframe occurs every
1ms, and if there is heavy traffic or high priority isoc, your bulk
USB transfer may be delayed by unspecified amount of time. In other
words, the USB round trip is between 2ms and a lot of ms.
3) It is *trivial* to do proper timing and buffering in the
dongle. Actually, the dongle has to do buffering because of USB
latency, and has to do precise timing because of XBOFS (or you can
generate a turnaround using XBOFS). What's missing is just a command
setting the turnaround in the dongle (just add another device
request).
4) It's not very difficult to snoop the "ua:rsp" and extract
the value of the turnaround. Of course, it's much cleaner to have a
explicit Device Request allowing the user space to control that.
5) If the dongle optimise only it's own turnaround as the spec
says, optimising the IrLAP turnaround just ammount to increasing this
turnaround value in some cases. Wow, doing an addition is probably too
difficult.
To me, it is beyond my imagination to *NOT* do the turnaround
in the dongle. It just make so much sense...
Dag : please forward this e-mail to whoever is in charge of
writing the IrDA-USB spec, so that we can add an optional explicit
"Set IrLAP Turnaround time" Device Request in the next spec. I'm
willing to contribute time to write the bit of spec needed.
Regards,
Jean
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
