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. X310 Twin RX coherence (Parth Vakil)
2. Re: Wireless data transfer (do ber)
3. Re: Wireless data transfer (Julian Arnold)
4. Re: Wireless data transfer (Marcus M?ller)
5. Re: Wireless data transfer (Julian Arnold)
6. Re: Asymmetry in achievable TX/RX rates (Claudio Cicconetti)
7. Re: Asymmetry in achievable TX/RX rates (Stefano Bettelli)
8. Cannot se sent out signal in oscilloscope (Carin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Feb 2017 20:03:41 +0000
From: Parth Vakil <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 Twin RX coherence
Message-ID:
<bn6pr07mb2900b8f9fd15f679e18fbcb9c5...@bn6pr07mb2900.namprd07.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am trying to build a system that utilizes 2 TwinRx and X310. I am using RFNoC
radio blocks, FFT and DDCs to utilize the FPGA resources before I bring
narrowband data into GNU Radio for further processing. All of that seems to be
working great.
The issue I am trying to solve is that of coherence between the four channels.
In the past, we have been able to get 4 coherent channels off of the USRP
source by setting up the LO infrastructure so that 3 of the receivers slave off
one master LO. We also had to do timed tune commands to keep the channels
coherent as we would tune away from a specific frequency and back (coherent so
that the phase differences were the same between retunes).
Are there any examples I can look at as reference to set up the LO
infrastructure as well as the timed tune commands to make the RFNoC radio
blocks run coherently as well when I retune? Or is the best way to track the
code from the USRP source commands to the uhd commands that actually tickle the
tuning and LO settings?
Thank you.
PV
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170228/50b4a90f/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 1 Mar 2017 08:24:04 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID:
<CABLDF_eOVT1ZVqD3qi=L=4bwixx2ecuh1ll-cuiovg9pumx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I think I explained my problem in a wrong way. I am normally using GNU
radio and I can synchronize them by using GPSDO. So far there is no
problem.
Lets say there is 1km distance between 2 USRPs. What I am asking is how can
I start two distant USRP's from one computer. How can I get the I/Q data
from them. For example, can I control them via a kind of dongle instead of
an ethernet cable?
In other words, I am saying that the USRPs are far away from me and I
cannot use cables. Is there a wireless solution?
Best regards,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/ff5e8041/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 1 Mar 2017 09:29:33 +0100
From: Julian Arnold <[email protected]>
To: do ber <[email protected]>, [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Ali,
I could imagine that using something like LTE modems in the PCs
controlling the USRPs could be a quick way to get a control channel up
and running.
Also, you could of course try to use the USRPs themselves to establish
the control channel. However, I think this would be more involved than
using an existing mobile network.
Cheers,
Julian
On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
> Hi,
>
> I think I explained my problem in a wrong way. I am normally using GNU
> radio and I can synchronize them by using GPSDO. So far there is no
> problem.
>
> Lets say there is 1km distance between 2 USRPs. What I am asking is how
> can I start two distant USRP's from one computer. How can I get the I/Q
> data from them. For example, can I control them via a kind of dongle
> instead of an ethernet cable?
>
> In other words, I am saying that the USRPs are far away from me and I
> cannot use cables. Is there a wireless solution?
>
> Best regards,
> Ali
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 4
Date: Wed, 01 Mar 2017 10:55:19 +0100
From: Marcus M?ller <[email protected]>
To: Julian Arnold <[email protected]>, Julian Arnold via
USRP-users <[email protected]>, do ber
<[email protected]>
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I'd like to agree with Julian here. IQ data is typically very high-rate, and
you must tell us which rates you need to achieve on your six channels before we
can recommend anything.
Also note that the x3x0 has pretty universally compatible 10 gigabit Ethernet
SFP+ ports, so the most intuitive way would simply be coming up with a
dedicated fibre optic network based e.g. on 10 GBase-LR.
Best regards,
Marcus
Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via USRP-users
<[email protected]>:
>Hi Ali,
>
>I could imagine that using something like LTE modems in the PCs
>controlling the USRPs could be a quick way to get a control channel up
>and running.
>Also, you could of course try to use the USRPs themselves to establish
>the control channel. However, I think this would be more involved than
>using an existing mobile network.
>
>Cheers,
>Julian
>
>On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>> Hi,
>>
>> I think I explained my problem in a wrong way. I am normally using
>GNU
>> radio and I can synchronize them by using GPSDO. So far there is no
>> problem.
>>
>> Lets say there is 1km distance between 2 USRPs. What I am asking is
>how
>> can I start two distant USRP's from one computer. How can I get the
>I/Q
>> data from them. For example, can I control them via a kind of dongle
>> instead of an ethernet cable?
>>
>> In other words, I am saying that the USRPs are far away from me and I
>> cannot use cables. Is there a wireless solution?
>>
>> Best regards,
>> Ali
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>--
>Julian Arnold, M.Sc.
>
>Institute for Networked Systems
>RWTH Aachen University
>
>Kackertstrasse 9
>52072 Aachen
>Germany
>
>_______________________________________________
>USRP-users mailing list
>[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/20170301/b7528e02/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 1 Mar 2017 12:13:37 +0100
From: Julian Arnold <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: Julian Arnold via USRP-users <[email protected]>, do ber
<[email protected]>
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hey,
If I understood it correctly he only needs a control channel to start the
experiment at all locations at the same time. The actual data is then stored on
the local machines. Or did I get that wrong?
Streaming the whole data to a central location would of course be a completely
different story.
Cheers,
Julian Arnold, M.Sc
> On 1 Mar 2017, at 10:55, Marcus M?ller <[email protected]> wrote:
>
> I'd like to agree with Julian here. IQ data is typically very high-rate, and
> you must tell us which rates you need to achieve on your six channels before
> we can recommend anything.
>
> Also note that the x3x0 has pretty universally compatible 10 gigabit Ethernet
> SFP+ ports, so the most intuitive way would simply be coming up with a
> dedicated fibre optic network based e.g. on 10 GBase-LR.
>
> Best regards,
> Marcus
>
> Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via USRP-users
> <[email protected]>:
>>
>> Hi Ali,
>>
>> I could imagine that using something like LTE modems in the PCs
>> controlling the USRPs could be a quick way to get a control channel up
>> and running.
>> Also, you could of course try to use the USRPs themselves to establish
>> the control channel. However, I think this would be more involved than
>> using an existing mobile network.
>>
>> Cheers,
>> Julian
>>
>>> On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>>> Hi,
>>>
>>> I think I explained my problem in a wrong way. I am normally using GNU
>>> radio and I can synchronize them by using GPSDO. So far there is no
>>> problem.
>>>
>>> Lets say there is 1km distance between 2 USRPs. What I am asking is how
>>> can I start two distant USRP's from one computer. How can I get the I/Q
>>> data from them. For example, can I control them via a kind of dongle
>>> instead of an ethernet cable?
>>>
>>> In other words, I am saying that the USRPs are far away from me and I
>>> cannot use cables. Is there a wireless solution?
>>>
>>> Best regards,
>>> Ali
>>>
>>>
>>>
>>>
>>>
>>> USRP-users mailing list
>>> [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/20170301/370d1e45/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 1 Mar 2017 12:20:45 +0100
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hello Stefano,
Do you mind sharing the source code of your modified benchmark_rate?
I would like to give it a try.
Best regards,
Claudio
On 02/28/2017 03:18 PM, Stefano Bettelli via USRP-users wrote:
> No, that?s the entire point of my mail.
> It doesn?t underrun because N is small.
> I can choose N randomly limited between 200?000 and 260?000 and it will still
> fail.
> It seems it doesn?t depend on the actual value, only about its variance.
> I choose such a small rate (1MS/s) exactly to prove the point.
> In another example that I have I can transfer 20MB of data into the UHD, send
> the end-of-burst packet, wait a bit, and only after 200ms or more I start
> receiving the U?s. But I may be extrapolating from too small a number of
> examples. Is there any sort of experiment that I can run to discriminate
> between a real underrun and a bug?
>
> From: [email protected] [mailto:[email protected]]
> Sent: Dienstag, 28. Februar 2017 14:56
> To: Stefano Bettelli <[email protected]>
> Cc: usrp-users <[email protected]>
> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
>
>
> Hi Stephano,
>
> I have spent some time in the packetization code and it is well done, cant
> see any obvious ways to improve efficiency within the host UHD code...
>
> I havent looked at the --random flag, but if it cant keep the buffers full
> based on the tx sample rate because it chooses a streak of small N (too small
> to satisfy the data requirements), then underruns will occur.
> ________________________________
> From: "Stefano Bettelli via USRP-users"
> <[email protected]<mailto:[email protected]>>
> To: "usrp-users"
> <[email protected]<mailto:[email protected]>>
> Sent: Tuesday, February 28, 2017 8:08:03 AM
> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
>
> Dear all,
>
> I want to add some findings to this very interesting thread.
> During the last week I have been playing with the source of the
> benchmark_rate example program.
> In the following examples I will be transmitting at 1MS/s with sc16 for both
> cpu and otw, and TWO channels.
>
> If I run the "stock" benchmark program (which will use 496 samples per buffer
> per channel) and I printout the time it takes to complete the various calls
> to send(), I have the following evolution:
> 10 to 20 calls are executed with times strongly fluctuating in the range 5 -
> 20 microseconds (transient?)
> Several thousand calls are then executed with quite stable call times of 3-5
> microseconds
> Then, as we hit about 16M samples sent (64MB) every 8th call will return
> after 3-4 milliseconds
> So, clearly send() writes to a local buffer ring on the server, then blocks
> when it is filled.
>
> As already noted, it is not necessary to use tx_stream->get_max_num_samps()
> as the number of samples per send buffer. If we provide larger buffers the
> UHD driver will split them for us. So I tried with 2^18 = 262144 samples per
> buffer:
> The first call executes in about 2.3 milliseconds
> The following 30 execute in about 2.0 milliseconds
> Then, as we hit the 16M samples mark, the call time jumps to about 261.6
> milliseconds.
> So, same pattern, same behaviour, but a factor 1000 more in the number of
> samples per buffer per channel.
>
> Then, I tried the same transfer with a variable number of samples, choosing
> between N and 262144 at every send().
> The result is that, without any pattern apparent to me, the benchmark throws
> a lot of U's, unless N is very close to the max value (in my case N ~ 220000,
> but I am not fully sure, it might just be that I didn't wait enough).
>
> Given that we have talked to our USRPs X310 in 2ch mode at 50MS/s without
> errors, I exclude that we are limited by any piece of hardware here. So, my
> question is:
> Is this evidence of a bug / deficiency in the algorithm that splits send()
> buffers inside the UHD driver? Or is there something I did not understand?
> Given that the stock benchmark tool fails with (fake?) underruns at low rates
> when the --random option is used, I would lean towards the first case.
>
> Is there any document where the internals of the UHD driver are explained in
> detail?
>
> Thanks,
> Stefano
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Claudio Cicconetti via USRP-users
> Sent: Montag, 27. Februar 2017 10:01
> To: [email protected]<mailto:[email protected]>
> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
>
> Dear all,
> I have been struggling for a few months to do continuous streaming of
> 100 MS/s towards an X300 with a single 10 GbE on Linux (Ubuntu).
>
> My mission is not yet fully accomplished (see below) but I have a few
> findings to share that may be useful to others:
>
> - data _must_ be ready when you issue the send() command: no way you can do
> processing between consecutive calls to send()
>
> - assigning real-time scheduling priority to the sending thread: surely does
> not harm, but also does _not_ save you from underruns if there are concurrent
> threads on the same core, even if they have best-effort priority
>
> - CPU speed is important but, again, is _not_ a life-saver: I have same
> performance, in terms of rate of underruns, with Intel E5-2660 @ 2.60 GHz and
> Intel i7-6700K @ 4.00 GHz
>
> - fiddling with OS (ie. changing CPU frequency scaling, locking thread to a
> core, disabling IRQ balancing, disabling unused cores) very easily leads to a
> _worse_ performance; on the other hand, I never managed to get any noticeable
> improvements out of these tricks
>
> - NIC interrupt coalescing _must_ be enabled in my case (Intel 82599ES):
> with interrupt coalescing enabled I have about 8000 interrupts/s, which is
> much below the maximum my CPU+OS can sustain (easily 6-7x that)
>
> - for all other network-related configuration the default is sufficient,
> including the number of TX descriptors and network buffers
>
> - the size of the vectors passed to send() does not influence performance; in
> particular, it does _not_ help to split the vector into chunks with a size
> that is a multiple of the maximum samples per packet
>
> The only remaining issue I have is that I get sporadic underruns (in the
> order of one every several minutes, on average) that are periodic with base
> 10 seconds within 0.01 s. For instance, first underrun at 08:22:54.83, next
> could be at 08:31:04.83 and then 08:34:24.83 and so on.
>
> Since the only non-vital daemon running on the PC is sshd, I wonder whether
> it is something related to the OS (Google did help me pin-pointing the issue)
> or to the UHD (something like "every 1 billions samples do something
> special").
>
> Best regards,
> Claudio
>
> On 02/24/2017 10:47 PM, Martin Braun via USRP-users wrote:
>> Stefano,
>>
>> let me just add some statements to this:
>>
>> - In general, it's harder to create data at high rates from a PC and
>> then receive it on the FPGA than vice versa. On top of what Ian said,
>> regular OSes + GPPs have a lot of scheduling latency/randomness. At
>> 100 Msps, on the 3.10 release cycle, you will get an underrun if you
>> miss a chance to transmit a data packet by a small number of ?s (the
>> actual value is hard to tell, but we're speaking of two-digit orders
>> of magnitude). But even 100 ?s scheduling delays are possible. On my
>> machine, I need to tune some knobs until I get this kind of
>> performance, such as using "performance" CPU governors (I also
>> increase the number of Tx descriptors with ethtool -G, but I'm not sure
>> that's as influential.
>> I would still recommend you bump it all the way up to 4096).
>> - With dual-channel, this gets exacerbated because you have multiple
>> threads competing for timely access to the transport device. I would
>> assume that with dual cables, that's not true, but who knows what's
>> going on internally.
>>
>> - On 3.10, we are currently *worse off* than on 3.9 in terms of
>> streaming performance. There's a whole bunch of reasons for that, but
>> the good news is we're currently working on some fixes to improve
>> streaming performance. With the current 3.10 release, it's hard to run
>> at 200 Msps from GNU Radio, for instance. If your software has
>> comparable rates to benchmark_rate, then you're probably not going to
>> be affected by this anyway.
>>
>> -- M
>>
>>
>> On 02/23/2017 12:05 PM, Ian Buckley via USRP-users wrote:
>>> Stefano
>>> I'll take a stab at explaining the probable background on this. UHD
>>> uses credit based flow control to avoid overflowing buffers in the
>>> USRP. When you prepare to start a new TX operation the TX buffer
>>> inside the USRP is completely empty and can fill at wire rate speed.
>>> At some point it may/will become full and at this point the credit
>>> based flow control algorithm will pace the data over the network such
>>> that it approximates the TX rate over the air (Which is hard real
>>> time). When the actual TX over the air operation starts relative to
>>> when the buffering of data commences can yield some challenging situations.
>>> If the TX operation starts as soon as the first samples of data reach
>>> the TX DSP (i.e buffer is practically empty) then it runs the very
>>> real risk of underflowing because it consumes data at a constant rate
>>> but data delivered from the host tends to be bursty and jitter in
>>> delivery (since the host is non-realtime in design) and also the main
>>> sample buffer is a DRAM with a single port to which access is
>>> arbitrated adding more jitter as ingress and egress compete for
>>> access. Typically UHD deals with the "buffer practically empty" case
>>> by starting streaming the data to the USRP well in advance of a
>>> scheduled TX operation start time allowing time for buffers to fill
>>> somewhat, but the buffer access arbitration is tricky at startup
>>> since you have a corner case situation with data streaming in at wire
>>> speeds rather than rate limited by the credit algorithm plus data
>>> being drained at the configured sample rate by the TX DSP. What you
>>> are probably therefore seeing is underflows (@ the DSP) during the
>>> initial fill of the buffer as internal bandwidth is transiently
>>> exceeded, and then smoother operation as the bit rate over the
>>> network drops back to approximate the transmission sample rate once the
>>> buffer is full.
>>>
>>> I'm a couple of years stale on the internal implementation details of
>>> this now, but that is the gist of the challenge.
>>> -Ian
>>>
>>>
>>>
>>> On Feb 23, 2017, at 11:02 AM, Stefano Bettelli via USRP-users
>>> <[email protected]
>>> <mailto:[email protected]<mailto:[email protected]%20%3cmailto:[email protected]>>>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We are still in the process of extracting maximum performance from
>>>> our USRP X310's, and we have a weird problem with transmission of
>>>> data, which does not appear while reading data. The USRP that I am
>>>> considering has two 10G fibre connections, and uses the XG FPGA
>>>> firmware (we use the latest UHD, 3.10.1.1). The software developed
>>>> by us and the benchmark_rate example agree on both RX and TX, so I
>>>> will report only the results with the benchmark_rate. RX works
>>>> nicely, we have 800MB/s on each fibre:
>>>>
>>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>>> --duration 30 --channel "0,1" --rx_otw sc16 --rx_cpu sc16 --rx_rate
>>>> 200e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>>> UHD_003.010.001.001-release [...] Testing receive rate 200.000000
>>>> Msps on 2 channels Benchmark rate summary:
>>>> Num received samples: 12000120052
>>>> Num dropped samples: 0
>>>> Num overflows detected: 0
>>>> Num transmitted samples: 0
>>>> Num sequence errors: 0
>>>> Num underflows detected: 0
>>>> Num late commands: 0
>>>> Num timeouts: 0
>>>>
>>>> However, TX shows a lot of problems for rates larger that 50MS/s,
>>>> for
>>>> instance:
>>>>
>>>> ./benchmark --args "addr=192.168.30.2,second_addr=192.168.40.2"
>>>> --duration 30 --channel "0,1" --tx_otw sc16 --tx_cpu sc16 --tx_rate
>>>> 100e6 linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>>> UHD_003.010.001.001-release [.] Testing transmit rate 100.000000
>>>> Msps on 2 channels [. throws a lot of U's .] Benchmark rate summary:
>>>> Num received samples: 0
>>>> Num dropped samples: 0
>>>> Num overflows detected: 0
>>>> Num transmitted samples: 6013212352
>>>> Num sequence errors: 0
>>>> Num underflows detected: 18509
>>>> Num late commands: 0
>>>> Num timeouts: 0
>>>>
>>>> Eventually there is transmission at 400MB/s on both fibres, but we
>>>> lose the initial part. Achieving tx_rate=200e6 does not work at all
>>>> (the USRP stops replying). By observing the threads with htop we see
>>>> that one thread approaches 80-90% of CPU usage. By comparison with
>>>> our program, where we can identify the threads, I infer that it is
>>>> the thread containing the tx_streamer->send() call; this call seems
>>>> to be very heavy. All this looks strange because the Ethernet fibres
>>>> are exactly the same, and the rest of the system seems to be
>>>> configured in the same way for RX and TX:
>>>>
>>>> Both network interfaces have MTU=9000:
>>>> ifconfig | grep enp129 -A3
>>>> enp129s0f0 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2c
>>>> inet addr:192.168.40.1 Bcast:192.168.40.255 Mask:255.255.255.0
>>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2c/64 Scope:Link
>>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>>> --
>>>> enp129s0f1 Link encap:Ethernet HWaddr e8:4d:d0:c5:1b:2d
>>>> inet addr:192.168.30.1 Bcast:192.168.30.255 Mask:255.255.255.0
>>>> inet6 addr: fe80::ea4d:d0ff:fec5:1b2d/64 Scope:Link
>>>> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
>>>>
>>>> Both RX and TX have large network buffer sizes sysctl -a | grep
>>>> net.core.*mem_max net.core.rmem_max = 33554432 net.core.wmem_max =
>>>> 33554432
>>>>
>>>> both RX and TX have the same number of descriptors (also on the
>>>> other
>>>> card):
>>>> ethtool -g enp129s0f0
>>>> Ring parameters for enp129s0f0:
>>>> Pre-set maximums:
>>>> RX: 4096
>>>> RX Mini: 0
>>>> RX Jumbo: 0
>>>> TX: 4096
>>>> Current hardware settings:
>>>> RX: 512
>>>> RX Mini: 0
>>>> RX Jumbo: 0
>>>> TX: 512
>>>>
>>>> Interrupt coalescing seems not to be available on these cards. The
>>>> server is also quite powerful, 2xXeon with 48 cores in total, and
>>>> 128GB of memory. Cores run at at least 3GHz. Can you suggest any
>>>> idea to help us debugging this problem? Thanks in advance,
>>>>
>>>> Best regards/Mit freundlichen Gruessen,
>>>>
>>>> Stefano Bettelli
>>>> Senior research engineer
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]<mailto:[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]<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]<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
>
------------------------------
Message: 7
Date: Wed, 1 Mar 2017 12:41:31 +0000
From: Stefano Bettelli <[email protected]>
To: Claudio Cicconetti <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <1C28F8990859A84D809CFC7AB0D38942A853AF@lhreml502-mbx>
Content-Type: text/plain; charset="us-ascii"
Hi Claudio,
-----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Claudio Cicconetti via USRP-users
> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
> Hello Stefano,
> Do you mind sharing the source code of your modified benchmark_rate?
In the spirit of the minimal working example I have prepared a simplified code
that I attach at the end of this message.
You have to recompile it to change parameters, because I have stripped out all
option parsing, but it is a quick thing.
In the main you can change the args string, the transmit rate, the # of
channels and the init delay.
In the send() subthread called b_tx_rate() you can change mainly how many
samples per channel you send with each individual send().
This benchmark runs till "target" (global variable) samples per channel have
been sent, or till the send() returns 0.
Compile it with the following command line:
g++ -std=c++14 -Wall -Wextra -O3 -s -o mybenchmark mybenchmark.cpp -luhd
-lpthread -lboost_system
I have an X310 with the XG firmware, and 2 10G cables, and I have tried it in
the following configurations:
1) 2 ch, 1MS/s, 200'000 S/ch, target = 16'000'000 --> OK
2) like in 1) but target = 200'000 --> errors
3) like in 1) but the # of S/ch is randomly chosen between 200'000 and 200'500
--> errors
4) same as 1),2) and 3) with only one channel --> same results
Analysing the traffic with Wireshark doesn't show any specific anomaly, nor
large fluctuations in packet deltas (the transport tends to use UDP packet with
about 2000B of payload, with a delta of 5-20 microseconds, while one packet
needs 1ms to be processed by the USRP.
I would be very interested to know whether you get the same results, and
whether you spot any error in the program workflow.
Thanks in advance,
Stefano
--------------- start of mybenchmark.cpp --------- cut here -------------------
#include <uhd/utils/thread_priority.hpp>
#include <uhd/utils/safe_main.hpp>
#include <uhd/usrp/multi_usrp.hpp>
#include <iostream>
#include <thread>
std::vector<size_t> counts(256, 0); // async message counts
size_t target { 16000000 }; // total # samples per channel to be TXed
#include <chrono>
#define NOW std::chrono::high_resolution_clock::now()
#define DIF ((std::chrono::high_resolution_clock::now()-start).count()/1000)
/***********************************************************************
* Attempt transmission with multiple send()'s
**********************************************************************/
void b_tx_rate(uhd::tx_streamer::sptr tx_stream,
uhd::time_spec_t start_time, double tx_rate) {
uhd::tx_metadata_t md;
md.time_spec = start_time;
md.has_time_spec = true;
// const size_t natural_spp = tx_stream->get_max_num_samps();
const size_t min_spp = 200000;//199600; // samples per channel
const size_t max_spp = 200000; // samples per channel
std::cout << "Using " << max_spp << " samples in send()" << std::endl;
std::vector<char> buff(4 * max_spp); // sc16 is 4 bytes per sample
const auto num_ch = tx_stream->get_num_channels();
std::vector<const void *> pts(num_ch, &buff.front());
auto start { NOW }; size_t accum { 0 };
while (target > 0) {
size_t act_spp = min_spp + (double(rand())/RAND_MAX)*(max_spp - min_spp);
if (act_spp > target) act_spp = target;
auto rel_time { md.time_spec }; rel_time -= start_time;
std::cout << " spp " << act_spp << " alsent " << accum
<< " to send " << target << " time spec "
<< rel_time.get_real_secs() << std::endl;
start = NOW;
auto n = tx_stream->send(pts, act_spp, md);
std::cout << "Send call time " << DIF << " sent= " << n << std::endl;
accum += n; target -= n;
start = NOW;
md.time_spec += uhd::time_spec_t::from_ticks(n, tx_rate);
md.has_time_spec = false;
if (n == 0) { target = 0; break; /* stop on error */ } }
md.has_time_spec = false;
md.end_of_burst = true; // EOB packet
tx_stream->send(pts, 0, md); }
/***********************************************************************
* Handle asynchronous messages
**********************************************************************/
void b_tx_async(uhd::tx_streamer::sptr tx_stream) {
uhd::async_metadata_t amd;
size_t termination = 10; // delayed exit to catch late messages
while (target > 0 || termination > 0) {
if (not tx_stream->recv_async_msg(amd)) { // 100ms timeout
if (target == 0) --termination; continue; }
++counts[amd.event_code]; } }
/***********************************************************************
* Main code + dispatcher
**********************************************************************/
int UHD_SAFE_MAIN(int argc, char *argv[]){
(void)argc; (void)argv;
// ---------------------------------------------------------------
std::string args { "addr=192.168.30.2,second_addr=192.168.40.2" };
std::vector<size_t> tx_channels { 0,1 };
double init_delay { 0.5 }; // 500mS
double tx_rate { 1.0e6 };
// ---------------------------------------------------------------
uhd::set_thread_priority_safe();
std::cout << "Creating the usrp device with: " << args << std::endl;
auto usrp = uhd::usrp::multi_usrp::make(args);
std::cout << "Using Device: " << usrp->get_pp_string() << std::endl;
usrp->set_tx_rate(tx_rate);
//usrp->set_tx_gain(20,0);
usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
uhd::stream_args_t stream_args("sc16", "sc16");
stream_args.channels = tx_channels;
auto tx_stream = usrp->get_tx_stream(stream_args);
std::cout << "\nTX subdev_spec=" << usrp->get_tx_subdev_spec().to_string()
<< "\nTesting tx_rate=" << (usrp->get_tx_rate()/1.0e6) << "MS/s"
<< " chan=" << tx_stream->get_num_channels() << "\n\n";
auto start_time = usrp->get_time_now() + uhd::time_spec_t(init_delay);
std::thread tx { b_tx_rate , tx_stream, start_time, tx_rate };
std::thread as { b_tx_async, tx_stream };
tx.join(); as.join();
#define CC(s) std::endl << #s": " << \
counts[uhd::async_metadata_t::event_code_t::EVENT_CODE_ ## s]
std::cout << CC(BURST_ACK) << CC(UNDERFLOW) << CC(SEQ_ERROR)
<< CC(TIME_ERROR) << CC(UNDERFLOW_IN_PACKET)
<< CC(SEQ_ERROR_IN_BURST) << CC(USER_PAYLOAD) << std::endl;
return EXIT_SUCCESS; }
------------------------------
Message: 8
Date: Wed, 1 Mar 2017 14:17:10 +0000
From: Carin <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Cannot se sent out signal in oscilloscope
Message-ID:
<am3pr01mb2282ae3d43fe107d3a2c304e2...@am3pr01mb228.eurprd01.prod.exchangelabs.com>
Content-Type: text/plain; charset="utf-8"
Hi,
We are working on an SDR solution for satellite communication using your USRP
B210 along with GNU Radio Companion. We got stuck on the first step, i.e.
transmitting a simple sine-signal created in GNU radio to an oscilloscope. We
are however getting some kind of signal, but it doesn?t seem to be related to
the frequency and amplitude of the signal source, but rather to the center
frequency of the uhd sink.
We have also tried following the tutorial "Building a QPSK Transmitter ? on
your website but with the same results. Do you have any ideas on what can be
wrong?
Regards,
Carin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/44015d92/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 79, Issue 1
*****************************************
