Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

[Josh Blum]

> Thanks a lot for the explanation.
> 

To explain your observations for the curious:

Prior to the fix, a recv buffer would be lost to the transport layer on
each timeout (thanks to an optimization I made earlier).

So, for every 100ms window (the default timeout) that did not have at
least 90 packets transmitted. A receive buffer was lost. After 32
timeouts, there were no more available buffers and the flow control
throttled back.

-Josh

answers below:

> When you say 90 packets, I assume that you mean UDP packets (which
> contain samples). Given the default MTU (1500-8-20)B and 2 samples per
> symbol as well as 4B per sample, for BPSK or GMSK, 90 packets of samples
> correspond to 90*1472/(2*4*8)=2070B of user data. If I use 1500B per
> user packet, that's less than 2 packets. For 700 UDP packets, that's
> about 10 user packets. This actually explains what I observed, after
> about 10 user packets, my transmission stopped. According to you, the
> host blocked first. However, it seemed that USRP didn't send back update
> packets for some reason--which is unusual. So it's likely timeout was
> called.  To help my understanding what caused the above behavior, would
> you please spend little time answering the following questions?
> 
> (1) Which parameter (*ups_per_fifo or **ups_per_sec*) corresponds to the
> above control parameter here (90 transmission packets and 700 packets
> update)? (2) How is the update packet generated on USRP?  (3) In normal
> cases, when the host transmits a packet, does it specify a transmission
> time for USRP? If so, it must get the clock of USRP first and then leave
> some margin, this introduce some time overhead; if not, does the USRP
> send whatever it receives immediately? (4) What's the content of the
> short update packet?
> 

1) ups_per_fifo

2) it counts the number of transmitted packets, and sends an update
packet every nth packet (default n = 90)

3) a transmission time is optional, when not specified the send is immediate

4) the sequence of the last transmitted packet

> Andrew
> 
> On 02/28/2011 05:58 PM, Josh Blum wrote:
>> A brief description on the flow control implementation:
>>
>> The flow control is only used on the transmit size to throttle the host
>> calls to send(). Update packets are received by the host every 90
>> transmitted packets. If the host does not get an update packet after
>> about 700 packets, the calls to send will block until the an update
>> packet arrives or timeout.
>>
>> This does not incur any overhead on receive. Update packets are small,
>> have their own dedicated udp port, and arrive infrequently. The overhead
>> on the transmit side is a check of the flow control condition per
>> packet. Which looks like this:
>> return seq_type(_last_seq_out -_last_seq_ack)<  _max_seqs_out;
>>
>> -josh
>>
>> On 02/28/2011 02:42 PM, Feng Andrew Ge wrote:
>>> Marc,
>>>
>>> Unfortunately I don't much experience  with Ethernet pause-frame flow
>>> control.  For my applications, sending is not an issue since we don't
>>> send high data rates; we are more concerned at the receiver side,
>>> particularly its latency (which is related to CPU consumption too.)
>>>
>>> Andrew
>>>
>>>
>>> On 02/28/2011 05:19 PM, Marc Epard wrote:
>>>> On Feb 28, 2011, at 3:54 PM, Feng Andrew Ge wrote:
>>>>
>>>>> Josh,
>>>>>
>>>>> I haven't found time to try what you suggested yet; however, it would
>>>>> be nice that the user has the option to choose host-side flow
>>>>> control.  In principle, I don't fully trust host-side flow control
>>>>> simply because there is too much uncertainty in a general-purpose
>>>>> processor (determined by both its hardware architecture and OS).
>>>>>
>>>>> Andrew
>>>> (We should probably move this to one of the public lists.)
>>>>
>>>> Andrew,
>>>>
>>>> How much experience do you have with Ethernet pause-frame flow
>>>> control? It caused us a bunch of problems and judging by the lists
>>>> over the last 8 months or so, it creates huge customer support
>>>> problems.
>>>>
>>>> -Marc
>>>>
> 
>