Hi list.
I am tryint to get the maximum throughput using 2.0 dongles (anycom
USB-250). For my tests I wrote a program that opens a l2cap socket with a
second host and continuously writes a message of 1200 bytes. Befores opening
the socket connection I change the connection packet type to 3-DH5 with
hcitool utility. My kernel is 2.6.22-rc6 and I have just installed
bluez-utils-3.12 and bluez-libs-3.12.
I thought this environment would be enough for getting close to 3Mb/s of
transfering throughput, but I am just reaching a little over 1 Mb/s.
Does anyone ever tried something similar? Can anyone give some direction
about what I am missing?
Thanks in advance!
Loreno
Loreno Oliveira wrote:
> USB-250). For my tests I wrote a program that opens a l2cap socket with a
> second host and continuously writes a message of 1200 bytes.
1200 is a bad number.
1200 byte L2CAP payloads become 1204 bytes over the air. Multiple L2CAP
PDUs can not be aggregated into an air packet. 3-DH5 packets can hold
only 1021 bytes.
This means that, even in ideal circumstances, your payload will split into
one 1021 byte 3-DH5 packet and one 183 byte 2-DH3 packet. This will
take 10 slots to send (5+1+3+1).
So, the absolute best you could hope for is to send 1200 bytes in
6.25 ms. That's 1.5 Mbps.
> Befores opening
> the socket connection I change the connection packet type to 3-DH5 with
> hcitool utility.
This is generally a bad idea and is extremely bad in this case.
Now, even under ideal circumstances, the 183 byte trailer has to go into
a 3-DH5. You're now looking at 12 slots or 7.5 ms per L2CAP PDU. This
reduces your theoretical maximum data rate to 1.3 Mbps.
Make the following changes to your test.
* Increase your L2CAP PDU size to 2033 bytes (that's 2037 over the
air).
* Don't restrict the choice of packet types.
This should be optimal for real world throughput as 2037 not only splits
nicely into 1021 byte 3-DH5 packets but also splits nicely into 679 byte
2-DH5 packets. This means that when your link starts to degrade - as it
will do in the real world - your bandwidth will fall to 1.4 Mbps. If you
used, say, 1017 byte packets to get optimal 3-DH5 performance your 2-DH5
bandwidth would be worse.
Restricting to 3-DH5 in the real world is bad. 2-DH5 packets are much
more robust than 3-DH5 packets so when the link starts to degrade,
2-DH5 packets will give much higher bandwidth than 3-DH5. Note also that
you can't prevent the baseband from using DM1 packets so restricting you
may get worse results than you expect if the baseband decides that 3-DH5
packets aren't getting through and it needs to fall back. It'll have to
go all the way to DM1 packets which would be bad.
- Steven
--
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users