Dear SangHyuk, please be aware that digital receivers aren't really easy to make more CPU efficient; a real-world receiver not only has to convert received symbols to bits, but has to do the frequency and frame synchronization as well as a timing recovery; high-bandwidth transceivers must go through significant amounts of equalization (OFDM is one way to approach this, converting one giant channel into a lot of narrow, hence, nearly flat, channels that can be single-tap equalized, at the expense of doing FFTs and inserting pilots/redundancy), too. The Benchmark_* tools aren't really doing anything to equalize (if I remember correctly), so they aren't really applicable to wideband channels, and if you do equalization, you'll probably be even slower. As said on numerous occassions, go ahead and try the rx_ofdm.grc and tx_ofdm.grc examples from gr-digital. They are much more modern.
If I had a diagnosis, still, your PC is probably simply too slow for receivers that aren't highly optimized; GNU Radio really does its best with efficient filter, FFT, synchronizer structures, but it might not be able to compensate that at 2.7GHz x 4 cores, you only have 432 CPU cycles per sample at 25MS/s, if your application was perfectly scalable (which it's not). That's not really much for a complicated receiver, if you consider that includes all the data handling (ie. getting data from the network card, converting it to something your CPU can deal with, writing the results somewhere), filtering, synchronization, channelizing (if doing *FDM), symbol decision, de-framing, channel decoding (no one would build a real-world transceiver without that), and as said, benchmark_rx (from the gr-digital/examples/ofdm directory, we're not talking about the narrowband one) isn't that optimally structured – it's really just a proof of concept. Best regards, Marcus On 07.04.2016 13:39, SangHyuk Kim wrote: > 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 > <mailto: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 :) > > $\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 <mailto: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
