olin_piclist@embedinc.com (Olin Lathrop) wrote:
> Dave Tweed wrote:
> > My guess is that this additional time (8.7 seconds) simply represents
> > the latency induced by the basic 1 ms USB frame period. Every
> > transaction will experience a delay that averages 0.5 ms, or half the
> > frame period.
> > I would estimate that the process you describe above requires about
> > 16k
> > to 17k individual messages back and forth to the EasyProg. Does that
> > sound about right?
> 
> There should have been at least 24K of them, plus a few extra, say around
> 25000.  Worst case you get one command and response per mS, but with the
> USB otherwise unloaded the driver is allowed to use remaining bandwidth
> to go back and allow devices that still have outstanding requests to use
> the bus again.  In this case, the USB to serial adapter was the only
> device using the USB at the time.  I imagine is uses bulk transfers,
> which would let it essentially have the whole USB bandwidth when no other
> device requests it.

It isn't quite that simple. The low-level packet scheduler (part of the
OS driver for the USB host chip) implements a strict 1 ms frame even
when there is only one device on the bus.

Now, it may be that outbound bulk transfers don't have to wait for a 1 ms
boundary, but the status request that tells the scheduler that there's
inbound data waiting in the device definitely does. So, if we only have
to account for latency on the inbound messages, that probably explains
the difference in time you saw. (12500 messages @ 0.7 ms each)

-- Dave Tweed
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist