Re: [USRP-users] warning on UDP buffer size when using Python API
Hi, On Fri, Sep 22, 2017 at 08:38:32PM +, Osvaldo Alcala (Ozzie) wrote: > Thank you. I should have said that I did try the command that shows in the > screenshot, but the required buffer size keeps changing: thus I get the same > error every time. So maybe in your script/application you have increasing buffer sizes and thus the uhd send()/recv() calls try to send bigger buffers? But that's just guessing. An explanation what you are trying to do with the Python API would be helpful, so the root cause (either in UHD or your application can be identified) Cheers, Andrej -- Andrej Rode GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA signature.asc Description: Digital signature ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] warning on UDP buffer size when using Python API
Thank you. I should have said that I did try the command that shows in the screenshot, but the required buffer size keeps changing: thus I get the same error every time. Thanks Oz -Original Message- From: Andrej Rode [mailto:m...@andrejro.de] Sent: Friday, September 22, 2017 12:15 PM To: Osvaldo Alcala (Ozzie) Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] warning on UDP buffer size when using Python API Hi, On Fri, Sep 22, 2017 at 02:12:06AM +, Osvaldo Alcala (Ozzie) via USRP-users wrote: > Hi, I'm running with the Python API and I keep getting the following warning > (see pic below). I go ahead and change the buffer size per the command > listed, but I still get the warning again with different numbers. > > Is this normal? Will it cause any data loss? Anyway to fix? Actually, your screenshot already contains suggestions for a fix. Running `sysctl -w net.core.wmem_max=` and `sysctl -w net.core.rmem_max=` with the suggested values will size the send/recv buffers of your udp transport accordingly. AFAIK this is not closely related to the Python API, bit might be triggered by huge buffers passed into the python send/recv call? Cheers, Andrej -- Andrej Rode GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] C674 fail on B210 rev 4
Hi Billy. C674 is Kemet T495C107K016ATE200 CAP,SM,100UF,16V,10%,TANTALUM,6032. Schematics for the B210 are available here: http://files.ettus.com/schematics/b200/b210.pdf -Robin On Fri, Sep 22, 2017 at 8:23 PM, Billy Jones via USRP-users < usrp-users@lists.ettus.com> wrote: > I have been using a B210 board for about a week now to run OpenBTS and > OpenBTS-UMTS. I left the board powered on in its enclosure overnight, and > when I arrived in the morning discovered it not working, the power led > flickering, and my computer alerting that there was a USB power surge. I > took the board out of its enclosure and discovered capacitor C674 had > completely burned up. > > Has anyone else encountered a hardware failure as catastrophic as this > with the power supply? > > Does anyone know the specs on that capacitor (capacitance, voltage rating, > etc.) so I can possibly replace it on the board myself? > > I'm using Rev 4 of the B210, and I have a GPSDO-TCXO module installed. I > was using a 9V, 1.5A wall wart as the power supply and had the USB3 cable > connected to my PC. > > Thanks, > Billy > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] C674 fail on B210 rev 4
I have been using a B210 board for about a week now to run OpenBTS and OpenBTS-UMTS. I left the board powered on in its enclosure overnight, and when I arrived in the morning discovered it not working, the power led flickering, and my computer alerting that there was a USB power surge. I took the board out of its enclosure and discovered capacitor C674 had completely burned up. Has anyone else encountered a hardware failure as catastrophic as this with the power supply? Does anyone know the specs on that capacitor (capacitance, voltage rating, etc.) so I can possibly replace it on the board myself? I'm using Rev 4 of the B210, and I have a GPSDO-TCXO module installed. I was using a 9V, 1.5A wall wart as the power supply and had the USB3 cable connected to my PC. Thanks, Billy ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] warning on UDP buffer size when using Python API
Hi, On Fri, Sep 22, 2017 at 02:12:06AM +, Osvaldo Alcala (Ozzie) via USRP-users wrote: > Hi, I'm running with the Python API and I keep getting the following warning > (see pic below). I go ahead and change the buffer size per the command > listed, but I still get the warning again with different numbers. > > Is this normal? Will it cause any data loss? Anyway to fix? Actually, your screenshot already contains suggestions for a fix. Running `sysctl -w net.core.wmem_max=` and `sysctl -w net.core.rmem_max=` with the suggested values will size the send/recv buffers of your udp transport accordingly. AFAIK this is not closely related to the Python API, bit might be triggered by huge buffers passed into the python send/recv call? Cheers, Andrej -- Andrej Rode GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA signature.asc Description: Digital signature ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] warning on UDP buffer size when using Python API
Dear Oz, what's the different numbers you get? Also note that it's actually easier for us to read when you just copy and paste the text instead of making a screenshot. Thanks! Best regards, Marcus On 09/21/2017 07:12 PM, Osvaldo Alcala (Ozzie) via USRP-users wrote: > > Hi, I’m running with the Python API and I keep getting the following > warning (see pic below). I go ahead and change the buffer size per the > command listed, but I still get the warning again with different numbers. > > > > Is this normal? Will it cause any data loss? Anyway to fix? > > > > Thanks! > > > > Oz > > > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] High CPU load on UHD driver and Ether ISR
Dear Kobayashi-san, You want to make sure the size of the network packets is as large as possible to reduce overhead; UHD will print out the information of how many bytes are in a single packet during initialization. You might need to tell Linux that it needs to use a larger MTU (8000B should work fine). It is also often relatively helpful to set the interrupt coalescing properties of your network card. That way, your CPU won't be buried under a torrent of interrupts, but Linux will instead poll the card for data (which almost always will be there), which is much more effective in this use case. You can modify these settings using `ethtool -C`; see `man ethtool` for more details. Paul's application note [1] also illustrates how to increase the number of descriptor rings. The idea is that a network card places packets in a ring of buffers, and the OS takes the "oldest" one of these, and processes it. The more rings you have, the better the card can balance the load itself, as a rule of thumb. Best regards, Marcus [1] https://kb.ettus.com/Using_Dual_10_Gigabit_Ethernet_on_the_USRP_X300/X310 On 09/21/2017 07:14 PM, Kobayashi, Noboru via USRP-users wrote: > Hi, all > > I'm working in a LTE related system using Ettus X310, using UHD driver > on CentOS 7.3 base real-time kernel patched environment. > UHD driver version using is 3.9.6 > > Current master clock frequency is 184.32MHz, and sampling rate is > 30.72MHz. 2 RX/TX antennas are used with 16bit I/Q interface. > UDP transmission rate is about 2.3Gbps for UL/DL each. > 10Gb Ether port is used. > >UHD driver's CPU load is very high, almost 90% for RX side and > 80% for TX side of one core ,Intel(R) Xeon(R) CPU E5-2687W v4 @ 3.00GHz. > Dedicated two cores are used just for UHD driver. (I'm isolating CPU cores > using boot parameter. (grub)) >And Ethernet ISR drivers load is also high, up to 70%. > One more dedicated core is required for ISR. (IRQ affinity is used) > Totally, three cores are used just for interfacing USRP. > >Is the CPU load of three core for USRP interface under above condition, > reasonable ? >I want to reduce CPU core counts for USRP interface. > >Is there any way to reduce the CPU load ? > > > Best Regards, > Noboru KOBAYASHI > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Phase jumps in USRP B210 with GPSDO
Hi Sylvain, W dniu 22.09.2017 o 11:44, Sylvain Munaut pisze: > Hi Piotr, > > > And do you set both the Clock and Time source to the external ones > when using it in that configuration ? I think I have written this at least twice before. I will try again to describe it again as clear as I can. Recipe to reproduce the problem: 1. take a USRP B210 with GPSDO inside, 2. connect external source (i.e. Octoclock-G) of PPS and 10MHz ref to it, 3. set sources of PPS and 10MHz ref to "external", 4. record sinusoid, 5. look at the sinusoid's phase (one simple solution is to uwrap phase, fit first order polynomial to it and remove it from the original). > I just had a look at both the schematic and VHDL and there is actual > switches ... the GPSDO 10M and PPS should basically be completely > disconnected when the reference for time and clock is external. I suppose they are not enough. Anyway problem with combo of USRP B210 equipped with GPSDO and Octoclock-G was confirmed yesterday by mixbit on usrp-users list (he said they have it in their bug tracker). > Also, are you using an external power supply ? Maybe the issue is the > added load on the supply rails when the GPSDO is plugged in. > External supply doesn't help. Only removing GPSDO from USRP B210 helps. Which is not bad. p.s. Now we are fighting with frequency offset between two USRPs B210 synchronized with octoclock. It causes phase drift of about 1 degree/second, and changes with time. When I will know more I will describe it in a new thread on the mailing list. Best Regards, Piotr Krysik ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Phase jumps in USRP B210 with GPSDO
Hi Piotr, And do you set both the Clock and Time source to the external ones when using it in that configuration ? I just had a look at both the schematic and VHDL and there is actual switches ... the GPSDO 10M and PPS should basically be completely disconnected when the reference for time and clock is external. Also, are you using an external power supply ? Maybe the issue is the added load on the supply rails when the GPSDO is plugged in. Cheers, Sylvain ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] High CPU load on UHD driver and Ether ISR
Hi, all I'm working in a LTE related system using Ettus X310, using UHD driver on CentOS 7.3 base real-time kernel patched environment. UHD driver version using is 3.9.6 Current master clock frequency is 184.32MHz, and sampling rate is 30.72MHz. 2 RX/TX antennas are used with 16bit I/Q interface. UDP transmission rate is about 2.3Gbps for UL/DL each. 10Gb Ether port is used. UHD driver's CPU load is very high, almost 90% for RX side and 80% for TX side of one core ,Intel(R) Xeon(R) CPU E5-2687W v4 @ 3.00GHz. Dedicated two cores are used just for UHD driver. (I'm isolating CPU cores using boot parameter. (grub)) And Ethernet ISR drivers load is also high, up to 70%. One more dedicated core is required for ISR. (IRQ affinity is used) Totally, three cores are used just for interfacing USRP. Is the CPU load of three core for USRP interface under above condition, reasonable ? I want to reduce CPU core counts for USRP interface. Is there any way to reduce the CPU load ? Best Regards, Noboru KOBAYASHI ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] warning on UDP buffer size when using Python API
Hi, I'm running with the Python API and I keep getting the following warning (see pic below). I go ahead and change the buffer size per the command listed, but I still get the warning again with different numbers. Is this normal? Will it cause any data loss? Anyway to fix? Thanks! Oz [cid:image001.png@01D3330D.8352CEF0] ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Phase jumps in USRP B210 with GPSDO
W dniu 21.09.2017 o 21:06, Marcus D. Leech via USRP-users pisze: > On 09/21/2017 02:27 PM, Piotr Krysik via USRP-users wrote: >> >> -- >> Piotr Krysik >> >> >> Also take into account that I'm not comparing phase signals observed by >> two different USRPs. What I have shown is for single channel of one USRP >> in which such jumps are observed (I'm comparing phase of digitally >> generated sinusoid with phase of recorded one). Same thing, however, can >> be observed when recording signal with two USRPS in situation where one >> have board mounted GPSDO and another one doesn't (with simple >> unwrap(angle(x1.*conj(x2))) where x1 and x2 are signal vectors). Both >> USRPs synchronized with use of Octoclock-G. >> >> To make the matter simpler to gasp I will check if the same problem can >> be observed on one USRP B210 with board mounted GPSDO - without any >> additional hardware. >> >> > I use B210s for interferometry. Phase coherence is stable basically > "forever" between two B210 RX channels, regardless of the reference > used, since the > LO is shared between the two receive channels. So, absent bugs in > the FPGA digital processing, I'd be very surprised to see phase-hits > within a single > B210. > Hi, The problem appears only when synchronizing USRPs B210 that have board mounted GPSDO with use of Octoclock-G. This configuration doesn't work correctly. Marcus - I suppose that you haven't seen this problem yet because you didn't try to use B210s in such configuration. I've checked today signal phase on a single USRP B210 with GPSDO, but without connecting external synchronization source. In this situation everything is fine. So what is good is that it is not board mounted GPSDO alone that causes the problem. In short the solution for now is: remove GPSDO from your USRP B210 if you want to synchronize it with use of external PPS and 10MHz ref source. (The solution is not perfect as these GPSDOs have delicate pins at the connector.) Best Regards, Piotr Krysik ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
