On Thu, 21 May 2009, Leonid Lisovskiy wrote: > On Tue, 20 May 2009, Alan Stern wrote: > > >> I discover that new TT scheduler don't allow transfers longer than 780uS > >> (see max_tt_usecs[] in ehci-sched.c) or approx. 1000 bytes as > calculated in > >> iso_stream_init() for full speed isoc transfer. But, as I can understand > >> from usb 2.0 documentation, limit for full speed isoc transfer is 1023 > >> bytes as of table 5-4 sec 5.6.3. and it take approx. 806 uS > > > > That time includes bit-stuffing. Without bit-stuffing the value would > > be 692 us or so. > > Thanks, I miss this. > > >> Can somebody explain scheduler limitation of 780 uS? Is it 78% of 1000 > >> uS (8 microframes) or 89% of 875 uS (8 microframes minus SOF)? > > > > I'm not certain (since I didn't write the code), but I think 780 is a > > bad estimate of: 1000 us * 90% * (6/7). The (6/7) factor was put in to > > account for bit-stuffing, by mistake. If you do the calculation, the > > actual value would be 771, not 780, so maybe this guess is wrong. > > If I understand you correctly, we should change calculation of > stream->tt_usecs in iso_stream_init() to not include bit-stuffing, or take > it(bit-stuffing) into account in the scheduler itself, right? Yes, except that the scheduler is wrong in some other fundamental respects, so it should be changed extensively. It needs to implement the scheme described in section 11.18 of the USB spec. Fixing this one calculation won't be enough. > >> Why old scheduler allow 1023 bytes full speed isoc transfer but new one > >> forbid this?? > > > > Because the new scheduler has bugs. You found one of them. > > Usually, the software has bugs ;-) Can you assist to repair this bug? I'm working on it. It's a difficult job and it will take a while. 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
