Is that a new symptom, or have the UHD Warning:... been there from the beginning?
I'd like to ask you to copy&paste (not screenshot) the full console output of running your flowgraph on your machine. Thanks! Marcus On 08/02/2017 08:18 PM, Rui ZOU wrote: > Most of the times, the transmission is stable, but there are 3 times > bad things pop up. 'L' is shown for one time after running for some > time. The following warning is shown twice. > > UHD Warning: > x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7] > thread[thread-per-block[5]: <block gr uhd usrp sink (1)>]: > RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected FIFO > depth [0x7] > > The X3xx is connected to the host using 1G Ethernet cable. The network > card is Intel Ethernet Converged Network Adapter X520-DA2. The card > can support 10Gbps, but the sfp+ to rj45 adapter can supports only > 1Gbps. The output of lspci is shown below. > > lspci > 00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM > Registers (rev 07) > 00:01.0 PCI bridge: Intel Corporation Sky Lake PCIe Controller (x16) > (rev 07) > 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI > Controller (rev 31) > 00:14.2 Signal processing controller: Intel Corporation Sunrise > Point-H Thermal subsystem (rev 31) > 00:16.0 Communication controller: Intel Corporation Sunrise Point-H > CSME HECI #1 (rev 31) > 00:16.3 Serial controller: Intel Corporation Sunrise Point-H KT > Redirection (rev 31) > 00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID > mode] (rev 31) > 00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root > Port #9 (rev f1) > 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller > (rev 31) > 00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31) > 00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31) > 00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31) > 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) > I219-LM (rev 31) > 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit > SFI/SFP+ Network Connection (rev 01) > 01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit > SFI/SFP+ Network Connection (rev 01) > 02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. > [AMD/ATI] Oland XT [Radeon HD 8670 / R7 250/350] (rev 83) > 02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape > Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series] > > Rui > > > On Wed, Aug 2, 2017 at 1:17 PM, Marcus Müller <muel...@kit.edu > <mailto:muel...@kit.edu>> wrote: > > I'd consider that good news, because that definitely means that > your PC is up to the task of supplying samples fast enough :) > > Still, we're getting "L"s. So let's reduce the test case: Same > USRP Sink as you use here, but with a Null Source directly feeding > it. Is that stable? > > While we're at it: can you describe how the X3xx is connected? Can > you maybe even share info on the network card you're using (lspci > might help)? > > Best regards, > > Marcus > > > On 08/02/2017 06:01 PM, Rui ZOU wrote: >> Sorry for the confusion, because I thought whenever a hardware is >> not used throttle block must be used. >> >> This time, no USRP, no throttle block, the rate is 11.6MS/s. The >> python test takes several top CPU consumption PIDs as shown by >> the htop screen capture. >> >> ******* MESSAGE DEBUG PRINT ******** >> (((rate_now . 1.14922e+07) (rate_avg . 1.16197e+07))) >> ************************************ >> >> >> On Wed, Aug 2, 2017 at 11:45 AM, Marcus Müller <muel...@kit.edu >> <mailto:muel...@kit.edu>> wrote: >> >> I'm really confused at this point. In no point in your >> testing should be Throttle involved. So, please, can you do a >> test with: >> >> Null Source >> Probe Rate -> Message Debug >> No UHD USRP Sink >> No Throttle >> >> and tell me a) how fast you were and b) how much CPU you used ? >> Thanks! >> >> Marcus >> >> >> On 08/02/2017 05:18 PM, Rui ZOU wrote: >>> The screen capture of htop when running the python script, >>> test.py, is attached. >>> >>> On Wed, Aug 2, 2017 at 11:10 AM, Rui ZOU >>> <zourui.mkithap...@gmail.com >>> <mailto:zourui.mkithap...@gmail.com>> wrote: >>> >>> Throttle block is NEVER in use when USRP Sink is used. >>> >>> On Wed, Aug 2, 2017 at 11:08 AM, Rui ZOU >>> <zourui.mkithap...@gmail.com >>> <mailto:zourui.mkithap...@gmail.com>> wrote: >>> >>> USRP sink >>> >>> On Wed, Aug 2, 2017 at 11:08 AM, Rui ZOU >>> <zourui.mkithap...@gmail.com >>> <mailto:zourui.mkithap...@gmail.com>> wrote: >>> >>> My previous email shows the rate WITHOUT >>> >>> On Wed, Aug 2, 2017 at 11:05 AM, Marcus Müller >>> <muel...@kit.edu <mailto:muel...@kit.edu>> wrote: >>> >>> WAIT! Throttle? I didn't see that in either >>> of the flow graphs you sent me first >>> (twoparatx, onefile2tx) >>> >>> Seriously?! Your GRC will even print a >>> warning that you mustn't use Throttle >>> together with hardware if you have both >>> Throttle and a USRP sink. >>> >>> Remove the Throttle, and try again. >>> >>> >>> >>> On 08/02/2017 05:00 PM, Rui ZOU wrote: >>>> Changed to null source, the rate is still >>>> around twice the sample rate (390.625k) for >>>> throttle block. >>>> >>>> ******* MESSAGE DEBUG PRINT ******** >>>> (((rate_now . 781360) (rate_avg . 786529))) >>>> ************************************ >>>> >>>> When the throttle block is bypassed, the >>>> rate jumps up to around 11.3MS/s. >>>> >>>> ******* MESSAGE DEBUG PRINT ******** >>>> (((rate_now . 1.16071e+07) (rate_avg . >>>> 1.12848e+07))) >>>> ************************************ >>>> >>>> The rate is similar to using file source, >>>> 0.78MS/s with throttle and 11.3MS/s when >>>> throttle bypassed. >>>> >>>> Rui >>>> >>>> On Wed, Aug 2, 2017 at 10:37 AM, Marcus >>>> Müller <muel...@kit.edu >>>> <mailto:muel...@kit.edu>> wrote: >>>> >>>> Ok, there's something fishy here. That >>>> rate (without the USRP Sink) is >>>> ridiculously low. Can you replace the >>>> file_source with a null_source? That >>>> way, we can rule out storage as the >>>> bottleneck. >>>> >>>> The probe_rate does nothing but just >>>> count how many items fly by, and then >>>> send a message at its output port every >>>> update period. The message_debug just >>>> prints messages. >>>> >>>> If it's not storage: are you perhaps >>>> running in a powersaver mode? Even so, >>>> the rate would be too low. I really >>>> don't know what's going wrong here. Run >>>> your flow graph, run "top" in a >>>> terminal, check that the python process >>>> and its spawned child threads really >>>> consume most of the CPU. If that's not >>>> the case, you've got something else >>>> eating away on your CPU. >>>> >>>> Best regards, >>>> >>>> Marcus >>>> >>>> >>>> On 08/02/2017 04:22 PM, Rui ZOU wrote: >>>>> Not sure if the debug setup is the >>>>> expected since it's the first time I >>>>> use the 'Probe Rate' and 'Message >>>>> Debug' blocks whose functions are not >>>>> very clear to me now just after >>>>> reading the contents under the >>>>> document tag. If there are other ways >>>>> to learn about new blocks, please advise. >>>>> >>>>> The rates I get when the USRP Sink >>>>> disabled is around 0.78MS/s I guess >>>>> from the debug output, shown below. >>>>> >>>>> ******* MESSAGE DEBUG PRINT ******** >>>>> (((rate_now . 782916) (rate_avg . >>>>> 784937))) >>>>> ************************************ >>>>> >>>>> After enabling the USRP Sink, I got >>>>> lots of 'L's and 2.4MS/s, shown below. >>>>> >>>>> >>>>> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL******* >>>>> MESSAGE DEBUG PRINT ******** >>>>> (((rate_now . 2.36319e+06) (rate_avg . >>>>> 2.36319e+06))) >>>>> ************************************ >>>>> >>>>> GRC and python files are attached. >>>>> >>>>> Rui >>>>> >>>>> On Wed, Aug 2, 2017 at 3:57 AM, Marcus >>>>> Müller <muel...@kit.edu >>>>> <mailto:muel...@kit.edu>> wrote: >>>>> >>>>> Huh, I really don't know what's >>>>> happening there :/ I sadly don't >>>>> have the USRP to test this live >>>>> with me right now, but there's >>>>> absolutely no timed commands involved¹ >>>>> >>>>> So, trying to weed out bugs: >>>>> >>>>> * I've replaced the USRP sink with >>>>> a "Probe Rate" block, connected to >>>>> a "Message Debug"'s print port. I >>>>> saw samples fly by with more than >>>>> 7 MS/s, so there really shouldn't >>>>> be a bottleneck here – can you try >>>>> to do the same and see whether >>>>> your system can get similar rates? >>>>> 7MS/s is still far too little for >>>>> my taste, but that is >>>>> FM-Modulation-limited² >>>>> * Can you delete your subdev spec? >>>>> in a 2-channel case, that should >>>>> be the implicit one, anyways. >>>>> >>>>> Best regards, >>>>> >>>>> Marcus >>>>> >>>>> ¹ "timed commands" are a USRP >>>>> feature that allows certain things >>>>> to happen at well-defined times. >>>>> You get an L when a timed command >>>>> reaches the USRP after the >>>>> specified time has already passed. >>>>> In your flow graph, all that could >>>>> happen is that a sample packet >>>>> reaches the USRP after it should – >>>>> but that's unlikely, you'd get a >>>>> "U" instead. >>>>> >>>>> ² at least on my machine, most of >>>>> the time is spent in the FM >>>>> modulator. Which is kind of >>>>> annoying, because looking into >>>>> that, what costs most time is the >>>>> "keeping the phase within 0;2pi" >>>>> floating point modulo operation. I >>>>> might get the urge to fix that. >>>>> >>>>> >>>>> >>>>> On 08/01/2017 08:31 PM, Rui ZOU wrote: >>>>>> Hi Marcus, >>>>>> >>>>>> I have fixed the two parallel >>>>>> SISO by removing packeting >>>>>> encoding, using QT GUI instead of >>>>>> WX. But the 'L' indicator still >>>>>> comes on, even sooner than >>>>>> previous version. The GRC and >>>>>> generated python files are attached. >>>>>> >>>>>> Rui >>>>>> >>>>>> On Tue, Aug 1, 2017 at 12:04 PM, >>>>>> Marcus Müller <muel...@kit.edu >>>>>> <mailto:muel...@kit.edu>> wrote: >>>>>> >>>>>> Ah, cool, but then I wouldn't >>>>>> start by packetizing data. >>>>>> >>>>>> Simply send your file >>>>>> GMSK-Modulated; drop the >>>>>> packet encoding; think about >>>>>> it: the MIMO coding (usually) >>>>>> happens *after* the data has >>>>>> been formed to logical data >>>>>> units. >>>>>> >>>>>> A few notes on your >>>>>> flowgraphs: Don't use the WX >>>>>> GUI elements in new >>>>>> flowgraphs. We have >>>>>> deprecated them, since no-one >>>>>> can maintain them, and the Qt >>>>>> GUI sinks have shown to be >>>>>> both more stable and >>>>>> efficient. As far as I can >>>>>> foresee your application's >>>>>> needs, Qt has replacements >>>>>> for all the WX visualizations >>>>>> you'd need. >>>>>> >>>>>> For the receiver, I'd guess >>>>>> you'd first simply start by >>>>>> just recording from to >>>>>> channels, and then >>>>>> experimenting with things >>>>>> like cross-correlation, and >>>>>> estimating the channel matrix >>>>>> based on your known transmit >>>>>> signal. I wouldn't be >>>>>> surprised if the channel is >>>>>> rather boring in your setup – >>>>>> I blindly assume you're doing >>>>>> this indoors, and that limits >>>>>> the path difference and the >>>>>> amount of change (and hence, >>>>>> the delay spread and the >>>>>> doppler spread) your signals >>>>>> are subject to, especially >>>>>> since your bandwidth is so >>>>>> low. Of course, having a flat >>>>>> channel is nice :) but it >>>>>> also means that it might be >>>>>> quite hard to get any actual >>>>>> MIMO gain, because the two RX >>>>>> antennas might be very >>>>>> correlated. If in doubt, >>>>>> increase bandwidth. Be >>>>>> agressive with roll-off / >>>>>> Bandwidth factors of your GMSK. >>>>>> >>>>>> Cheers, >>>>>> Marcus >>>>>> >>>>>> >>>>>> On 08/01/2017 05:51 PM, Rui >>>>>> ZOU wrote: >>>>>>> Hi Marcus, >>>>>>> >>>>>>> My goal is to first build a >>>>>>> 2-by-2 space multiplexing >>>>>>> MIMO using two X310s and GNU >>>>>>> Radio. As I'm new to all >>>>>>> this stuff, I'm starting >>>>>>> from building 2 parallel >>>>>>> SISOs. If there are some >>>>>>> good kick-start materials or >>>>>>> any resources, they will be >>>>>>> very valuable. Thanks. >>>>>>> >>>>>>> Rui >>>>>>> >>>>>>> On Tue, Aug 1, 2017 at 11:37 >>>>>>> AM, Marcus Müller >>>>>>> <muel...@kit.edu >>>>>>> <mailto:muel...@kit.edu>> wrote: >>>>>>> >>>>>>> Hi Rui, >>>>>>> >>>>>>> sorry, I might simply >>>>>>> have missed those, and >>>>>>> didn't find your first >>>>>>> email when I saw your >>>>>>> recent one! I apologize. >>>>>>> >>>>>>> So, hm, interestingly, >>>>>>> we have a severe bug in >>>>>>> the packet_encoder block >>>>>>> (its design is pretty >>>>>>> bad, and that triggers >>>>>>> an unexpected behaviour >>>>>>> underneath). That might >>>>>>> mean the packet_encoder >>>>>>> is just consuming items >>>>>>> as fast as it can, >>>>>>> without actually >>>>>>> producing packets. In >>>>>>> other words, >>>>>>> packet_encoder is >>>>>>> broken; you can't use it >>>>>>> right now. >>>>>>> >>>>>>> The more appropriate way >>>>>>> of dealing with data >>>>>>> might be in the example >>>>>>> flowgraphs that you'd >>>>>>> find under >>>>>>> >>>>>>> /usr/[local/]share/doc/gnuradio/examples/digital/packet_loopback_hier.grc >>>>>>> ; it's a lot more >>>>>>> complicated, though, and >>>>>>> you'd have to write a >>>>>>> message / PDU source >>>>>>> that gives you the data >>>>>>> you want to transmit, >>>>>>> rather than the Random >>>>>>> PDU block! >>>>>>> >>>>>>> I don't really know if >>>>>>> that is the way to go. >>>>>>> What is it, that you >>>>>>> want to build? Maybe the >>>>>>> mailing list can advise? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Marcus >>>>>>> >>>>>>> >>>>>>> On 08/01/2017 05:26 PM, >>>>>>> Rui ZOU wrote: >>>>>>>> Here are the two >>>>>>>> flowgraphs I have used. >>>>>>>> I have tried to attach >>>>>>>> the two files in my >>>>>>>> first email. Probably >>>>>>>> failed in doing that. >>>>>>>> If still not seen, >>>>>>>> please let me know so I >>>>>>>> will try again. Thanks >>>>>>>> for your help. >>>>>>>> >>>>>>>> Running the first flow >>>>>>>> graph will cause GRC >>>>>>>> stop responding >>>>>>>> instantly, while the >>>>>>>> second one can run for >>>>>>>> a little while and >>>>>>>> produce lots of 'L' >>>>>>>> before going not >>>>>>>> responsive. >>>>>>>> >>>>>>>> Rui >>>>>>>> >>>>>>>> On Tue, Aug 1, 2017 at >>>>>>>> 11:09 AM, Marcus Müller >>>>>>>> <muel...@kit.edu >>>>>>>> <mailto:muel...@kit.edu>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Rui, >>>>>>>> >>>>>>>> don't know, to me, >>>>>>>> it looks like >>>>>>>> replying didn't >>>>>>>> work out great, >>>>>>>> since my mail >>>>>>>> client showed your >>>>>>>> mail in a new >>>>>>>> thread. Really, >>>>>>>> replying to a >>>>>>>> mailing list mail >>>>>>>> should be nothing >>>>>>>> more than hitting >>>>>>>> the "reply" or >>>>>>>> "reply all" button. >>>>>>>> >>>>>>>> Anyway, even the >>>>>>>> slowest >>>>>>>> PC/laptop/Raspberry >>>>>>>> Pi/… I could think >>>>>>>> of would be able to >>>>>>>> deal with these >>>>>>>> rates, so there's >>>>>>>> very, very likely >>>>>>>> something wrong >>>>>>>> with the GNU Radio >>>>>>>> flowgraph you're >>>>>>>> using. Maybe you'd >>>>>>>> want to share that! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Marcus >>>>>>>> >>>>>>>> >>>>>>>> On 08/01/2017 04:59 >>>>>>>> PM, Rui ZOU wrote: >>>>>>>>> Hi Marcus, >>>>>>>>> >>>>>>>>> Sorry for leaving >>>>>>>>> the title empty, >>>>>>>>> that's the first >>>>>>>>> time to post to a >>>>>>>>> mailing list. This >>>>>>>>> is also the first >>>>>>>>> time to reply, no >>>>>>>>> sure if I replied >>>>>>>>> correctly. >>>>>>>>> >>>>>>>>> I use 390.625k as >>>>>>>>> the sampling rate >>>>>>>>> because this is >>>>>>>>> the lowest I can >>>>>>>>> get using the >>>>>>>>> Ettus X310 without >>>>>>>>> giving me a >>>>>>>>> warning saying >>>>>>>>> that the sampling >>>>>>>>> rate cannot be >>>>>>>>> provided by the >>>>>>>>> hardware. The >>>>>>>>> application is >>>>>>>>> just transmitting >>>>>>>>> a file using GMSK >>>>>>>>> modulation on the >>>>>>>>> two daughter >>>>>>>>> boards of X310. >>>>>>>>> >>>>>>>>> Rui >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Discuss-gnuradio mailing >>>>>>>>> list >>>>>>>>> Discuss-gnuradio@gnu.org >>>>>>>>> >>>>>>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>>>>>> >>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>>> >>>>>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>>>>> > _______________________________________________ > 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
