Hi If you are moving blocks of data ( = pictures / video ) out over the same basic USB interface. I suspect you will get into blocking issues. That sort of thing will make the basic “frame rate” stuff a bit less important. I have that same “gotcha” in what I’m doing. The network will be a bit busy while I’m also trying to sent time.
Bob > On Dec 5, 2019, at 2:21 PM, jimlux <[email protected]> wrote: > > On 12/5/19 5:16 AM, Bob kb8tq wrote: >> Hi >> One timing issue could be that USB is not that great for timing. Since it is >> packet based it introduces jitter in the link. Running NTP on a “traditional” >> RPi is unlikely to produce numbers below a milisecond. > > > USB only guarantees 125 microsecond timing (8kHz) - that's the basic "frame > rate" for isochronous channels, and was designed years ago to make it > possible to do telephone quality audio in real time. > > It might well be that USB 2 and USB 3 have shortened the timing windows as > well as increasing the speed, but I wouldn't be counting on it. One might > also have specific USB implementations that are better, but you're depending > on a "feature" of the chip, not part of the spec. I did see a mention on > wikipedia about some interrupt latency of about 1 microsecond in high speed > transfers, which is substantially better than the 125 microsecond frame > timing. > > There are people who claim to have low uncertainty USB timing. Fierce > electronics was one I found using google, but they appear to use custom USB > hubs. > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
