Josh,
Before I test it with the raw ethernet driver, would you tell me what's
the difference in gr_uhd_usrp_sink between blocking send and
non-blocking send? Since the sending data is already in the buffer and
it is UDP sending, I don't see any difference. But perhaps you might
point out any
On 03/02/2011 07:37 AM, Feng Andrew Ge wrote:
> Josh,
>
> As predicted, changing from "RECV_MODE_FULL_BUFF" to
> "RECV_MODE_ONE_PACKET" and then "RECV_MODE_FULL_BUFF" reduced the
> latency significantly. My ping RTT time was >17ms in average, now it is
> 10.5ms. This is GREAT:-)
>
glad to hear
Josh,
As predicted, changing from "RECV_MODE_FULL_BUFF" to
"RECV_MODE_ONE_PACKET" and then "RECV_MODE_FULL_BUFF" reduced the
latency significantly. My ping RTT time was >17ms in average, now it is
10.5ms. This is GREAT:-)
Nonetheless, 10.5ms still includes quite some overhead because the
co
On 03/01/2011 04:39 PM, Feng Andrew Ge wrote:
> Josh,
>
> Your explanation makes sense. Is there a quick fix for me to bypass
> this problem temporarily while you are working on the modification.
>
http://gnuradio.org/cgit/jblum.git/commit/?id=75538e12300cb0d593792a986841ba2df9997c54
:-)
>
Josh,
Your explanation makes sense. Is there a quick fix for me to bypass
this problem temporarily while you are working on the modification.
Further, following your current bandwidth optimization implementation,
is the code trying to fill the buffer in both uhd_single_usrp_sink
(sending b
On 03/01/2011 03:25 PM, Feng Andrew Ge wrote:
> Josh,
>
> Everything is in the attachment, look for python-based UHD_* code.
>
> The performance before and after Feb.25 was both poor. At one point
> before Feb. 25, the latency was even worse, up to >30ms. But I forgot
> the time.
>
> In terms
On 03/01/2011 02:21 PM, Feng Andrew Ge wrote:
> Josh,
>
> First of all, I am aware of what you pointed out and I did use the code
> latency_test.cpp for measuring latency between USRP2 and a host. The
> latency is negligible.
>
Ok, i see. You were measuring the ping time over the tunnel. :-)
Josh,
First of all, I am aware of what you pointed out and I did use the code
latency_test.cpp for measuring latency between USRP2 and a host. The
latency is negligible.
I think I was not clear enough in my previous email.
My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The
On 03/01/2011 12:52 PM, Feng Andrew Ge wrote:
> Josh,
>
> That's great, thanks.
>
> When using UHD in GNU Radio, I observed huge time overhead: for example,
> using the raw_Ethernet code and 500kb/s, tunnel.py has only about 8 ms
> ping RTT time between two nodes; now with UHD, I have 17ms in a
Josh,
That's great, thanks.
When using UHD in GNU Radio, I observed huge time overhead: for example,
using the raw_Ethernet code and 500kb/s, tunnel.py has only about 8 ms
ping RTT time between two nodes; now with UHD, I have 17ms in average.
As I increase the ping payload, the overhead time
> 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 pa
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 use
On 02/28/2011 08:21 AM, Feng Andrew Ge wrote:
> Josh,
>
> Thanks for sharing the information and your changes sound quite reasonable.
>
> However, it seems that your changes have introduced some bugs at the
> transmitter side. I updated my system using your new code (following
> your instructio
> When you say "2x" performance increase, do you mean CPU performance or
> send()/recv() latency? Do you mind saying a few words on what changes
> you have made?
>
Much of the performance gains involved removing things out of the
fast-path that only needed to be called once at initialization (f
14 matches
Mail list logo
