Re: [PATCH 2/2 v4] ehci: Respect IST when scheduling new split iTDs.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20 Oct 2009, Clemens Ladisch wrote:

> Steve Calfee wrote:
> > This is the problem. It completely violates the definition of
> > isochronous. Periodic endpoints are guaranteed bandwidth and
> > timeliness. There is no guarantee about delivery - in fact iso is not
> > guaranteed to be delivered safely at all. Inserting big gaps in a
> > transfer because of unrelated processor loads or chip bugs is wrong.
> > If an app needs guaranteed good data, it should not be using iso
> > transfers. An app that needs delivery guarantees should use bulk or
> > maybe high bandwidth interrupt transfers.
> > 
> > I think you should mark the missed transfers as failed and just skip
> > them. This would maintain the "chronous" aspect of the transfers.
> > Delaying 80 uframes means delaying up to 80*1024*3=245760 bytes that
> > were supposed to be timely on isochronous  transfers. FS audio delays
> > of 10 msec is very irritating and noticable.
> 
> For the audio drivers, throwing away some data is better than time-
> shifting.  With the current patch, the only way to implement correct
> behaviour would be for the driver to check the actual start frame after
> the URB has been submitted, and, if the HCD has introduced a gap, kill
> all URBs, throw away 10 ms of data, and resubmit the following data.
> 
> Furthermore, there are devices where multiple isochronous streams must
> be synchronized.
> 
> > Alan made a comment about excepting the ASAP scheduling, but since
> > that is the only practical scheduling method for applications, I think
> > all missed schedule windows should just be returned as "done" with an
> > error per iso packet transfer within the urb.
> 
> Or at least this behaviour should be selectable with a flag (ASAP or
> !ASAP or some new one).

I agree, this needs to be fixed.  But it is a separate issue, so it 
should be fixed in a separate patch.  Sarah, I can work out a patch 
that handles this first; then your IST can go on top of it.  How does 
that sound?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux