On Mon, 1 Oct 2001 10:48:51 -0700, Jean Tourrilhes wrote: > 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.
The text only tries to tell you that you don't have to keep track of the current direction (turnaround) of the IrDA hardware as you have to do with other IrDA FIR chipsets where you explicitly have to tell if the hardware should be in Tx or Rx mode. You must however keep track of *when* to do the turnarounds yourself. > 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... No, because most stacks (including Linux-IrDA) optimizes the turnaround time, and will give away the token right away it if doesn't have anything data to send, and then back off if both sides doesn't have anything to send (FastRR's). Remember that the IrDA link doesn't turnaround at a fixed rate!! It's only a lower and upper bound. Even the stack doesn't know if or when it's going to send a frame. It only tries to make sure it doesn't happen before or after the min and max turn times. > 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. I agree that the dongle could help with handlingq the min. turnaround, and many other FIR chipsets does this. But it shouldn't do it automagically, since that would be over-engineering. Provice mechanisms, not policies!! They should be as high up in the system as possible. > Regards, > > Jean -- Dag -- 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
