How about if you use an unmodified "benchmark_rate"?
On Mon, Dec 18, 2023 at 11:43 AM Anabel Almodovar <
anabel.almodo...@gmail.com> wrote:
> Even with a single card I still get the same error.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Creating the usrp device with:
> addr0=192.168.60.2,second_addr0=192.168.50.2,recv_buff_size=900000000...Creating
> the subdevice with: A:0 A:1 B:0 B:1...Using Device: Single USRP: Device:
> X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard:
> A RX Subdev: TwinRX RX0 RX Channel: 1 RX DSP: 1 RX Dboard: A
> RX Subdev: TwinRX RX1 RX Channel: 2 RX DSP: 0 RX Dboard: B RX
> Subdev: TwinRX RX0 RX Channel: 3 RX DSP: 1 RX Dboard: B RX
> Subdev: TwinRX RX1 TX Channel: 0 TX DSP: 0 TX Dboard: A TX
> Subdev: Unknown (0xffff) - 0 TX Channel: 1 TX DSP: 0 TX Dboard: B
> TX Subdev: Unknown (0xffff) - 0Número de canales detectados: 4Número de
> tarjetas detectadas: 1Actual RX Rate: 50.000000 Msps...Actual Acquisition
> Time to: 0.000000 Seconds.Actual RX Freq: 800.000000 MHz...Actual RX Gain:
> 5.000000 dB...Actual RX Bandwidth: 50.000000 MHz...Setting LO
> source...[INFO] [MULTI_USRP] 1) catch time transition at pps edge[INFO]
> [MULTI_USRP] 2) set times next pps (synchronously)Press Ctrl + C to
> stop streaming...STAR SAMPLING ...D[ERROR] [STREAMER] The receive packet
> handler failed to time-align packets. 1002 received packets were processed
> by the handler. However, a timestamp match could not be determined.D[ERROR]
> [STREAMER] The receive packet handler failed to time-align packets. 1002
> received packets were processed by the handler. However, a timestamp match
> could not be determined.^CReceived 199995208 samples in 6.703929
> seconds29.8325 MspsDone!*
>
>
> El lun, 18 dic 2023 a las 17:13, Rob Kossler (<rkoss...@nd.edu>) escribió:
>
>> Several comments:
>>
>> - It seems like multiple things are going on. You mentioned the
>> original "failed to time align" error and below you mentioned 'O' and 'D'.
>> - The time-align error I did not expect had anything to do with
>> "performance". This seemed to me that the first packet arriving from
>> device
>> 1 had a different time stamp than the first packet arriving from
>> device 2.
>> Now, I'm not so sure
>> - But, the 'O' and 'D' are often related to "performance".
>> Overflow 'O' occurs when the 'Radio' block has A/D samples that it
>> needs to
>> put in a FIFO but the FIFO is full because it is not being emptied fast
>> enough (presumably by the host PC). A dropped packet (or sequence
>> error)
>> 'D' occurs when the host PC detects that the incoming packets are not
>> in
>> sequential order. This can occur if the host PC Ethernet handling
>> becomes
>> overwhelmed and simply discards a set of incoming packets for a time
>> period. Both 'O' and 'D' can imply that the host PC is not keeping up
>> with
>> incoming data
>> - In any case, you may want to simplify the problem by dropping from
>> two devices to one device. See if you can eliminate some or all of these
>> problems when using only 4 channels.
>> - If you drop to one device, you can use benchmark_rate to test
>> performance. If you do not use "second_addr", you should be able to get
>> 4x50 MS/s. If you use "second_addr", you should be able to get 4x100
>> MS/s.
>> - Regarding your needed changes to "rx_samples_to_file", I guess I
>> was thinking about the latest version which supports multiple channels.
>> Perhaps UHD 3.12 has a version of this example that only supports a single
>> channel. You could compare your version to the latest version (say, UHD
>> 4.6) to see the improvements to this example.
>>
>>
>> On Mon, Dec 18, 2023 at 7:44 AM Anabel Almodovar <
>> anabel.almodo...@gmail.com> wrote:
>>
>>> Hi Rob,
>>>
>>> Thanks for the suggestions. I have tried deleting the LO sharing, and
>>> nothing changes. Then removing the second addr, and that leads me to get
>>> 'Ds' in addition to the error already mentioned, as it is not able to
>>> handle that much information. Although I don't quite understand the
>>> difference between 'O' and 'D'.
>>>
>>> From what I understand the program is set up for a single channel, so I
>>> need to modify it to get more than one.
>>>
>>> Thank you in advance.
>>>
>>> Regards,
>>> Anabel
>>>
>>> El vie, 15 dic 2023 a las 15:39, Rob Kossler (<rkoss...@nd.edu>)
>>> escribió:
>>>
>>>> Hmmm. I'm not sure. Here are a few comments:
>>>>
>>>> - Try running without "second_addr". I realize that you will need
>>>> it for full rate (4 x 100MS/s for each X310), but you could run at 50
>>>> MS/s
>>>> without second_addr
>>>> - Try running without shared LO. I don't think you would need to
>>>> physically change any sharing cables.
>>>> - I am curious why you needed to modify the streamer, pointer
>>>> buffer and file writing. I would expect that this would scale with the
>>>> number of channels such that you didn't need to modify any code in this
>>>> area
>>>> - If you were using a more recent UHD, I would recommend switching
>>>> to the example benchmark_rate which natively supports external PPS and
>>>> multiple devices. I noticed that even the most recent
>>>> rx_samples_to_file
>>>> does not support external PPS (without modifying the code)
>>>> - I know you mentioned you were unable to upgrade because of
>>>> compatibility constraints. But, even if you cannot upgrade the OS,
>>>> would
>>>> you be able to install a new UHD - perhaps in a local folder that did
>>>> not
>>>> interfere with the system-wide UHD 3.12 installation. I typically have
>>>> multiple UHD versions on my system and switch among them by "sourcing" a
>>>> given setup file as needed.
>>>>
>>>>
>>>> On Fri, Dec 15, 2023 at 12:52 AM Anabel Almodovar <
>>>> anabel.almodo...@gmail.com> wrote:
>>>>
>>>>> Dear Rob,
>>>>>
>>>>> Yes, I use an external clock configuration.
>>>>>
>>>>> *std::this_thread::sleep_for( std::chrono::milliseconds(int64_t(1000 *
>>>>> setup_time) );*
>>>>>
>>>>>
>>>>>
>>>>> *usrp->set_clock_source("external",
>>>>> uhd::usrp::multi_usrp::ALL_MBOARDS); usrp->set_time_source("external",
>>>>> uhd::usrp::multi_usrp::ALL_MBOARDS);usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));std::this_thread::sleep_for(std::chrono::seconds(1));*
>>>>>
>>>>> I have only modified the code to get 8 channels and LO sharing. I want
>>>>> to get a continuous acquisition setup without losing samples. But I am
>>>>> starting with something basic at the moment. Any suggestions are welcome.
>>>>> So I've modified the streamer, the pointer buffer, and added writing
>>>>> files.
>>>>>
>>>>> my line is
>>>>> *$sudo ./rx_samples_to_file_v1
>>>>> --args="addr0=192.168.60.2,second_addr0=192.168.50.2,addr1=192.168.40.2,second_addr1=192.168.30.2,recv_buff_size=900000000"
>>>>> --subdev="A:0 A:1 B:0 B:1" --channel="0,1,2,3,4,5,6,7" --freq 800e6 --rate
>>>>> 25e6 --bw 25e6 --gain 70 *
>>>>>
>>>>> Regards,
>>>>>
>>>>> *Anabel*
>>>>>
>>>>>
>>>>>
>>>>> El jue, 14 dic 2023 a las 18:25, Rob Kossler (<rkoss...@nd.edu>)
>>>>> escribió:
>>>>>
>>>>>> Hi Anabel,
>>>>>> In my opinion, the error you are experiencing has nothing to do with
>>>>>> streaming performance settings (such as "performance" governor, network
>>>>>> descriptors, MTU size, etc). The issue seems to be that the two X310
>>>>>> devices do not have synchronized clocks. In addition to the physical
>>>>>> synchronization using OctoClock, you must also configure each device to
>>>>>> use
>>>>>> external synchronization and you must tell each device to reset its FPGA
>>>>>> clock count at a common PPS. The typical sequence is: (1) wait for a PPS
>>>>>> to
>>>>>> occur (by querying either device), (2) tell each device to reset its FPGA
>>>>>> clock at the subsequent PPS (this step must complete before the next PPS
>>>>>> arrives).
>>>>>>
>>>>>> You mentioned that you are using rx_samples_to_file. Did you modify
>>>>>> it in any way? What is your exact command line with all parameters?
>>>>>> Rob
>>>>>>
>>>>>> On Thu, Dec 14, 2023 at 10:29 AM Anabel Almodovar <
>>>>>> anabel.almodo...@gmail.com> wrote:
>>>>>>
>>>>>>> Dear Rob
>>>>>>>
>>>>>>> Thank you for your answer.
>>>>>>> I make use of the CDA-2990 octoclock as a source of synchronization
>>>>>>> between both USRPs, in addition to local oscillator sharing. I use dual
>>>>>>> 10GigEth connections and a MTU of 9000 to connect the USRPs to the PC.
>>>>>>>
>>>>>>> Due to various compatibility issues I am unable to upgrade the
>>>>>>> system.
>>>>>>>
>>>>>>> When I work with a sample rate of 10MSps I don't get problems but
>>>>>>> when I increase to 25MSps I start to get the error. I need them working
>>>>>>> with 100MSps. I have tried changing the CPU governor to "performance" to
>>>>>>> get the maximum working frequency (*sudo cpupower frequency-set
>>>>>>> --governor performance*), as well as changing the number of network
>>>>>>> interface descriptors to maximum (*sudo ethtool -G <interface> tx
>>>>>>> <max> rx <max>*), or increasing the dirty memory buffer (*sudo
>>>>>>> sysctl -w vm.dirty_ratio=80; sudo sysctl -w
>>>>>>> vm.dirty_background_ratio=50*),
>>>>>>> but I still get the same problem.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anabel
>>>>>>>
>>>>>>> El jue, 14 dic 2023 a las 15:38, Rob Kossler (<rkoss...@nd.edu>)
>>>>>>> escribió:
>>>>>>>
>>>>>>>> Hi Anabel,
>>>>>>>> How are you sync-ing the clocks on the two units? Do you have an
>>>>>>>> external PPS source and are you configuring both devices to use this
>>>>>>>> external source?
>>>>>>>>
>>>>>>>> Finally, do you have the ability to upgrade your OS and your UHD
>>>>>>>> versions? There aren't many user's that are using UHD 3.12 so if you
>>>>>>>> have
>>>>>>>> issues, it will be hard to get support.
>>>>>>>> Rob
>>>>>>>>
>>>>>>>> On Thu, Dec 14, 2023 at 5:20 AM Anabel Almodovar <
>>>>>>>> anabel.almodo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Dear all,
>>>>>>>>>
>>>>>>>>> I am trying to make an acquisition with two X310 equipped with two
>>>>>>>>> TwinRx. I am using Ubuntu 16.04 LTS 64-bit and UHD 3.12. My PC
>>>>>>>>> contains
>>>>>>>>> 128GB RAM and an Intel® Xeon(R) Silver 4114 CPU @ 2.20GHz × 40 and a
>>>>>>>>> 4TB
>>>>>>>>> SSD. I have modified the example rx_samples_to_file.cpp code to get 8
>>>>>>>>> channels and I get the following error:
>>>>>>>>>
>>>>>>>>> *D*
>>>>>>>>> *[ERROR] [STREAMER] The receive packet handler failed to
>>>>>>>>> time-align packets. 1002 received packets were processed by the
>>>>>>>>> handler.
>>>>>>>>> However, a timestamp match could not be determined.*
>>>>>>>>> *Timeout while streaming*
>>>>>>>>>
>>>>>>>>> *[ERROR] [X300] 192.168.60.2 <http://192.168.60.2>: x300 fw
>>>>>>>>> communication failure #1*
>>>>>>>>> *EnvironmentError: IOError: x300 fw poke32 - reply timed out*
>>>>>>>>> *[ERROR] [UHD] An unexpected exception was caught in a task
>>>>>>>>> loop.The task loop will now exit, things may not work.AssertionError:
>>>>>>>>> reply.sequence == request.sequence*
>>>>>>>>> * in virtual void
>>>>>>>>> x300_ctrl_iface_enet::__poke32(uhd::wb_iface::wb_addr_type, uint32_t)*
>>>>>>>>> * at
>>>>>>>>> /home/rs3_lab/workarea-uhd/uhd/host/lib/usrp/x300/x300_fw_ctrl.cpp:135*
>>>>>>>>>
>>>>>>>>> I don't know how to solve the Timeout problem, I have tried to
>>>>>>>>> start the acquisition 1.1 sg in time. But it didn't work.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> * stream_cmd.stream_now = false;
>>>>>>>>> stream_cmd.time_spec = usrp->get_time_last_pps(0)+1.1;*
>>>>>>>>>
>>>>>>>>> What is the problem and how can I fix it?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Anabel
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com
>>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>>>>>>>>
>>>>>>>>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
