Thank you both!
\
This allows me to buffer \~100 packets of 1996 samples instead of 65. \
\
For others:\
stream_args.args\["streamer"\] = "replay_buffered"; // Add more "elasticity" on
Tx using the Replay block as FIFO in USRP
___
USRP-users mailing lis
Hi Rob and Team,
I enabled the `streamer=replay_buffered` option as shown below. However, I did
not notice any difference, as it still buffers 64 packets.
Is there any additional configuration or step I need to take for this to work
as expected?\
\
uhd::device_addr_t addr_args("addr0=192.168.30
I hope everyone had a good holiday break!
Would you mind providing some guidance on the 3 questions?
Thanks
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Hi,
I know it’s the holiday…so I understand.
Trying to bring this back to the top of the queue.
Best
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
**Hi,**
**Hopefully you can help me out with some clarification and help on a few
questions.**
**We are using the X310 all with timestamps as we try to get an understanding
of the behavior. We have created several scenarios to try out start of burst
and end of burst and have noticed different
Hi Marcus,
Thanks for the answer in 2).
What about 1) **FPGA Rx Buffer Size:**
* What is the FPGA Rx buffer size on the X310?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Thank you Rob… I will explore this because I don’t want to deal with DPDK. I
read in other posts that it didn’t seem to make a difference.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.e
Hi,
Thanks for the answer in 2).
What about 1) **FPGA Rx Buffer Size:**
* What is the FPGA Rx buffer size on the X310?
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Dear Ettus Support Team,
I hope this message finds you well. We are currently using the X310 (FPGA 39.2)
with a 10GigE interface, handling 1996 samples (4 bytes each) per packet.
Despite following all recommended setup tips and tricks for the USRP and our
Linux box, we occasionally encounter “U
Hi,
Thanks for the support on this. We purchased a second unit. The problem on
the 2nd unit is no longer present after installing the same SFP + cable, and
connecting to the same server running the same program.
Thanks…
___
USRP-users mailing list -
I also got out of sequence errors at 1e6, I just had to wait 60 seconds instead
of 30.
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
I went back and looked at the 2974…. Got it. It’s one x310 with 2 interfaces
(30.2, 40.2), so it would make sense that the second instance doesn’t work.
Thank you.
In regards to the 8000 MTU, I set this up on the server (directly connected to
30.2), I still get the same trickle of S’s at low
Here is some interesting info that I could not explain.
* **Ran on server at 200Msps, got S’s with uhd thread priority at 0.90**
* **Ran on server at 100Msps, got S’s with uhd thread priority at 0.90**
* **Ran on server at 6.25Msps, got S’s with uhd thread priority at 0.90**
Why would I get S
Good catch!!!
I updated it now, but still have the same result…printing S’s when directly
connected to the powerful server.
I repeated the test on the USRP PC (2974) with the same results, printed U’s.
For the server, I cleared the NIC stats, then ran the program for a few
seconds. Here is th
Hi Marcus,
Anyone else able to look at this with ability to Tx on x310?
I have looked at all the counters on the server, and it I don’t see anything
unusual.\
Let me know if you need me to up/down the interface (to reset) and provide you
some counters….\
\
Here is more info:
```
~$ sudo ethtoo
Hi, Did you give the modified host/examples/tx_timed_samples.cpp I provided
above a try? This maybe the best first path to go down, to make sure it is not
a UHD thing. You can just replace the current tx_timed_samples.cpp with this
one (2 threads ago), then make in (for example) “\~/uhd-4.4.0.
uld easily keep up with 200Msps.
I ran the same program I provided above (I just modified your example program
tx_timed_samples.cpp) and now it outputs S’s instead of U’s.
Here is the output:
```
cjohnson@demo:~/uhd_versions/uhd_4.4.0.0/host/build/examples$ ./tx_timed_samples
Creating the usrp dev
Hi,
I appreciate the response. I previously made all of those changes (except
bios, DPDK, and Sprectre). In addition, I have MTU at 9000. I just
re-verified.
I’m still getting the U’s.
So we could have the same common code as a starting point, I modified your
tx_timed_samples.cpp provided
Hi Wade,
I am now receiving “U” instead of “L”. They don’t come out on the console that
often, but it is “bad” if I see any.\
In addition, I did add a priority to the thread, you can see below (takes on a
value between 0.0-100.0).\
I also tried setting the buffer to 10\*1996.\
None of these eff
Would you be able to provide some suggestions? We need to keep precision
timing for transmission. Neither of the two proof of concepts (POC) below are
meeting our needs. Of course we are sending 2 packets due to lack of jumbo
frames.
We have 2048 samples (4 bytes per sample) we would have li
Thanks for all the great info Marcus & Wade
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
I hacked the code to set the DATA_FRAME_MAX_SIZE = 8500, half-way between 8000
and MTU 9000.
Then I made sure to set the send_frame_size=recv_frame_size=8700, which is
equal, and over the MAX_SIZE.It still picks 8144. You can see below.
I added a bunch of debug of the intermediate variables.
Actually, you can probably expect that the ping -s with jumbo frames to fail,
since the FPGA stack is very limited and most likely hasn’t implemented ICMP
for jumbo frames.
However, the limitation of 8000 seems to be an artificial limit of the UHD
code, as it I have been able to demonstrate it
It is the switch that is internal to you hardware on USRP-2974.
You can see the switch below (from your documentation). I’m sending from the
SBC (Single board computer) shown in the diagram.
\
https://kb.ettus.com/File:2974_blk_dia_hiLevel_v01.png
___
nd_frame_size argument appropriately.UHD will use the
auto-detected max frame size for this connection.\
Interesting enough, at 8000 it does not complain. Of course we are fragmenting
because 8192 bytes packet.\
\--\
**I have confirmed that ping with larger size packet doesn’t work.**\
cj
Hi,
Any luck here? Even when specifying the mac (no arp required), the FPGA still
doesn’t send anything, though the control plane believes it is.
Here is the log, but no stream being transmitted.
---
> ```
> cjohnson@demo:~/ettus_repo/uhd/host/examples/python$ ./remote_rx.py
> --r
Hi Marcus^2,
Thanks for taking a look at this.
Yes, I am using 10G interface, but you will notice my streaming request was
only at 200Mbps (via command —rate=200e6).
> ```
> eno1: flags=4163 mtu 1500
> inet 192.168.0.67 netmask 255.255.255.0 broadcast 192.168.0.255
> inet6 fe
Hi Marcus,
Okay, thanks for that information.
What should we try next?
Thanks,--Cy
On Wednesday, May 17, 2023 at 12:05:39 PM PDT, Marcus D. Leech
wrote:
On 17/05/2023 14:49, cjohn...@serranosystems.com wrote:
Hi Marcus,
I am still interested to know how your team tests to ver
Hi Marcus,
I am still interested to know how your team tests to verify the FPGA is sending
the data….meanwhile I did two quick experiments based on your suggestions.
1) Same setup using the second interface I setup on the network card for the
remote port @192.168.30.30, “./remote_rx.py --rate=2
Hi Marcus,
I appreciate you quick responses. They have been useful.
If you look at the code in xport_adapter_ctrl.cpp, specifically
xport_adapter_ctrl::add_remote_ep_route(), you will notice that the dest_udp
is required.I don't think we are getting to the "catch" part, since based on
all the
—Cy
> ```
> cjohnson@demo:~/ettus_repo/uhd/host/examples/python$ ./remote_rx.py
> --rate=200e6 --freq=1223e6 --gain=20 --dest-addr=192.168.30.30
> --dest-port=54321 --adapter=sfp1 --dest-mac-addr=3c:ec:ef:c2:43:47
> [INFO] [UHD] linux; GNU C++ version 11.3.0; Boost_107400;
> UHD_4.
Hi Marcus,
On an external host.
As you know, the sfp1 interface is not connected to the internal switch (going
to the i7, only sfp0). But we are not using the i7. Instead, we are using
sfp1, connected to a different host, which should work similar to an X310 (with
external host).
Thanks,
; > udp0 0 192.168.30.1:34602 192.168.30.2:49152
> > ESTABLISHED
> > ```
> >
> > ```
> > udp0 0 0.0.0.0:50237 0.0.0.0:*
> >
> > ```
> >
> > ```
> > udp0 0 192.168.30.1:50938 192.168.30.2:
me figure out why this doesn’t work?
Thanks,
—Cy
—-Below using python scripts 1st attempt:-
cjohnson@demo:\~/ettus_repo/uhd/host/examples/python$ ./remote_rx.py
--rate=200e6 --freq=1223e6 --gain=20 --dest-addr=192.168.30.30 --dest-port=54321
\[INFO\] \[UHD\] linux; GN
34 matches
Mail list logo
