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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
