Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Disabling GPS-DO (Eric C.)
2. Re: Tooling for connector on B200mini (Ian Buckley)
3. Re: Disabling GPS-DO (Marcus D. Leech)
4. Re: USRP B210 Overflow (Marcus M?ller)
5. Re: USRP B210 Overflow (Marcus D. Leech)
6. [UHD] Versioning scheme for future major releases (Martin Braun)
7. Custom FPGA image without UHD on X3x0 (Christian Schr?der)
8. Re: Custom FPGA image without UHD on X3x0 (Marcus M?ller)
9. Re: srsLTE & X300 box. (Marcus M?ller)
10. Re: srsLTE & X300 box. (Michael West)
11. Re: srsLTE & X300 box. (Marcus M?ller)
12. Re: Custom FPGA image without UHD on X3x0 (Ian Buckley)
13. Re: srsLTE & X300 box. (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 17 Jun 2016 10:06:08 -0600
From: "Eric C." <[email protected]>
To: "Eric C." <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Disabling GPS-DO
Message-ID:
<CABf-Ja7CiJuMJ9GT6a8YZ8M+no4=yvqzuphfe5zrmxkwg5w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
> On 06/16/2016 05:51 PM, Eric C. via USRP-users wrote:
> >* I was wondering how far I have to go to disable the GPS-DO? In looking
*> >* at the schematics it would seem that switching the J510 jumper should
*> >* be enough, then I can use an external 10 MHz reference and 1 PPS. But
*> >* I think I still get a message when I start up the device about
*> >* detecting and using the GPS-DO. Should I unplug the power? The 10 MHz
*> >* and 1 PPS internal rf cables? The serial cable? Thanks.
*> >> >* -- Eric C.
*> >> >> >* _______________________________________________
*> >* USRP-users mailing list
*> >* USRP-users at lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
*> >* http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
*> When you create your USRP object, just configure it for external
10Mhz > and 1PPS reference. It'll still go through the motions on
start-up> to confirm the GPSDO presence, but the actual "session"
will use > external.
Thank you. Does this mean I don't even have to change the jumper J510
back to the way it was before installing the GPS-DO?
(I'm sorry for the inline text here. For some reason I didn't receive
your last email, I just found it online.)
-- Eric C.
On Thu, Jun 16, 2016 at 3:51 PM, Eric C. <[email protected]> wrote:
> I was wondering how far I have to go to disable the GPS-DO? In looking at
> the schematics it would seem that switching the J510 jumper should be
> enough, then I can use an external 10 MHz reference and 1 PPS. But I think
> I still get a message when I start up the device about detecting and using
> the GPS-DO. Should I unplug the power? The 10 MHz and 1 PPS internal rf
> cables? The serial cable? Thanks.
>
> -- Eric C.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/fbf773bc/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 17 Jun 2016 09:19:59 -0700
From: Ian Buckley <[email protected]>
To: Dan CaJacob <[email protected]>
Cc: Mark Napier <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Tooling for connector on B200mini
Message-ID:
<CAM_0ocGHoNCXJX5CeKgT6c5PSqkzMmet2DtRLSf8qA1mt=v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Mark,
I had a fairly large quantity of cables to work with these connectors made
up in Asia for exactly this reason.
Contact me off list and if what I have works for you I'll sell you a few at
cost.
-Ian
On Fri, Jun 17, 2016 at 8:12 AM, Dan CaJacob via USRP-users <
[email protected]> wrote:
> Oh, I thought you were talking about an RF cable.
>
> On Fri, Jun 17, 2016 at 10:47 AM Mark Napier <[email protected]>
> wrote:
>
>> The contact is 440147-2 from Tyco Electronics. Wire is 28 AWG. Digikey
>> has already said they don't do them. Think crazy small.
>>
>>
>> On Fri, Jun 17, 2016 at 10:34 AM, Dan CaJacob <[email protected]>
>> wrote:
>>
>>> What type of cables/connectors are these? You can usually buy pre-made
>>> cables from places like DigiKey and Mouser as well as other smaller, more
>>> specific RF houses. They're not the best cables in the world, but they're
>>> inexpensive.
>>>
>>> On Fri, Jun 17, 2016 at 8:04 AM Mark Napier via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hello,
>>>>
>>>> We're trying to make a couple of cables to mate up with J5 and J6 on
>>>> the B205mini. Have the mating connector and contacts. However, the
>>>> contacts are *very* tiny with open barrel construction. The recommended
>>>> tooling for them is for mass production and is wildly expensive. Our
>>>> technician is trying with a couple different hand crimpers (very high
>>>> quality) but right now is very frustrated.
>>>>
>>>> What do you use in house? Is there a hand-held crimper that will do an
>>>> acceptable job? Failing that, is there someone you use to make cables for
>>>> you?
>>>>
>>>> Thank you much,
>>>>
>>>> Mark Napier
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>> --
>>> Very Respectfully,
>>>
>>> Dan CaJacob
>>>
>>
>> --
> Very Respectfully,
>
> Dan CaJacob
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/7b6134f7/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 17 Jun 2016 12:22:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Disabling GPS-DO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/17/2016 12:06 PM, Eric C. via USRP-users wrote:
> > On 06/16/2016 05:51 PM, Eric C. via USRP-users wrote:
> > >/ I was wondering how far I have to go to disable the GPS-DO? In looking
> />>/ at the schematics it would seem that switching the J510 jumper should
> />>/ be enough, then I can use an external 10 MHz reference and 1 PPS. But
> />>/ I think I still get a message when I start up the device about
> />>/ detecting and using the GPS-DO. Should I unplug the power? The 10 MHz
> />>/ and 1 PPS internal rf cables? The serial cable? Thanks.
> />>/
> />>/ -- Eric C.
> />>/
> />>/
> />>/ _______________________________________________
> />>/ USRP-users mailing list
> />>/ USRP-users at lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> />>/ http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> />When you create your USRP object, just configure it for external 10Mhz
> >and 1PPS reference. It'll still go through the motions on start-up
> > to confirm the GPSDO presence, but the actual "session" will use
> >external.
> Thank you. Does this mean I don't even have to change the jumper J510 back to
> the way it was before installing the GPS-DO?
> (I'm sorry for the inline text here. For some reason I didn't receive your
> last email, I just found it online.)
Actually, yes, you'll need to change that jumper. I'd forgotten than on
N2xx, that "GPS DO" and "External" are actually conceptual synonyms, and
you have to change that jumper. On newer hardware, they're distinct
hardware pathways.
>
>
> -- Eric C.
>
> On Thu, Jun 16, 2016 at 3:51 PM, Eric C. <[email protected]
> <mailto:[email protected]>> wrote:
>
> I was wondering how far I have to go to disable the GPS-DO? In
> looking at the schematics it would seem that switching the J510
> jumper should be enough, then I can use an external 10 MHz
> reference and 1 PPS. But I think I still get a message when I
> start up the device about detecting and using the GPS-DO. Should I
> unplug the power? The 10 MHz and 1 PPS internal rf cables? The
> serial cable? Thanks.
>
> -- Eric C.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/c78ba1e5/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 17 Jun 2016 19:07:39 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Xuesong,
I was just told I misread your email. I'd like to apologize for that!
> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
> streaming data to a file even with sampling rate of 5 MHz:
> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
> --wirefmt=sc16 --duration=600
Ooops, you're doing 5MS/s here.
Ok, that's only 20MB/s, and now everything is comparable to the N210 case.
This is actually not typical; let's do a quick benchmark with dd:
yes | dd of=/home/marcus/Desktop/test.bin bs=512 count=$((4*600 * 5 * 10**6 /
512)) conv=fsync
to try and write data in roughly the same granularity as
rx_samples_to_file does by default for a B210 connected using USB3 with
the same amount of data.
Could you also copy&paste the full output of rx_samples_to_file? That
could be very helpful.
I'm still pretty sure the problem is storage here ? my suspicion is that
the write buffer of your operating system fills up with the 12GB of data
coming in from the USRP, and then suddenly, the OS has to start
throttling the USRP, because it can't write data to the SSD fast enough
- possibly partly because filesystem access is everything but CPU-free.
Are you planning on using GNU Radio? If you want to do that anyway,
something like:
UHD USRP Source ---> File Sink
would probably work better than the rx_samples_to_file example, because
GNU Radio is inherently multi-threaded. If you're using the GNU Radio
companion, the USRP Source block has an "advanced options" tab, where
you can set a larger minimum output buffer; try something like 10**7,
which will give you a couple Megabytes of buffering already, which might
already compensate for the non-uniform write speeds of a storage device.
Best regards,
Marcus
On 17.06.2016 17:34, Marcus M?ller wrote:
> Hi Xuesong,
>
> On 06/17/2016 03:20 PM, illuantision via USRP-users wrote:
>> Hi all,
>>
>> If anyone of you encountered the overflow problem when streaming data
>> into a file using USRP B210 through USB 3.0?
> Yes. Storage devices are usually slower at consuming data than the
> B210 is at producing them.
> Furthermore, not all USB3 host controller chipsets can deal with the
> full rate coming from a USRP. They simply throttle, drop packets or crash.
>>
>> The situation is that:
>>
>> 1) Everything works fine without overruns in benchmark rate test:
>> ./benchmark_rate --rx_rate=50e6 --otw=sc16
> Excellent! Your USB3 works fine at these rates.
>>
>> 2) Everything works fine without overruns in rx_samples_to_file test:
>> ./rx_samples_to_file --file=/dev/null --rate=50e6 --wirefmt=sc16
>> --duration=600
> The same as above.
>>
>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>> streaming data to a file even with sampling rate of 5 MHz:
>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>> --wirefmt=sc16 --duration=600
> This is 50MS/s * 4B/S = 200MB/s = 1600Mb/s of data, to a total of
> 120GB. Not even most SSDs are up to that write speed over that much
> data, which definitely exceeds typical file system RAM buffers.
>
> If you really need to store 120GB of recorded spectrum at once, you'll
> either need a lot of RAM to first write this into a RAMdisk, or you'll
> need a really really capable storage subsystem ? PCIe SSDs, or
> impressive RAIDs of cheaper SSDs might work. Also, you'll want to
> optimize your filesystem for continued streaming (journalling file
> systems make no sense here, huge buffers do), and you'll probably want
> something else than our rx_samples_to_file example: it's not really
> multithreaded, and does no internal write buffering.
>>
>> The throughput of the Samsung mSATA SSD disk we are using is more
>> than 500 MBps,
> Which is too little by more than a factor of 3
>> and it works fine with N210.
> Which can't do more than 25MS/s @SC16
>> I am quite sure this problem is not the fault of CPU, memory, SSD
>> disk or USB 3.0. It seems that something happens when they work
>> together with B210.
> Pretty sure this is your SSD.
>>
>> I also found previous reports about the same problem in the 2014
>> March usurp mail list here:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-March/008894.html;
>> and in the Github issues here:
>> https://github.com/EttusResearch/uhd/issues/58.
>>
>> Streaming data into files is a basic application of USRP. Hope some
>> of you could provide with solutions for this problem.
> I'm afraid all I can tell you is:
>
> * faster storage
> * using a multi-threaded, buffering program instead of the
> rx_samples_to_file example (it's /really/ just an example of how to
> use UHD to receive files, not a throughput-optimized application)
>
> Best regards,
> Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/2d5697aa/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 17 Jun 2016 13:28:30 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 Overflow
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/17/2016 01:07 PM, Marcus M?ller via USRP-users wrote:
>
> Hi Xuesong,
>
> I was just told I misread your email. I'd like to apologize for that!
>
>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>> streaming data to a file even with sampling rate of 5 MHz:
>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>> --wirefmt=sc16 --duration=600
> Ooops, you're doing 5MS/s here.
> Ok, that's only 20MB/s, and now everything is comparable to the N210 case.
> This is actually not typical; let's do a quick benchmark with dd:
>
> yes | dd of=/home/marcus/Desktop/test.bin bs=512 count=$((4*600 * 5 * 10**6 /
> 512)) conv=fsync
>
> to try and write data in roughly the same granularity as
> rx_samples_to_file does by default for a B210 connected using USB3
> with the same amount of data.
>
> Could you also copy&paste the full output of rx_samples_to_file? That
> could be very helpful.
>
> I'm still pretty sure the problem is storage here ? my suspicion is
> that the write buffer of your operating system fills up with the 12GB
> of data coming in from the USRP, and then suddenly, the OS has to
> start throttling the USRP, because it can't write data to the SSD fast
> enough - possibly partly because filesystem access is everything but
> CPU-free.
>
> Are you planning on using GNU Radio? If you want to do that anyway,
> something like:
>
> UHD USRP Source ---> File Sink
>
> would probably work better than the rx_samples_to_file example,
> because GNU Radio is inherently multi-threaded. If you're using the
> GNU Radio companion, the USRP Source block has an "advanced options"
> tab, where you can set a larger minimum output buffer; try something
> like 10**7, which will give you a couple Megabytes of buffering
> already, which might already compensate for the non-uniform write
> speeds of a storage device.
>
> Best regards,
> Marcus
>
> On 17.06.2016 17:34, Marcus M?ller wrote:
>> Hi Xuesong,
>>
>> On 06/17/2016 03:20 PM, illuantision via USRP-users wrote:
>>> Hi all,
>>>
>>> If anyone of you encountered the overflow problem when streaming
>>> data into a file using USRP B210 through USB 3.0?
>> Yes. Storage devices are usually slower at consuming data than the
>> B210 is at producing them.
>> Furthermore, not all USB3 host controller chipsets can deal with the
>> full rate coming from a USRP. They simply throttle, drop packets or
>> crash.
>>>
>>> The situation is that:
>>>
>>> 1) Everything works fine without overruns in benchmark rate test:
>>> ./benchmark_rate --rx_rate=50e6 --otw=sc16
>> Excellent! Your USB3 works fine at these rates.
>>>
>>> 2) Everything works fine without overruns in rx_samples_to_file
>>> test: ./rx_samples_to_file --file=/dev/null --rate=50e6
>>> --wirefmt=sc16 --duration=600
>> The same as above.
>>>
>>> 3) There will DEFINITELY be overruns (in less than 2 minutes) when
>>> streaming data to a file even with sampling rate of 5 MHz:
>>> ./rx_samples_to_file --file=~/Desktop/test.bin --rate=5e6
>>> --wirefmt=sc16 --duration=600
>> This is 50MS/s * 4B/S = 200MB/s = 1600Mb/s of data, to a total of
>> 120GB. Not even most SSDs are up to that write speed over that much
>> data, which definitely exceeds typical file system RAM buffers.
>>
>> If you really need to store 120GB of recorded spectrum at once,
>> you'll either need a lot of RAM to first write this into a RAMdisk,
>> or you'll need a really really capable storage subsystem ? PCIe SSDs,
>> or impressive RAIDs of cheaper SSDs might work. Also, you'll want to
>> optimize your filesystem for continued streaming (journalling file
>> systems make no sense here, huge buffers do), and you'll probably
>> want something else than our rx_samples_to_file example: it's not
>> really multithreaded, and does no internal write buffering.
>>>
>>> The throughput of the Samsung mSATA SSD disk we are using is more
>>> than 500 MBps,
>> Which is too little by more than a factor of 3
>>> and it works fine with N210.
>> Which can't do more than 25MS/s @SC16
>>> I am quite sure this problem is not the fault of CPU, memory, SSD
>>> disk or USB 3.0. It seems that something happens when they work
>>> together with B210.
>> Pretty sure this is your SSD.
>>>
>>> I also found previous reports about the same problem in the 2014
>>> March usurp mail list here:
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-March/008894.html;
>>>
>>> and in the Github issues here:
>>> https://github.com/EttusResearch/uhd/issues/58.
>>>
>>> Streaming data into files is a basic application of USRP. Hope some
>>> of you could provide with solutions for this problem.
>> I'm afraid all I can tell you is:
>>
>> * faster storage
>> * using a multi-threaded, buffering program instead of the
>> rx_samples_to_file example (it's /really/ just an example of how to
>> use UHD to receive files, not a throughput-optimized application)
>>
>> Best regards,
>> Marcus
>
>
Also try increasing num_recv_frames in the device argument--up to 128 or so.
The "dynamics" of general-purpose operating systems are subtle, and
often not immediately intuitive. Just because you can stream at
one rate from a particular type of streaming device (a 1GiGe N210),
does not mean that the same rates are sustainable from a different
type of device that uses USB3. The operating-system resources
consumed by the underlying hardware are different, the buffering is
different, and the dynamic behavior is different.
The B210 is perfectly happy to be a "Niagara Falls" of sample data, but
the size of the "bucket" you hold under it is a attribute of your
underlying operating system software and hardware dynamics.
Also, rx_samples_to_file is an example, and as an example, it strives to
be as simple as possible. Which means that it's single threaded,
and has no "hooks" to optimize for system specifics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/6f7a7138/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 17 Jun 2016 12:03:41 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [UHD] Versioning scheme for future major
releases
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear UHD fans,
for the next major release (i.e. the 3.10 release), we will be changing
out versioning scheme. We'll be going to a quadruplet version scheme,
similar to GNU Radio. So, the current master branch is versioned
3.10.0.git, and the first actual release on this cycle will be 3.10.0.0.
An often-requested feature[1] was the ability to distinguish ABI and API
versions from the version string. We'll be doing this by adding actual
meaning to each tuple element; version numbers can be read as:
Major.API.ABI.Patch
Example: Say we release 3.10.0.0, and then 3.10.0.1. That means we've
fixed some bugs, but the ABI is the same --> Your binary installs will
still work if you swap out the shared libraries for UHD.
Example: We change something, and ABI changes: In this case, we'd go
from 3.10.0.0 to 3.10.1.0. This most likely means you will need to
recompile and -link your software to UHD after an update, but you won't
have to change the software.
Example: Say we modify the API in the next release (which won't happen,
but just as an example): We'd go from 3.10.0.0 straight to 3.11.0.0. In
this case, your software may need to be changed to work with the new
version, depending on which features you use. In many cases, an update
won't be necessary.
The 'major' change is reserved for changes that we subjectively grade as
major changes. With a major change (e.g. from 3.* to 4.*), we make no
guarantees about compatibility (but rest assured we'll do our best to
stay compatible as long as its feasible).
For anyone packaging UHD, please see if this affects your build scripts
and tools, and provide us feedback. The version feature has already been
merged onto master, so you should have ample time to try it before we do
another release.
Cheers,
Martin
------------------------------
Message: 7
Date: Fri, 17 Jun 2016 22:14:11 +0200
From: Christian Schr?der <[email protected]>
To: [email protected]
Subject: [USRP-users] Custom FPGA image without UHD on X3x0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
format="flowed"
Dear All,
I was wondering if it is possible to program a custom FPGA image onto
a X3x0 USRP (with CBX daughterboards) without using the UHD
implementation. With the custom FPGA image all the hardware components
connected to the FPGA should be controlled through our own IP modules.
Additionally, a connected host PC must serve as a controlling device.
Signal processing will be solely implemented on the FPGA.
I've found the related schematics of both X3x0 USRP and CBX
daughterboard as well as the specifications of the respective
components (AD/DA converter etc.). In my understanding it should be
possible to implement all necessary FPGA modules (like SPI master,
Ethernet towards host PC etc.) to control all of the hardware
components.
Now here's the question that bothers me: Am I missing something? Is
there anything I have to consider before?
Many thanks in advance!
Christian
------------------------------
Message: 8
Date: Fri, 17 Jun 2016 23:40:26 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Custom FPGA image without UHD on X3x0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Christian,
On 17.06.2016 22:14, Christian Schr?der via USRP-users wrote:
> Dear All,
>
> I was wondering if it is possible to program a custom FPGA image onto
> a X3x0 USRP (with CBX daughterboards) without using the UHD
> implementation.
Yes, but you'd be reinventing the proverbial wheel ? it's not trivial to
bring a board as complex as the X3xx to work at all. There's *a lot* of
finely-tuned timing involved, non-trivial things like handling the
10GEmac, etc.
The CBX isn't trivial either: the knowledge which registers of the
synthesizers to poke with what value is contained in the host code ?
simply because there's little flexibility to be gained by "knowing" the
inner workings in the FPGA, and a lot of complexity to be avoided by
doing the hardware configuration by sending the right commands from
software through network to a SPI/I?C/GPIO controller in the FPGA.
> With the custom FPGA image all the hardware components connected to
> the FPGA should be controlled through our own IP modules.
> Additionally, a connected host PC must serve as a controlling device.
> Signal processing will be solely implemented on the FPGA.
> I've found the related schematics of both X3x0 USRP and CBX
> daughterboard as well as the specifications of the respective
> components (AD/DA converter etc.). In my understanding it should be
> possible to implement all necessary FPGA modules (like SPI master,
> Ethernet towards host PC etc.) to control all of the hardware components.
> Now here's the question that bothers me: Am I missing something? Is
> there anything I have to consider before?
Well, the digital part is easily half of the engineering effort that
went into the X3xx ? you're free to replace it, but it'd probably take
you very long to get something that works even on a basic level.
Why would you want to do something like that? Can you tell us a little
more about why your specific application needs this?
Also, have you heard about RFNoC? It's meant for people that want to
place their own DSP chain on the USRP, but not rewrite the basic "let me
get samples from the ADC and to the DAC, run these at some sensible
frequency, and make sure that basically the DSP is sound" functionality.
RFNoC is basically the idea of letting users write IP blocks that can
easily be dropped into the existing framework.
Best regards,
Marcus
------------------------------
Message: 9
Date: Fri, 17 Jun 2016 23:45:01 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Ishwar,
I haven't used srsLTE, but if things stop working with an MTU > 5000,
then that's your maximum MTU size. The X3xx supports bigger frames over
network, but there's very little Gigabit ethernet cards that support
Jumbo Frames larger than 4KB.
So simply leave the MTU at e.g. 4096. If you still get U's, then you'll
probably need a faster computer, or other network settings can be
improved. I don't know which network card or OS you're using, but at
high rates, you should definitely make sure that interrupt coalescing is
set to a sensible value.
Best regards,
Marcus
On 14.06.2016 18:11, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
>
>
> Has anyone been running srsLTE software on X300? I have not had much
> luck with it. I have tried different X300 FPGA versions (15.0 & 20.0)
> but could not get pdsch_enodeb test app to work.
>
>
>
> I am connected to the X300 box on GigE interface. If the mtu value is
> left at default (1500) value, then I get continuous Underruns. If I
> increase the MTU value to a large value (> 5000), then I get following
> error.
>
>
>
> UHD Error:
>
> x300 fw communication failure #1
>
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
>
>
>
> If anyone has this test-app running, can you please let me know what
> version of FPGA & UHD Host drivers you are using? Also, how X300 box
> is connected to PC that is running the test app.
>
>
>
> I am using quad-core machine with following x86 CPU.
>
> model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
>
> I don?t have any other app running on this machine ( which could
> starve the test app).
>
>
>
> Strange thing is that the pdsch_ue app does not give this error.
>
>
>
> Any help will be greatly appreciated.
>
>
>
> Note: I asked for help on srsLTE mailing list and author asked me to
> run the question by this mailing list.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the
> taking of any action based upon reliance on the contents of this
> transmission is strictly forbidden. If you have received this message
> in error please notify the sender by return e-mail and delete it from
> your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/c45b2a05/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 17 Jun 2016 15:24:03 -0700
From: Michael West <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID:
<cam4xkrogmvxharhjzmrl5z-ixdpghrn9oma_8xaoqmmmcrp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Try increasing the default socket buffer size when using larger MTU sizes.
When using the Intel X710-DAO 10 GbE NIC, we found it was necessary to
increase the default socket buffer size when using an MTU >3000 or we would
get firmware communication or radio control errors. I also recommend
increasing the number of tx and rx descriptors on the interface.
Regards,
Michael
On Fri, Jun 17, 2016 at 2:45 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Ishwar,
>
> I haven't used srsLTE, but if things stop working with an MTU > 5000, then
> that's your maximum MTU size. The X3xx supports bigger frames over network,
> but there's very little Gigabit ethernet cards that support Jumbo Frames
> larger than 4KB.
> So simply leave the MTU at e.g. 4096. If you still get U's, then you'll
> probably need a faster computer, or other network settings can be improved.
> I don't know which network card or OS you're using, but at high rates, you
> should definitely make sure that interrupt coalescing is set to a sensible
> value.
>
> Best regards,
>
> Marcus
> On 14.06.2016 18:11, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
>
>
> Has anyone been running srsLTE software on X300? I have not had much luck
> with it. I have tried different X300 FPGA versions (15.0 & 20.0) but could
> not get pdsch_enodeb test app to work.
>
>
>
> I am connected to the X300 box on GigE interface. If the mtu value is left
> at default (1500) value, then I get continuous Underruns. If I increase the
> MTU value to a large value (> 5000), then I get following error.
>
>
>
> UHD Error:
>
> x300 fw communication failure #1
>
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
>
>
>
> If anyone has this test-app running, can you please let me know what
> version of FPGA & UHD Host drivers you are using? Also, how X300 box is
> connected to PC that is running the test app.
>
>
>
> I am using quad-core machine with following x86 CPU.
>
> model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
>
> I don?t have any other app running on this machine ( which could starve
> the test app).
>
>
>
> Strange thing is that the pdsch_ue app does not give this error.
>
>
>
> Any help will be greatly appreciated.
>
>
>
> Note: I asked for help on srsLTE mailing list and author asked me to run
> the question by this mailing list.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the taking of
> any action based upon reliance on the contents of this transmission is
> strictly forbidden. If you have received this message in error please
> notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/2c5faf19/attachment-0001.html>
------------------------------
Message: 11
Date: Sat, 18 Jun 2016 01:02:31 +0200
From: Marcus M?ller <[email protected]>
To: "Jasuja, Ishwar"
<[email protected]>,[email protected]
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The U might really not be a network problem - LTE is usually pretty CPU hungry,
and it might simply be the case that your computer is too busy handling all the
lte DSP to keep up with the sampling rate; that would be my intuition.
Best regards,
Marcus
Am 18. Juni 2016 00:44:55 MESZ, schrieb "Jasuja, Ishwar"
<[email protected]>:
>Thanks Marcus,
>
>The sampling rate set by pdsch_enodeb is only 5.76 M. I was under
>impression that any off the shelf (1G) NIC card should be able to
>support that rate. I tried bring the nof_prb down to 6 which brings the
>sampling rate down to 1.92 MHz and I still get underruns.
>
>I am using mint Linux (kernel version 3.18.9). The NIC in there is
>following:
>01:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network
>Connection (rev 02)
>
>I can run the example app from Ettus (tx_samples_c) at sampling rates
>of 10M, 20M & 25M and that does not give me any underrun issues. That
>is why I am not suspecting X300 FPGA or UHD API code. There has to be
>something in srsLTE UHD initialization code which is causing this. That
>is my wild guess. :)
>
>I know for sure that the computer is fast enough as I have been able
>to run 802.11n PHY (40Mhz channel bandwidth & 40M samples/sec) with
>some other SDR hardware though.
>
>I will try 10G Ethernet NIC in that PC and see how it goes.
>
>Thanks again,
>Ishwar
>
>From: USRP-users [mailto:[email protected]] On Behalf
>Of Marcus M?ller via USRP-users
>Sent: Friday, June 17, 2016 2:45 PM
>To: [email protected]
>Subject: Re: [USRP-users] srsLTE & X300 box.
>
>
>Hi Ishwar,
>
>I haven't used srsLTE, but if things stop working with an MTU > 5000,
>then that's your maximum MTU size. The X3xx supports bigger frames over
>network, but there's very little Gigabit ethernet cards that support
>Jumbo Frames larger than 4KB.
>So simply leave the MTU at e.g. 4096. If you still get U's, then you'll
>probably need a faster computer, or other network settings can be
>improved. I don't know which network card or OS you're using, but at
>high rates, you should definitely make sure that interrupt coalescing
>is set to a sensible value.
>
>Best regards,
>
>Marcus
>On 14.06.2016 18:11, Jasuja, Ishwar via USRP-users wrote:
>Hi,
>
>Has anyone been running srsLTE software on X300? I have not had much
>luck with it. I have tried different X300 FPGA versions (15.0 & 20.0)
>but could not get pdsch_enodeb test app to work.
>
>I am connected to the X300 box on GigE interface. If the mtu value is
>left at default (1500) value, then I get continuous Underruns. If I
>increase the MTU value to a large value (> 5000), then I get following
>error.
>
>UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
>
>If anyone has this test-app running, can you please let me know what
>version of FPGA & UHD Host drivers you are using? Also, how X300 box is
>connected to PC that is running the test app.
>
>I am using quad-core machine with following x86 CPU.
>model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
>I don't have any other app running on this machine ( which could starve
>the test app).
>
>Strange thing is that the pdsch_ue app does not give this error.
>
>Any help will be greatly appreciated.
>
>Note: I asked for help on srsLTE mailing list and author asked me to
>run the question by this mailing list.
>
>Thanks,
>Ishwar
>
>
>
>
>
>Spirent Communications e-mail confidentiality.
>------------------------------------------------------------------------
>This e-mail contains confidential and / or privileged information
>belonging to Spirent Communications plc, its affiliates and / or
>subsidiaries. If you are not the intended recipient, you are hereby
>notified that any disclosure, copying, distribution and / or the taking
>of any action based upon reliance on the contents of this transmission
>is strictly forbidden. If you have received this message in error
>please notify the sender by return e-mail and delete it from your
>system.
>
>Spirent Communications plc
>Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
>Kingdom.
>Tel No. +44 (0) 1293 767676
>Fax No. +44 (0) 1293 767677
>
>Registered in England Number 470893
>Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
>9XN, United Kingdom.
>
>Or if within the US,
>
>Spirent Communications,
>27349 Agoura Road, Calabasas, CA, 91301, USA.
>Tel No. 1-818-676- 2300
>
>
>
>
>_______________________________________________
>
>USRP-users mailing list
>
>[email protected]<mailto:[email protected]>
>
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160618/1f418c01/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 17 Jun 2016 21:57:18 -0700
From: Ian Buckley <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Custom FPGA image without UHD on X3x0
Message-ID:
<cam_0ocepeskeqp43fgheebo6pebedb-qrojufpsdz43lhme...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Christian,
I've done similar projects on other USRP's, (100% custom RTL)
One thing thats not initially obvious that you are going to likely run into
on X300, is that it incorporates a proprietary ASIC with no published
information that implements the PCIe interface. Unfortunately this device
also programs the FPGA configuration, there is no directly attached Flash.
Thus if you wish to retain a configuration across power cycles/resets you
will have to reverse engineer the functionality needed to program and boot
the Flash via the ASIC and also retain the National Instruments RTL that
interfaces to this ASIC. If you are happy to just load images via JTAG,
then of course you can largely just ignore this.
Aside from that it's a relatively straight forward platform, though some of
the high speed interfaces require a lot of attention to detail and you need
to be sure you have schematics that match your H/W rev exactly. I assume
you already understand the considerable magnitude of the task(s) and that
application support for a bare metal design will be minimal.
-Ian
On Fri, Jun 17, 2016 at 2:40 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Christian,
>
>
> On 17.06.2016 22:14, Christian Schr?der via USRP-users wrote:
> > Dear All,
> >
> > I was wondering if it is possible to program a custom FPGA image onto
> > a X3x0 USRP (with CBX daughterboards) without using the UHD
> > implementation.
> Yes, but you'd be reinventing the proverbial wheel ? it's not trivial to
> bring a board as complex as the X3xx to work at all. There's *a lot* of
> finely-tuned timing involved, non-trivial things like handling the
> 10GEmac, etc.
> The CBX isn't trivial either: the knowledge which registers of the
> synthesizers to poke with what value is contained in the host code ?
> simply because there's little flexibility to be gained by "knowing" the
> inner workings in the FPGA, and a lot of complexity to be avoided by
> doing the hardware configuration by sending the right commands from
> software through network to a SPI/I?C/GPIO controller in the FPGA.
> > With the custom FPGA image all the hardware components connected to
> > the FPGA should be controlled through our own IP modules.
> > Additionally, a connected host PC must serve as a controlling device.
> > Signal processing will be solely implemented on the FPGA.
> > I've found the related schematics of both X3x0 USRP and CBX
> > daughterboard as well as the specifications of the respective
> > components (AD/DA converter etc.). In my understanding it should be
> > possible to implement all necessary FPGA modules (like SPI master,
> > Ethernet towards host PC etc.) to control all of the hardware components.
> > Now here's the question that bothers me: Am I missing something? Is
> > there anything I have to consider before?
> Well, the digital part is easily half of the engineering effort that
> went into the X3xx ? you're free to replace it, but it'd probably take
> you very long to get something that works even on a basic level.
>
> Why would you want to do something like that? Can you tell us a little
> more about why your specific application needs this?
>
> Also, have you heard about RFNoC? It's meant for people that want to
> place their own DSP chain on the USRP, but not rewrite the basic "let me
> get samples from the ADC and to the DAC, run these at some sensible
> frequency, and make sure that basically the DSP is sound" functionality.
> RFNoC is basically the idea of letting users write IP blocks that can
> easily be dropped into the existing framework.
>
> Best regards,
> Marcus
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160617/4a492281/attachment-0001.html>
------------------------------
Message: 13
Date: Sat, 18 Jun 2016 10:05:18 +0200
From: Marcus M?ller <[email protected]>
To: "Jasuja, Ishwar" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Ishwar,
On 06/18/2016 07:56 AM, Jasuja, Ishwar wrote:
>
> CPU utilization never goes above 90%.
>
But 90% is very high! What you're looking at is not the maximum CPU
utilization over the last few seconds, but either an average or an
instantaneous value!
Notice that Us might not only be caused by your system being not fast
enought /on average/, each U is a point in time where the transmit
buffer in the USRP ran empty ? leaving the USRP with nothing to
transmit, while the DAC must continue to run.
>
> And all I see is constant stream of U getting sprayed on my console. I
> can understand occasional underrun if CPU utilization was going high
> every once in a while.
>
>
>
> Something just does not add up here. I am surprised srsLTE guys have
> not tested this recently although they claim on their website that
> their software works fine with X300.
>
I'd assume they've tested it; having seen some of their work in person
(been at FOSDEM), I'd say they do solid work; they don't gain anything
by claiming something works that doesn't.
>
> I am running this software on Haswell running at 4GHz. Do you
> recommend any other x86 CPU that I can try?
>
This is not the same core i5-5200 @3.3GHz you mentioned earlier?
Anyway, I think the way to get this to work is probably not by buying a
faster PC, but to identify the actual bottleneck, and to see what you
can do about them
>
>
>
> Software has to be doing something ?really strange? to get Underruns
> at a sampling rate of 5.7 MHz.
>
Not at all ? 5.7MS/s is still a lot of data, and the fact that we can
push through much more when not doing processing is a feat of
optimization in all, network or USB drivers, operating system
schedulers, UHD type conversion and application multithreading, not
something that would work out of the box on a machine with naively
implemented infrastructure. Also, latency is a critical issue here.
Now, as mentioned, LTE isn't really CPU-friendly ? aside from a few
FFTs, there's very much equalizing, synchronization and channel
(de)coding to be done, all of which take up quite some CPU cycles, and
potentially memory bandwidth.
>
>
> I was hoping to get this running without going into too much detail of
> srsLTE software. If I cannot get the basic thing working at such a low
> sampling rate, it is hard to justify the use of that open source
> package and the hardware to upper management.
>
> Esp when that package only supports release 8 features of LTE Phy.
>
>
>
Well, we're not affiliated with srsLTE, so as much as I like srs' free
software approach, we're no more versed in using srsLTE than you are
(probably less ? I personally haven't tried it), and also, we can't
support products that aren't ours. We'll try our best to make things
work for you by applying all knowledge we have on our devices, drivers,
and SDR architectures in general, but we're no experts in /all/ software
that uses our devices.
However, I'm pretty sure that the people behind srsLTE would probably
know better than I do how to optimize their software ? all I, and other
Ettus folks, can do is help you optimize the usage of the UHD driver,
and that includes the set up of networking, which is the nr. 1
performance killer on the UHD side for the X310. After the samples
"leave" UHD, either by being sent as network packets through your
operating systems network stack, or by being written to a buffer in your
application software, there's really nothing we can do than to make the
handling of everything as smooth as possible while it's "inside" UHD.
Hence our focus on dealing wiht what we know can influence performance.
Just a quick check: you're not using any network switch, virtualization
or firewall in between your PC and your X300? Also, which version of
Linux are you running? What's the output of ethtool -c ${your ethernet
device's name, e.g. eth0} ?
I've taken the liberty to "stalk" you a bit and read through your
submissions in the srsLTE-users mailing list archive. That was an
interesting read!
So, the point is that the N210 seems to able to transmit, at least,
though everything will be totally broken, because it can't support the
5.72MS/s rate. Now, the N210 and the X300 are really not that different
as an architecture ? the X300 definitely isn't any more "data-hungry";
in fact, with the X3xx we introduced a compressed header format, which
should actually reduce complexity and overhead for the computer. So my
guess is that if the sampling rate works, then srsLTE might be able try
and do useful processing with the received signal ? which typically is
much more CPU-intense than what happens on the transmit side.
So, I don't /think/ this is an issue with your USRP (which really
doesn't care what kind of operation runs on your PC, and will just throw
Us when it runs out of samples to send) or UHD. However, I think we
would both like to /know/, right?
Now, I don't know how to properly profile srsUE/LTE (not having had any
involvement in the software so far). I guess a post to their mailing
list asking how to identify a bottleneck would be smarter than just
poking around; also, they'd probably hear about what goes wrong where ?
after all, by a quick glance at their code and usage of VOLK (which is
an awesome hardware optimized processing library), they're going through
quite some effort to make srsUE/LTE work fast enough on modern hardware.
My immediate approach would be (you could share this with the mailing
list, maybe they have something to say about it):
1. compile both srsLTE and srsUE after configuration with cmake
-DCMAKE_BUILD_TYPE=RelWithDebInfo ..
2. use the Linux perf tool to get a recording of where CPU is spent
when running:
1. Enable perf profiling for normal users, including the ability to
inspect what's happening in the kernel:
sudo sysctl kernel/perf_event_paranoid=-1
2. Run the application of choice, recording what's happening:
perf record -ag ${the srs application you want to profile}
3. Then, analyze the resulting perf data:
perf report --sort=dso,cpu,comm
3. analyze the results: UHD's most intense task should probably be the
converter (which has the "side effect" of being in charge of getting
the data out of the network buffer into your program's sample
buffer, whilst converting the on-the-wire sample format to something
your CPU can deal with).
Now, the result can be that there is a CPU hog somewhere ? maybe a
network driver in the kernel, maybe actualy somethin in UHD, or maybe
some routine in srsLTE runs rampant. Or there might not be, and then we
that the reason your computer is not sending the samples in time to the
USRP is something architectural.
Hope we can figure something out!
Best regards,
Marcus
>
>
>
> *From:*Marcus M?ller [mailto:[email protected]]
> *Sent:* Friday, June 17, 2016 10:45 PM
> *To:* Jasuja, Ishwar; Michael West
> *Subject:* Re: [USRP-users] srsLTE & X300 box.
>
>
>
> That's pretty high, because a short increase would be totally
> sufficient to let your system lose step, and that would lead to an
> Underrun.
>
> Best regards,
> Marcus
>
> On 06/18/2016 02:03 AM, Jasuja, Ishwar wrote:
>
> The total CPU utilization hovers around 80-85 %
>
>
>
> *From:*Michael West [mailto:[email protected]]
> *Sent:* Friday, June 17, 2016 4:49 PM
> *To:* Jasuja, Ishwar
> *Cc:* Marcus M?ller
> *Subject:* Re: [USRP-users] srsLTE & X300 box.
>
>
>
> Hi Ishwar,
>
> Increasing the default socket buffer size was to eliminate the
> firmware communication errors when using larger MTU sizes. Please
> increase your MTU size to 9000. Also, try increasing the number
> of descriptors for the interface:
>
> > sudo ethtool -G eth<N> rx 4096 tx 4096
>
> And disable interrupt coalescing on the TX side:
>
> > sudo ethtool -C eth<N> adaptive-tx off
>
> If all that doesn't do it, I believe Marcus may be correct about
> the CPU being too busy to keep up with the TX stream. Check
> 'htop' to see what the overall CPU load is and if any of the cores
> is going over 90%.
>
>
>
> Regards,
>
> Michael
>
>
>
> On Fri, Jun 17, 2016 at 4:34 PM, Jasuja, Ishwar
> <[email protected] <mailto:[email protected]>> wrote:
>
> Just tried it. Still getting Underruns.
>
>
>
> Cut & pasting output of that test app here. Just in case if you
> notice anything..
>
>
>
>
>
> Opening RF device...
>
> Opening USRP with args:
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> -- Loading values from EEPROM...
>
> -- Setup RF frontend clocking...
>
> -- Radio 1x clock:200
>
> -- Initialize Radio0 control...
>
> -- Performing register loopback test... pass
>
> -- Initialize Radio1 control...
>
> -- Performing register loopback test... pass
>
> Trying to dynamically change Master clock...
>
> Master clock is configurable. Using reduced symbol sizes and
> sampling rates.
>
> Setting sampling rate 1.92 MHz
>
> Set TX gain: 31.5 dB
>
> Set TX freq: 2400.00 MHz
>
> - Resource Allocation Type: Type 0
>
> + Resource Block Group Size: 1
>
> + RBG Bitmap: 0x3f
>
> - Modulation and coding scheme index: 1
>
> - HARQ process: 0
>
> - New data indicator: No
>
> - Redundancy version: 0
>
> - TPC command for PUCCH: --
>
> - PRB Bitmap Assignment 0st slot:
>
> 0, 1, 2, 3, 4, 5,
>
> - PRB Bitmap Assignment 1st slot:
>
> 0, 1, 2, 3, 4, 5,
>
> - Number of PRBs: 6
>
> - Modulation type: QPSK
>
> - Transport block size: 208
>
> Type new MCS index and press Enter:
>
> UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
>
>
>
> *From:*Michael West [mailto:[email protected]
> <mailto:[email protected]>]
> *Sent:* Friday, June 17, 2016 4:26 PM
> *To:* Jasuja, Ishwar
> *Cc:* Marcus M?ller
>
>
> *Subject:* Re: [USRP-users] srsLTE & X300 box.
>
>
>
> Hi Ishwar,
>
> You need to change the default in addition to the max. Run 'sudo
> sysctl -w net.core.rmem_default=33554432'.
>
> Regards,
>
> Michael
>
>
>
> On Fri, Jun 17, 2016 at 3:59 PM, Jasuja, Ishwar
> <[email protected] <mailto:[email protected]>> wrote:
>
> srsLTE authors claim that their software works on X300 hardware
> and they are the ones who asked me to ping people on this group.
>
> I was hoping that there is some soul out there who is currently
> running what I am trying to do.
>
>
>
> Apparently, srsLTE guys only run their latest stuff on B210
> hardware with USB interface to Host. (I don?t have that box). Now
> don?t tell me ..?We can sell you one!!?
>
>
>
> I tried N210 with Ethernet interface to host and have not had much
> luck. Sampling rate on that box is not compatible with LTE.
>
>
>
> Note: Please do not forward this email to the mailing list.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
> *From:*Jasuja, Ishwar
> *Sent:* Friday, June 17, 2016 3:49 PM
> *To:* 'Michael West'; Marcus M?ller
> *Subject:* RE: [USRP-users] srsLTE & X300 box.
>
>
>
> Michael,
>
>
>
> I have done that already. (both rmem_max & wmem_max)
>
>
>
> UHD API is kind enough to print out a warning message otherwise.
>
> *Please run: sudo sysctl -w net.core.rmem_max=33554432*
>
>
>
> I will get hold of a 10 Gbe NIC card and try what you have suggested.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Michael West via USRP-users
> *Sent:* Friday, June 17, 2016 3:24 PM
> *To:* Marcus M?ller
> *Cc:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] srsLTE & X300 box.
>
>
>
> Try increasing the default socket buffer size when using larger
> MTU sizes. When using the Intel X710-DAO 10 GbE NIC, we found it
> was necessary to increase the default socket buffer size when
> using an MTU >3000 or we would get firmware communication or radio
> control errors. I also recommend increasing the number of tx and
> rx descriptors on the interface.
>
>
>
> Regards,
>
> Michael
>
>
>
> On Fri, Jun 17, 2016 at 2:45 PM, Marcus M?ller
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hi Ishwar,
>
> I haven't used srsLTE, but if things stop working with an MTU >
> 5000, then that's your maximum MTU size. The X3xx supports bigger
> frames over network, but there's very little Gigabit ethernet
> cards that support Jumbo Frames larger than 4KB.
> So simply leave the MTU at e.g. 4096. If you still get U's, then
> you'll probably need a faster computer, or other network settings
> can be improved. I don't know which network card or OS you're
> using, but at high rates, you should definitely make sure that
> interrupt coalescing is set to a sensible value.
>
> Best regards,
>
> Marcus
>
> On 14.06.2016 18:11, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
>
>
> Has anyone been running srsLTE software on X300? I have not
> had much luck with it. I have tried different X300 FPGA
> versions (15.0 & 20.0) but could not get pdsch_enodeb test app
> to work.
>
>
>
> I am connected to the X300 box on GigE interface. If the mtu
> value is left at default (1500) value, then I get continuous
> Underruns. If I increase the MTU value to a large value (>
> 5000), then I get following error.
>
>
>
> UHD Error:
>
> x300 fw communication failure #1
>
> EnvironmentError: IOError: x300 fw poke32 - reply timed out
>
>
>
> If anyone has this test-app running, can you please let me
> know what version of FPGA & UHD Host drivers you are using?
> Also, how X300 box is connected to PC that is running the test
> app.
>
>
>
> I am using quad-core machine with following x86 CPU.
>
> model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
>
> I don?t have any other app running on this machine ( which
> could starve the test app).
>
>
>
> Strange thing is that the pdsch_ue app does not give this error.
>
>
>
> Any help will be greatly appreciated.
>
>
>
> Note: I asked for help on srsLTE mailing list and author asked
> me to run the question by this mailing list.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
>
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged
> information belonging to Spirent Communications plc, its
> affiliates and / or subsidiaries. If you are not the intended
> recipient, you are hereby notified that any disclosure,
> copying, distribution and / or the taking of any action based
> upon reliance on the contents of this transmission is strictly
> forbidden. If you have received this message in error please
> notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
> United Kingdom.
> Tel No. +44 (0) 1293 767676 <tel:%2B44%20%280%29%201293%20767676>
> Fax No. +44 (0) 1293 767677 <tel:%2B44%20%280%29%201293%20767677>
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West
> Sussex, RH10 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300 <tel:1-818-676-%202300>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected] <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160618/6785ec4a/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 70, Issue 18
******************************************
