Re: [irda-users] Re: [RFT] stir4200 update

[Martin D. <li...@md...>]

On Tue, 2 Mar 2004, Stephen Hemminger wrote:

> > In general, I still believe the INT-urb would be better because it has 
> > guaranteed bandwidth on the bus - whereas with other devices and/or 
> > periodic traffic (audio/video) the low-priority bulk transfer might get 
> > very slow.
> 
> The problem (I think) is that the interrupt urb causes a behaviour where
> the data is not returned until it is idle for the interval (or buffer is full).
> So the trace with INT-urb is something like:
> 	4096 bytes
> +10ms   4096 bytes 
> +10ms   256 bytes (and data loss)

Ah, Ok. This means in FIR-mode the stir suddenly starts returning NAK 
instead of len=0 or is it just silent? Unfortunately I don't have a CATC 
to check it on the bus. But we mould need periodic intervals much shorter 
than 10 ms anyway, maybe even 2. But given it's pretty fast now with your 
current versions I'd say it's not worth the effort.

> 
> With bulk urb, we get:
> 	512 bytes
> +1ms	512 bytes

Do you really get the bulk-urb completed at 1ms period with only one urb?

> As an experiment tried isochronous but that just repeated the same data
> endlessly; since the device is not a real iso device.

Cannot work: for any FS device no ISO-EP can transfer more frequently then 
once per frame. So given the short (for ISO, for FS-BULK it is maximum 
possible) packet length=64 the max ISO-bandwith one could get from abusing 
the BULK EP for ISO is 64kb/s.

> > I take your other mail to understand we can rely on this, i.e. there is 
> > some guarantee, for a new allocated skb the skb->data will always be 
> > properly aligned and whatever is required for DMA? I'm not sure whether I 
> > missed the point why you are using a skb (instead of simple buffer) for 
> > the usb transfer, but if skb->data is aligned: just forget my comment ;-)
> > 
> 
> The new version just reuses the receive buffer for transmit and avoids all
> the socket allocation issues.

Ok, forget it - just saw your latest update has already changed it...

Martin