On Tue, Jun 21, 2011 at 8:09 AM, Caleb Kemere <ckemere@xxxxxxxxx> wrote:
> It seems like a larger bufferSize yields more data transferred without
> overflowing the transmit buffer. I've been testing with 2MB, though
> I'd ideally like to make this (much) smaller in order to get lower
> latencies.
If you use synchronous API, the main way to help is to increase
the bufferSize but then there is a limit. After all, the internal buffer
of FTDI chips are limited (two buffers, each 512Bytes in the FIFO
mode, for FT2232H, even though the RX/TX buffer is 4KB). So if
the host fails to fire one USB IN request for 512B, you are still
fine but if the host fails to fire two USB IN requests, you are done.
If you use the async API, I believe the bufferSize can be reduced.
>> For this kind of application, it is better to use async API
>> and the device may need to have certain buffer if you can not
>> afford data lose. For example, if the PC for some reason
>> is not able to get some data from the device in one transfer,
>> then the device may need to have buffers for two transfer.
>> I think Uwe's advice to try the streaming API is good.
>
> My impression is that the FT2232H FIFO is already acting as a buffer
> in some sense, no?
>
> I'm planning to integrate this into a QT multithreaded application, so
> having this thread block on USB is ok. Is the async API more efficient
> in other ways?
Sync API may be easier to use in multithreaded applications.
However async API should help the performance though
by always having the USB IN request available from the PC host
side. It is probably more difficult to use the async API with
a multithreaded application but it should push the performance
up with both (async API + a separate polling thread to check
transfer complete).
But I am not an expert in multi-threading applications.
Michael Plante and Uwe may help you better here.
The latest fid2xx 1.04 library under Linux is also based on libusb-1.0
just like libftdi-1.0. I believe it use async API and internal threads
to handle asynchronous events (read/write and read/write completion)
as well but I do not know the details.
>> The USB host USB driver and system performance have some
>> effect on the bulk transfer performance. As mentioned before,
>> bulk transfer is a best effort kind of delivery, the bandwidth is
>> not guaranteed, So different host system may schedule
>> different number of packets in a microframe (125 us for
>> high speed USB) which result in different speed. Slower
>> system (or slower USB host controller) may be prone to
>> drop a transfer as well.
>
> It must be that the USB host controller on my laptop is deficient. It
> can't be *that* bad, though, or it would not work at all, so I'm still
> curious if there's something I could do to help it.
Plug out all USB device not necessary to reduce bus activity.
Check the system latency as well. But I believe aysnc API
should help.
Reading this AN should help as well. It is talking about the FTDI driver
but the basic is the same using libftdi/libusb.
http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-03_D2XXDataThroughput.pdf
"When a device is opened, the driver allocates two buffers: a USB transfer
buffer of maximum USB transfer size bytes and a read buffer whose size is
based on, but not the same as, the maximum USB transfer size. The current
USB transfer size is set by default to 4Kbytes, but an application may setup
the current USB transfer size anytime after a device has been opened.
The driver
performs USB requests of any size up to the current USB transfer size,
then copies
the data to the read buffer. The actual USB request size is determined
by the space
that is currently available in the read buffer. If the read buffer
becomes full (i.e. there
is not enough space in the read buffer to hold data returned from a
USB request),
the driver will stop issuing USB requests until space becomes available.
Data is removed from the read buffer when the application performs a read
request. So the rate at which the application issues read requests has a
direct bearing on the driver's ability to keep issuing USB requests. USB
requests will continue to be issued as long as the application performs
enough read requests to ensure that the read buffer does not become full."
The following two AN may help as well.
http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf
(not updated for high speed FTDI device yet).
http://www.ftdichip.com/Support/Documents/AppNotes/AN_130_FT2232H_Used_In_FT245%20Synchronous%20FIFO%20Mode.pdf
--
Xiaofan
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
