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
