[USRP-users] questions about uhd-dpdk with n310

王盼 ruoyilei at 126.com
Sun Nov 3 21:53:35 EST 2019


Hello,
Sam Reiter. When leveraging dual 10GbE links,I  specify" addr=192.168.20.2,second_addr=192.168.10.2",last email I didn't give the example . The result is not much diffrent with use a single 10GbE link.
I think it is  "addr=<xxx.xxx.xxx.xxx>,second_addr=<xxx.xxx.xxx.xxx>" but not "addr0=<xxx.xxx.xxx.xxx>,addr1=<xxx.xxx.xxx.xxx>". when use  "addr0=<xxx.xxx.xxx.xxx>,addr1=<xxx.xxx.xxx.xxx>",I get errors:
[INFO] [MPMD] Initializing 3 device(s) in parallel with args: mgmt_addr0=192.168.2.230,type0=n3xx,product0=n310,serial0=316645B,claimed0=False,mgmt_addr1=192.168.2.230,type1=n3xx,product1=n310,serial1=316645B,claimed1=False,mgmt_addr2=192.168.2.230,type2=n3xx,product2=n310,serial2=316645B,claimed2=False,type=n3xx,mgmt_addr=192.168.2.230,addr1=192.168.10.2,addr2=192.168.20.2,master_clock_rate=122.88e6,use_dpdk=1
[ERROR] [RPC] Someone tried to claim this device again (From: 192.168.2.254)
[WARNING] [MPM.RPCServer] Someone tried to claim this device again (From: 192.168.2.254)
Error: RuntimeError: Error during RPC call to `claim'. Error message: Someone tried to claim this device again (From: 192.168.2.254)
root at seu73:/home/seu# 
On 11/2/2019 02:30,Sam Reiter<sam.reiter at ettus.com> wrote:
Panny Wang,


I notice that you're only specifying a single streaming address in your call to benchmark rate, implying that you're only leveraging a single 10GbE link. You can specify "addr0=<xxx.xxx.xxx.xxx>,addr1=<xxx.xxx.xxx.xxx>" in your device args.



Best,

Sam Reiter
SDR Applications Engineer
Ettus Research



On Wed, Oct 30, 2019 at 3:20 AM 王盼 via USRP-users <usrp-users at lists.ettus.com> wrote:

Hello,
 Nate.I want to use DPDK in UHD with N310 follow https://files.ettus.com/manual/page_dpdk.html,but the result is not satisfactory.I got you have some research about this from the user-list emails(With an i7-4790k / Intel x520-DA2 and N310, to stream at full duplex, over two channels at 125 MS/s, the lowest I can run my CPU clock freq at without flow control errors is 3.8 GHz using benchmark_rate and the native networking stack. Using DPDK I can run 2x2 @ 125 MS/s with my CPU freq locked at 1.5 GHz with no flow control errors. ).
May be you can do me a favor and have some idea about my quesion.
(1) I use benchmark_rate to test the streaming performance, I only got 122.88MS/s for 1channel, or 61.44MS/s for 2x2. run with 2x2 at 122.88MS/s , a lot of samples dropped. 
Unfortuately, my destination is 4x4 at 122.88MS/s. I don't know is it possible for my present host machine, or what configuration of host machine should have?
ubuntu server 18.04    uhd:3.14.1.1  dpdk 17.11.6   dual 10GbE links (XG image loaded)
host machine: 4 node, 8 cores in each node, tota 32 cores, cpu: Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz
more informations about my host machine is in the attchachment.(hypethread closed, cpufrequtils GOVERNOR="perfomance")
   --args "type=n3xx,mgmt_addr=192.168.1.104,addr=192.168.20.2,master_clock_rate=122.88e6,use_dpdk=1" \
   --duration 60 \
   --channels "0,1" \
   --rx_rate 122.88e6 \
   --rx_subdev "A:0 A:1" \
   --tx_rate 122.88e6 \
   --tx_subdev "A:0 A:1" 
   Benchmark rate summary:
     Num received samples:     2744145668
  Num dropped samples:      6030320380
  Num overruns detected:    921
  Num transmitted samples:  14684137560
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   67231
  Num late commands:        0
  Num timeouts (Tx):        0
  Num timeouts (Rx):        0


(2) In the  txrx_loopback_to_file test ,when I use the default --setting for 4*4channels, there is a error UUUUError: Receiver error ERROR_CODE_LATE_COMMAND .
I change it to --setting 1 ,it works.
I want to know the influence to my streaming or sample datas if 1 increase  --setting?
(--settling arg (=0.20000000000000001) settling time (seconds) before receiving)


Much appreciated.


Regards,
Panny Wang
 


_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20191104/1d1af630/attachment.html>


More information about the USRP-users mailing list