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. So you’re not actually sending a full packet in that case, and
it will look like packet loss.
Tim
Bishal T. wrote:
observe the file using read_complex_binary and plot it in matlab, I
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
Dear Tim,
First of all, thanks for your time answering my question. Secondly, one
point you left out is: I am sending 104*128 bytes in reality, because I
am
spreading a packet of size 128 bytes with a 104 bits long spreading
sequence
right inside the pkt.py file in the
gnuradio-core/src/python/gnuradio/blk2imp/pkt.py location. Does not that
mean I am not running into the USB block-size issue?
Lastly, question to the list and for Tim also, what does -N and -B
options
in ./benchmark_tx.py script represent? It says it is the block size for
fast
usb option and number of fast usb blocks in the description, what does
this
mean? Please help me understand. Thank you.
Sincerely,
On Mon, Sep 28, 2009 at 1:50 PM, Bishal T. [email protected]
wrote:
Dear Tim,
First of all, thanks for your time answering my question. Secondly, one
point you left out is: I am sending 104*128 bytes in reality, because I am
spreading a packet of size 128 bytes with a 104 bits long spreading sequence
right inside the pkt.py file in the
gnuradio-core/src/python/gnuradio/blk2imp/pkt.py location. Does not that
mean I am not running into the USB block-size issue?
I do not believe you are running into USB block size issues. By
default, the Linux usrp implementation will submit to the kernel all
data passed to it in the write call.
Lastly, question to the list and for Tim also, what does -N and -B options
in ./benchmark_tx.py script represent? It says it is the block size for fast
usb option and number of fast usb blocks in the description, what does this
mean? Please help me understand. Thank you.
Loosely speaking, FUSB_BLOCK_SIZE and FUSB_NBLOCKS refer to the
individual size and number of outstanding asynchronous transfers that
can be submitted to the underlying USB interface. The defaults
(specified with 0) use operating system dependent values. For example,
for Linux the default block size is 16-kb, which is then broken up by
the kernel into 512-bytes payloads that are sent over the hi-speed USB
bus.
Other combinations are possible. These include values less than or
non-multiples of 512-bytes, but this results in poor use of limited
USB bandwidth and ineffective use of existing code based around
512-byte payloads. For most general use cases, the default values
should suffice.
Hope that helps.
–
Thomas