Re: [Discuss-gnuradio] Rx overflow with high sample rate and high CPU ut

2016-04-07 18:49 GMT+09:00 Marcus Müller <address@hidden>:

Dear SangHyuk,

On 07.04.2016 08:25, SangHyuk Kim wrote:

Hi all,

I'm trying to solve Rx overflow problem.

I am using USRP N210 and CBX daughter board. As I know, my machine's maximum sample rate is up to 25 MSps.

No, that is the maximum number of 16bit complex samples you can get over Gigabit ethernet; I think I've done the math before, but here it goes again :)

$\frac{\SI{1}{\giga\bit\per\second}}{\SI{16}{\bit\per Integer}\text{[I]} + \SI{16}{\bit\per Integer}\text{[Q]}} = \frac{\SI{1e9}{\bit\per\second}}{\SI{32}{\bit\per S}}=\SI{31.25}{\mega S\per\second}$

and because the USRP can only give you integer fractions of its master clock rate 100MHz as sampling rate, 25MS/s is the maximum you get.

Yes, it works well at Tx (ex ./benchmark -f 2.5G -r 25000000).

However, when I use USRP to Rx mode (ex ./benchmark -f 2.5G -r 25000000), letter 'D' (overflow) be occurred.

Rx overflow 'D' is happened when host cannot consume packet fast enough.

... and that to a degree that the network stack, not UHD, decides to drop packets (not to "O"verflow). That is a very bad sign.

I observed incoming packet from USRP to host using wireshark tool.

Which will pose a significant additional load on your CPU, something that will influence your measurement.

After Rx command be launched (ex ./benchmark -f 2.5G -r 25000000), USRP sends many packet to host very fast.

Of course.

So, I checked cpu utilization at those moments. As a result, cpu utilization is over 200% (PC has 2.7GHz quad-cores). I couldn't believe it.

Why? How is that surprising? More than two cores under full load sounds like a reasonable load here.

However, I found "interrupt coalescing".

Incoming packet occurs interrupt to host and interrupt coalescing adjust how long/many packets make one interrupt to PC.

So, I changed these value using ethtool -C eth0 rx-usecs 1000 rx-frames 200.

But, it doesn't any effect for my case.

Well, then these values simply don't help; honestly, your PC is overwhelmed, and that not only by the interrupt load.

I'm using tg3 network driver and my setting like below:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes: 10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Link partner advertised link modes: 1000baseT/Half 1000baseT/Full
    Link partner advertised pause frame use: Transmit-only
    Link partner advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: on
    Supports Wake-on: g
    Wake-on: g
    Current message level: 0x000000ff (255)
                   drv probe link timer ifdown ifup rx_err tx_err
    Link detected: yes

Did I miss something ?

How can I solve Rx overflow problem at high sample rate ?

Does UHD's

benchmark_rate --rx_rate 25e6

work? If that's the case, the receiver flowgraph is simply too difficult for your PC to handle in real time. Nothing you can really do about that but get a faster PC, or design a less complex receiver.

Best regards,
Marcus

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

From:	SangHyuk Kim
Subject:	Re: [Discuss-gnuradio] Rx overflow with high sample rate and high CPU utilization
Date:	Thu, 7 Apr 2016 20:39:33 +0900