[PATCH][RFC] usbatm.[ch]: cleanup and OAM F5 loopback

Roman Kagan rkagan at mail.ru
Fri Mar 11 16:05:46 EST 2005

On Fri, Mar 11, 2005 at 09:22:31PM +0100, matthieu castet wrote:
> Roman Kagan wrote:
> >Below is the patch to rearrange it a bit.  More specifically, it
> >
> > 1) removes the distinction between sending and receiving buffers, and
> >    sticks the buffer with the urb to serve it onto the struct
> >    usbatm_transceiver, which is to replace structs usbatm_receiver,
> >    usbatm_sender, usbatm_receive_buffer and usbatm_send_buffer;
> Arf, it will make very hard to support iso pipe

Umm, I forgot about that.  Although it shouldn't be too different to what
it was, I guess, I don't immediately see why it's going to become so
very hard.

Nonetheless please let me reiterate the question I asked a while ago: do
you have an indication that isochronous transfers are better for this
sort of workload?  I'd be surprised if they are.  They are meant for
constant rate data streams with no requirement for data integrity, like
audio or video.  ATM data, on the opposite, is typically variable rate,
and loosing data on the way from the modem to the host doesn't look

Please note that I'm just handwaving here; AFAIK SpeedTouch 330 has iso
endpoints too, but I'd be really interested to see if it helps a single
bit...  Maybe eagle-usb project has done some measurements?


More information about the Usbatm mailing list