The minimum usb block transfer size (FUSB_BLOCK_SIZE) is 512 bytes, so
while you may for example send 128 byte packets, the usb driver doesn't
push it over the bus until it gets 512 bytes or 4 -128 byte packets.
Theoretically if you're packet sizes are a multiple of the buffer size
then, I don't think this would be a problem, although you gonna have a
bursty packet reception. However, if for some reason your packet sizes
are not a multiple and smaller than the minimum block size, then you'll
have a fraction of a packet in a block, and the following block (with
the other fraction) may not get sent if the buffer doesnt fill all the
way up. So you're not actually sending a full packet in that case, and
it will look like packet loss.
Tim
Bishal Thapa wrote:
Dear Eric, Jonathan, List
I am stuck in a simple problem, and I am wondering if I understand
what "-B FUSB_BLOCK_SIZE" and "-N FUSB_NBLOCKS" options do, then it
MIGHT help a little bit.
I am using benchmark_tx.py to send a payload of size 102 bytes, but
with added header, CRC, padded "0x55"s it becomes exactly a 128 bytes
packet. I spread this message using DSSS of length 104 in pkt.py and
use interpolation rate of 256 and modulation dbpsk.
On the receiver side, I collect complex baseband samples using
usrp_rx_cfile capture with decimation rate of 128 into a file. When I
observe the file using read_complex_binary and plot it in matlab, I
only receive about 15 packets out of every 20 packets I send. Do you
think, this is because of the USB transfers 512 bytes at a time, or
simply the queues not being cleared out before the transmitter stops
the transmit program. I do put a time.sleep(1) between every packet to
make sure they are sent, which I actually do not like to do.
Nevertheless, after all this, still i do not see all my
packets/samples captured. Could you shed a little light on this
please, if you don't mind. I was thinking may be setting -N to 1 and
-B to 128 will help. But I promise I couldn't figure out what exactly
these options will do for me. Thank you.
Sincerely,
1.Transmitter command:
sudo ./benchmark_tx.py -f 2.4G -i 256 -m dbpsk
--from-file=102bytesofA.txt -c 20 [-N 1] [-B 128]
(-c: Added an option to represent the number of times benchmark_tx
will send the same packet)
2.Receiver command:
usrp_rx_cfile.py -f 2.4G -d 128 foo.dat
3.Analysis In matlab:
I observer plot(abs(read_complex_binary('foo.dat'))). Five packets are
missing on average. It is not consistent, sometimes its 10 sometimes
its 3.
The minimum usb block transfer size (FUSB_BLOCK_SIZE) is 512 bytes, so
while you may for example send 128 byte packets, the usb driver doesn't
push it over the bus until it gets 512 bytes or 4 -128 byte packets.
Theoretically if you're packet sizes are a multiple of the buffer size
then, I don't think this would be a problem, although you gonna have a
bursty packet reception. However, if for some reason your packet sizes
are not a multiple and smaller than the minimum block size, then you'll
have a fraction of a packet in a block, and the following block (with
the other fraction) may not get sent if the buffer doesnt fill all the
way up because you may be done sending packets, so you're left with a
partially full usb block buffer that isnt sent. You're not actually
sending a full packet in that case, and it will look like packet loss.
This is just a limitation of USB, I've seen others who've lowered the
minimum block size through various hacks, but the overhead when doing
this offsets the gains typically.
Tim
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
