Thank you very much for being interested Mr Stern.
Here are answers to your questions:
What type are your transfers (bulk, interrupt, control)?
If they are interrupt, what is the period?
We are using bulk transfers.
What are the maxpacket values? What are the actual packet
sizes (you said some of them are 33 bytes)?
33 bytes is the max size of a packet according to our communication
protocol, has nothing to do with USB. Our USB driver buffers incoming
max-33-byte requests until a flush signal is received (which is
signalled every 2ms according to our design). Therefore, I guess,
USB HC splits the buffered data into transactions with 64byte payload,
adds necessary USB wrappers,and sends consecutive transactions to
target device controller within the same frame (since it's bulk mode).
The target firmware is designed such that it accepts a max of 512 byte
data as input, and sends a max of 1024 byte data stream as
output within a frame.
How many packets do you send in each frame? How many packets
do you receive in each frame?
The main loop of application sends a max of 15 write requests (each
write req includes 33 byte of data to write to device buffer in the
current frame, & 3 bytes of ACK response will be received in the
next frame) and 15 read requests (each read req includes 3 bytes
of data in current frame
that commands device to respond with 33 byte data in next frame).
For instance, the application sends a total of 15*(33+3) bytes in one
frame, receives 15*(33+3) bytes in next frame, and so on. Therefore,
the number of packets is kept at 30(15*2). It is important to
note that since we use a timer that flushes the buffer every 2ms,
above numbers are just an estimation. There may be less than
30*2 packets of data when a flush signal is received, or more.
When there is constantly more packets than a certain upper bound,
this causes an accumulation at the appropriate linked list of
application library. What we are trying to find is this upper bound
in terms of Mbps.
Is your external hub full speed (USB 1.1) or high speed (USB
2.0)?
It's a Digitus 7 port High speed hub(both 1.1 and 2.0 compatible).
By the way, I'm not sure about the internal hubs on my Pc, it's
just a guess that there are two HCs. The PC has two ports at the rear,
and two at the side, and I guess each pair is drived by a separate
UHCI HC, so that there are two HCs. If there is a way that I can
be sure about the internal hub details, please inform me.
Why don't you fix your kernel driver so that it doesn't leak
memory?
I explained what I mean by memory leak above. There is no leak at
kernel level, the leak is at the application level caused by the
accumulation of requests at the library linked list. This is not
a programatic error, it's just a sign of the situation that the
design cannot afford to communicate at the current bandwidth.
You should try looking at a usbmon trace to see what's really
happening.
I have never used it before because we already encode certain
checks such as sequence number check in the transmitted data
content. But I will also use it to monitor the trafic and let
you know results as soon as possible.
Thank you very much...
--------------------------------------------
- Show quoted text -
Hi everyone,
I am experiencing a weird situation in my USB based communication
test platform. Test platform is composed of:
- a user application statically linked to user level libraries
that handle basic communication with an external USB device (running
on a PC)
- a custom USB device driver that interfaces the application to the
external device (running on a PC)
- a firmware that receives requests from PC, and sends responses back
(running on a 8051 based Silabs F340 device)
The communication is carried out by the CPU sending requests and
receiving responses with a write system call, implemented by the
driver, and then simply copying received responses from kernel to
local application buffer with a read system call. So, only the
write call communicates with the external USB device, which involves
two urb submissions, one write and one read. Since the device
supports Full speed mode, this communication is continuously
initiated by the CPU every 2ms, which operates fine until the size
of transfer within a frame is increased to 6*33=198 bytes(6 packets
of 33 byte each). After that, the requests at the CPU application
start accumulating and memory leak is observed at the CPU in a linear
fashion, which is I guess something expected since the bandwidth
reserved for the device is limited. (This test achieves about
1.72Mbps communication when two way communication is considered,
where 6 "write to device" and 6 "read from device" requests are
initiated within frame, "write to device" occuring in first frame,
and "read from device" occuring in the next frame)
The weird situation is observed when more than one USB device
is used for communication at the same time. We tried connecting up
to 5 devices and a single device achieved up to 15*33=495 bytes of
transfer without any leak, where 15 is the maximum amount of packets
allowed in our own protocol within a frame (That makes about 4.3Mbps
per device). So 5 devices add up to more than 20Mbps.
1) Isn't it strange that accumulation of requests occur when one
evice is used for communication, whereas no accumulation is observed
with so many devices at the same time, consuming so much bandwidth?
2) How is it possible to add the total bandwidth in multi device test
to 20Mpbs? Doesn't USB controller assign 12Mpbs of bandwidth at Full
Speed? Is it possible that USB HC assigns 12Mpbs per each single
device connected?
Just one more detail, the PC has two internal hubs, which allow up
to 4 devices to be connected at the same time. For the 5 device case,
an external hub is used. But all tests, whether external hub is used
or not, give the same result that, HC looks to behave differently
in scenarios where a single device communication is involved, and a
multi device communication is involved.
--
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
