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? >> 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? -- Regards, Leonid -- 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
