Re: [Discuss-gnuradio] One question regarding "-B FUSB_BLOCK_SIZE" and "-N FUSB_NBLOCKS"

[Timothy Newman]

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