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: srsLTE & X300 box. (Jasuja, Ishwar)
2. Re: srsLTE & X300 box. (Jasuja, Ishwar)
3. Re: srsLTE & X300 box. (Jasuja, Ishwar)
4. srsLTE & X300 box. (Jasuja, Ishwar)
5. Re: srsLTE & X300 box. (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Sat, 18 Jun 2016 16:04:39 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID:
<by2pr1001mb106132117c9d0b112e3b2cbdec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
I am sorry Marcus & srsLTE folks. I might have said things which were not
appropriate. I apologize.
It is just that I was frustrated.
I have tried this on both Haswell processor & the one I mentioned before. But
the machine with Haswell CPU has lot of the other stuff loaded on it ( various
UHD versions, gcc-5.3,?)
So I decided to start afresh. Loaded everything from scratch. Also reduced the
sampling rate to 1.9M(by reducing no_prb to 6) but no luck.
The fact that tx_samples_c works fine on this machine puzzled me more and did
not give me much clues.
I am going to start digging deep into pdsch_enodeb code and see what is going
on there and try to do some profiling as you suggested. I was just trying to
avoid going down that path.
Thanks,
Ishwar
From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, June 18, 2016 1:05 AM
To: Jasuja, Ishwar; [email protected]
Subject: Re: [USRP-users] srsLTE & X300 box.
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:
* Enable perf profiling for normal users, including the ability to
inspect what's happening in the kernel:
sudo sysctl kernel/perf_event_paranoid=-1
* Run the application of choice, recording what's happening:
perf record -ag ${the srs application you want to profile}
* 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/076fc2ea/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 18 Jun 2016 18:17:50 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID:
<by2pr1001mb106107b941bf899e9480649fec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
I have been going through the srsLTE example code. Found a minor issue. It is
generating LTE sub-frames in a while loop. It should be generating sub-frame
once every 1ms. So it needs to have some breather between two successive
sub-frames.
I added a code (quick & dirty) to make sure it generates ~1000
sub-frames/second. This brings the CPU utilization down to 25% from 85%. But
still getting underrun errors. At least some progress?.
I could not get perf to install. Looks like pre-req it is looking for do not
exist for kernel version I have. I will go back to kernel version that has
those pre-reqs (linux-tools-common-3.18.9, linux-cloud-tools-3.18.9)
Ishwar
From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, June 18, 2016 1:05 AM
To: Jasuja, Ishwar; [email protected]
Subject: Re: [USRP-users] srsLTE & X300 box.
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:
* Enable perf profiling for normal users, including the ability to
inspect what's happening in the kernel:
sudo sysctl kernel/perf_event_paranoid=-1
* Run the application of choice, recording what's happening:
perf record -ag ${the srs application you want to profile}
* 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/a44891fb/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 18 Jun 2016 20:49:19 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID:
<by2pr1001mb10619d6403a3cec0473cba16ec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
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.
>> Pdsch_enodeb test application that I am running is only doing downlink
>> transmit part. So there is no rx processing involved at all. Typically in an
>> OFDM PHY, transmit path is much faster than the receive path.
>From my experience, the thread that does the transmit (scrambling, mapping,
>interleaving & iFFT) consumes way less CPU than what is required by recv code;
>which needs to do CFO correction, FFT, channel estimation using RS (Pilots) ,
>channel equalization, de-mapping , error correction (Viterbi or turbo decoder)
>& unscrambling + verifying CRC.
One thing I am going to try is to pin the x86 core to this thread and see if
that makes any difference. I doubt it will make any difference as the amount of
time used to encode these 1000 sub-frames adds up to less than 200ms out of
total 1 second duration. This tallies with 25% CPU utilization (used by all 4
threads in that example app).
From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, June 18, 2016 1:05 AM
To: Jasuja, Ishwar; [email protected]
Subject: Re: [USRP-users] srsLTE & X300 box.
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:
* Enable perf profiling for normal users, including the ability to
inspect what's happening in the kernel:
sudo sysctl kernel/perf_event_paranoid=-1
* Run the application of choice, recording what's happening:
perf record -ag ${the srs application you want to profile}
* 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/e2bed1c4/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 19 Jun 2016 01:20:53 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] srsLTE & X300 box.
Message-ID:
<by2pr1001mb1061684af66e0461708c7bcdec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
I have some more information now. I have sprinkled the debug messages in
srsLTE?s transmit handler to understand the tx behavior and here is what is
happening.
The sampling rate is set to 1.92 MHz as I have ?no_prb set to 6. (i.e channel
bandwidth=1MHz). Most conservative transmit case.
The code is sending 1920 samples every 1ms. This matches with sampling rate &
channel bandwidth
start_of_burst field (in tx_metadata) is marked as 1 very first time
uhd_tx_streamer_send() is called. All subsequent calls, this field is set to 0.
The call always succeeds; returns (last argument) that it transmitted 1920
samples.
Time_spec is updated by 0.001 after evert uhd_tx_streamer_send() call.
End_of_burst field is never set to 1. I guess it is telling USRP that it is
going to keep pumping 1920 samples every 1ms.
So now the question is,
What if it cannot come back and issue tx for 1920 samples in time?? USRP
not going to like it??
If I do not have the breather between two consecutive tx calls, it is going to
keep pumping samples at a rate faster than the tx_sampling rate? How does
USRP(FPGA) react in that case?
Thanks for all your help. I think we are starting to get closer to the root
cause of this.
Regards,
Ishwar
From: USRP-users [mailto:[email protected]] On Behalf Of
Jasuja, Ishwar via USRP-users
Sent: Saturday, June 18, 2016 1:49 PM
To: Marcus M?ller; [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
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.
>> Pdsch_enodeb test application that I am running is only doing downlink
>> transmit part. So there is no rx processing involved at all. Typically in an
>> OFDM PHY, transmit path is much faster than the receive path.
>From my experience, the thread that does the transmit (scrambling, mapping,
>interleaving & iFFT) consumes way less CPU than what is required by recv code;
>which needs to do CFO correction, FFT, channel estimation using RS (Pilots) ,
>channel equalization, de-mapping , error correction (Viterbi or turbo decoder)
>& unscrambling + verifying CRC.
One thing I am going to try is to pin the x86 core to this thread and see if
that makes any difference. I doubt it will make any difference as the amount of
time used to encode these 1000 sub-frames adds up to less than 200ms out of
total 1 second duration. This tallies with 25% CPU utilization (used by all 4
threads in that example app).
From: Marcus M?ller [mailto:[email protected]]
Sent: Saturday, June 18, 2016 1:05 AM
To: Jasuja, Ishwar;
[email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
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:
* Enable perf profiling for normal users, including the ability to
inspect what's happening in the kernel:
sudo sysctl kernel/perf_event_paranoid=-1
* Run the application of choice, recording what's happening:
perf record -ag ${the srs application you want to profile}
* 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/20160619/30194c85/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 19 Jun 2016 10:16:55 +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,
if your USRP expects samples, and it will do that after every packet of
samples, as long as neither the "SEND_N_SAMPLES_AND_DONE" streaming mode
is used nor the end-of-burst flag was set, then it will send a
"U"nderrun notification when the samples aren't there in time. That's
exactly the job of these "U"s! If the following packet, with a valid tx
timestamp, reaches the USRP before its "too late", then things will
still work out ? which is the reason why doing the while() loop is
probably right, and sleeping in between is definitely wrong. You need to
be faster at sending than the USRP is at consuming, in general (on a
long-term average, you will be exactly as fast at sending as the USRP is
at consuming samples, but that must happen because the USRP at one point
throttles you).
I must admit that I really don't know how the srs libraries work
internally, and I can not really help you with that, sorry.
Best regards,
Marcus
On 06/19/2016 03:20 AM, Jasuja, Ishwar via USRP-users wrote:
>
>
>
> Marcus,
>
>
>
> I have some more information now. I have sprinkled the debug messages
> in srsLTE?s transmit handler to understand the tx behavior and here
> is what is happening.
>
>
>
> The sampling rate is set to 1.92 MHz as I have ?no_prb set to 6. (i.e
> channel bandwidth=1MHz). Most conservative transmit case.
>
>
>
> The code is sending 1920 samples every 1ms. This matches with sampling
> rate & channel bandwidth
>
>
>
> start_of_burst field (in tx_metadata) is marked as 1 very first time
> uhd_tx_streamer_send() is called. All subsequent calls, this field is
> set to 0. The call always succeeds; returns (last argument) that it
> transmitted 1920 samples.
>
>
>
> Time_spec is updated by 0.001 after evert uhd_tx_streamer_send() call.
>
>
>
> End_of_burst field is never set to 1. I guess it is telling USRP that
> it is going to keep pumping 1920 samples every 1ms.
>
>
>
> So now the question is,
>
> What if it cannot come back and issue tx for 1920 samples in
> time?? USRP not going to like it??
>
>
>
> If I do not have the breather between two consecutive tx calls, it is
> going to keep pumping samples at a rate faster than the tx_sampling
> rate? How does USRP(FPGA) react in that case?
>
>
>
> Thanks for all your help. I think we are starting to get closer to the
> root cause of this.
>
>
>
> Regards,
>
> Ishwar
>
>
>
>
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Jasuja, Ishwar via USRP-users
> *Sent:* Saturday, June 18, 2016 1:49 PM
> *To:* Marcus M?ller; [email protected]
> <mailto:[email protected]>
> *Subject:* Re: [USRP-users] srsLTE & X300 box.
>
>
>
> 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.
>
> >> Pdsch_enodeb test application that I am running is only doing
> downlink transmit part. So there is no rx processing involved at all.
> Typically in an OFDM PHY, transmit path is much faster than the
> receive path.
>
> From my experience, the thread that does the transmit (scrambling,
> mapping, interleaving & iFFT) consumes way less CPU than what is
> required by recv code; which needs to do CFO correction, FFT, channel
> estimation using RS (Pilots) , channel equalization, de-mapping ,
> error correction (Viterbi or turbo decoder) & unscrambling + verifying
> CRC.
>
>
>
> One thing I am going to try is to pin the x86 core to this thread and
> see if that makes any difference. I doubt it will make any difference
> as the amount of time used to encode these 1000 sub-frames adds up to
> less than 200ms out of total 1 second duration. This tallies with 25%
> CPU utilization (used by all 4 threads in that example app).
>
>
>
>
>
> *From:*Marcus M?ller [mailto:[email protected]]
> *Sent:* Saturday, June 18, 2016 1:05 AM
> *To:* Jasuja, Ishwar; [email protected]
> <mailto:[email protected]>
> *Subject:* Re: [USRP-users] srsLTE & X300 box.
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20160619/1b6b9cf7/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 19
******************************************
