-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X310: Incorrect mapping of channels in multi-USRP TX only setup (DmaFIFO-related) #367
Comments
@ab-kbg Assuming this testing was on UHD 3.15.0.0 or 3.15.LTS ... yes? Please clarify. do you know if this is an issue with the recently tagged UHD4.0rc1? It's worth testing with that and reporting back here that info. |
Tagging @michael-west ... since some Ettus body needs to know about this ... and can hopefully comment on / verify the issue. |
Here is the full version string from UHD: |
@michaelld I did test 4.0.0.0-rc1 (I had to update FPGA version also) just now. |
Excellent! Thanks for the feedback @ab-kbg ! |
Is there any workaround for this issue? |
@armin485 workarounds include:
I say "maybe" because I can't reproduce this. However, the log posted has an interesting line:
|
Looks like this is UHD 3 only, and has workarounds, so we're not going to handle this. |
Issue Description
When using DmaFIFO (which is the default), the enabled channels are different than the intended ones, and change between each run of the program. In effect, Multi-USRP TX does not work properly with two or more X310s.
Setup Details
UHD 3.15.0.0 on Fedora 32 Linux
2 X310s motherboards, 192.168.10.2 and 192.168.110.2
4 UBX-40 daughterboards
Laptop with IPs 192.168.10.1 and 192.168.110.1, connected to the X310s via 1Gbit ethernet switch.
OctoClock-G connected to both X310s, providing 1 PPS and 10 MHz (not required to reproduce)
Expected Behavior
When I specify tx_channels="0,2" (subdevice spec is "A:0 B:0" by default), i should expect that the A output on both X310 gets enabled, while B outputs remain disabled.
Actual Behaviour
Sometimes, A and B outputs on first X310 are the only ones enabled. Other times A and B outputs on the second X310 are the only ones enabled. Rarely, <10% of the time, the behavior is as expected, where A outputs on both X310s are only ones enabled. The proportion between these errors changes somewhat depending on whether I enable external sync/ref or not, but external sync/ref is not required to demonstrate the issue.
This varies from run to run, and also occurs with other channel selections than "0,2".
When DmaFIFO is disabled via "skip_dram=1", the mapping is as expected, and the issue does not occur.
Steps to reproduce the problem
Both of these exhibit the issue:
benchmark_rate --args="addr0=192.168.10.2,addr1=192.168.110.2" --tx_rate 5e6 --tx_channels="0,2" --ref=external --pps=external
benchmark_rate --args="addr0=192.168.10.2,addr1=192.168.110.2" --tx_rate 5e6 --tx_channels="0,2"
Works as expected when DmaFIFO is disabled:
benchmark_rate --args="addr0=192.168.10.2,addr1=192.168.110.2,skip_dram=1" --tx_rate 5e6 --tx_channels="0,2"
Additional Information
See http:https://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2020-August/062553.html for background information, where the issue was narrowed down and the testing made in relation to it. Thanks to
Attached is a trace log from running
benchmark_rate --args="addr0=192.168.10.2,addr1=192.168.110.2" --tx_rate 5e6 --tx_channels="0,2"
, where A and B outputs on the second X310 are the only ones that get enabled, instead of only both A inputs on both X310s.uhd.log
The text was updated successfully, but these errors were encountered: