Dear Marcus,
I'm always appreciated your help.
I did ./benchmark_rate --rx_rate 25e6 and it worked well.
Then, I should make it simple.
Very thanks you!
2016-04-07 18:49 GMT+09:00 Marcus Müller <marcus.muel...@ettus.com>:
> 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
> :)
>
> [image: $\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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
