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

[Feng Andrew Ge]

Josh,

Thanks a lot for the explanation.

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?

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