I'm puzzled about this thread. As I understand the discussion, seems that someone is using an interrupt out for a small amount of data and, for some unknown reason, the last data packet is being resent on each "interrupt" interval. If this is the case, then I'm pretty sure that it isn't supposed to work this way unless the target endpoint is "misbehaving". If the target ACK's all the data, then both UHCI and OHCI will retire the associated descriptor and, if nothing further is queued to the endpoint, there will be no traffic to that endpoint on the next interrupt interval (interval is endpoint specific). If the endpoint has a problem and decides to NAK the last data (endpoint might not properly deal with a last packet that is shorter than MAX_PACKET_SIZE), then both UCHI and OHCI will retry that packet, ad nauseam.
So, if the hardware is working correctly, the only thing that should cause the last packet to be resent is if the driver has made a mistake. BTW, the purpose of the interrupt endpoint is to provide guaranteed latency. When combined with an allowed packet size, this just happens to give guaranteed bandwidth. However, because of the possibility of errors and retries, the bandwidth is not the guaranteed throughput but simply a guarantee of access to bandwidth. David Wooten > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf > Of Vojtech Pavlik > Sent: Tuesday, February 19, 2002 3:50 AM > To: David Brownell > Cc: Roland King; Simon Gittins; [EMAIL PROTECTED] > Subject: Re: [linux-usb-devel] stopping interrupt transfers.. > > > On Tue, Feb 19, 2002 at 02:59:28AM -0800, David Brownell wrote: > > > By the host controller driver. It's a "periodic" transfer, > > which _by design_ is going to be happening over and > > over and over again. > > Which is a problem. All uses of interrupt out I have met don't need to > be periodic - they're used for example in HID if the device has an > output interrupt endpoint for sending output reports, and for I-Force > devices to send outgoing data. > > However the nature of the data isn't periodic at all. > > > > > How is that supposed to work with output transfers then? If you > > > > schedule an interrupt transfer and the driver continues > to resubmit > > > > it, doesn't that just mean that, as the initial writer > in this thread > > > > noted, you get the same data sent to the endpoint again > and again? > > > > Yes, which is why an interrupt OUT transfer has to modify > the buffer. > > > > And why there's that issue I mentioned (reported in Janary by > > Wolfgang Mües) about changing the _length_ of an OUT transfer. > > I've some comments I hope to send out, but can't do so much before > > Wednesday. > > It would work if most of the time the interrupt OUT URB could have a > transfer_length of 0 bytes of data, but I'm not surw which HCDs will > choke on that. > > > > > What are interrupt outputs supposed to do? If you have just one > > > > thing to send are you better off always just sending a > bulk one even > > > > to an interrupt endpoint? > > > > "Better off" is a tradeoff. One factor is guaranteed bandwidth: > > > > > As far as I know the only difference between one-shot out > interrupt > > > > (which is a UHCI-ism :) > > But that's only a driver issue. I don't believe OHCI/EHCI in hardware > wouldn't be able to implement oneshot interrupt transfers. I may be > wrong here, though. > > > Another factor is when the transfer happens ... if your device is > > only able to handle data every 16 msec, you're not doing anyone > > a favor by trying to send/recv it more often, it'll just > choke. So use > > interrupt transfers, not bulk transfers. > > If there is such a device, yes. > > > Then there's the fact that the transfer sizes are different. For > > high speed (480 MBit/sec) interrupts max out at 64 bytes by > > default, but single transfers go up to 1KByte and there's also > > a "high bandwidth" mode where one endpoint can do 3KBytes > > in each microframe (12 KByte/msec, 12 MByte/sec). Bulk > > maxpacketsize at High speed is fixed at 512 bytes. > > Of course, if you stick to the interrupt transfer inflicted sizes, you > aren't going to cause problems by using bulk instead. > > -- > Vojtech Pavlik > SuSE Labs > > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
