Hi Brian,
I’ve got two observations:
1. This is a summary of my custom block streaming where the data packet
stream ends with icmp packets about the destination becoming unreachable:
No. Time Source Destination Protocol Length
Info
1 0.000000000 10.23.128.1 10.23.128.255 UDP
50 1534 → 1534 Len=8
5343 49.277852197 10.22.128.3 10.23.128.1 UDP
60 49152 → 36716 Len=16
<5000-odd small udp and small rfnoc control & management packets. Setup I
guess.>
7318 50.792688865 10.22.128.3 10.22.128.1 RFNOC 4146
[Data] -> 6
<first seq=0 rfnoc data packet of the correct size given my tlast counter>
7319 50.792748665 Intel_e8:c3:4c Broadcast ARP
42 Who has 10.22.128.1? Tell 10.23.128.1
7320 50.792754229 10.22.128.3 10.22.128.1 RFNOC 4146
[Data] -> 6
<a few 100 more correct data packets>
7775 50.795514072 10.22.128.3 10.22.128.1 RFNOC 4146
[Data] -> 6
<a string of more control and short 66 byte rfnoc packets, but no rfnoc data
packets>
7968 52.854255766 Intel_e8:c3:4c Broadcast ARP
42 Who has 10.22.128.1? Tell 10.23.128.1
7969 53.238261827 Intel_e8:c3:4e NationalInst_35:aa:da ARP
42 Who has 10.23.128.3? Tell 10.23.128.1 (duplicate use of
10.23.128.1 detected!)
7970 53.238475399 NationalInst_35:aa:da Intel_e8:c3:4e ARP
60 10.23.128.3 is at 00:80:2f:35:aa:da (duplicate use of 10.23.128.1
detected!)
<then the destination becomes unreachable?>
7971 53.878292746 10.23.128.1 10.22.128.3 ICMP
590 Destination unreachable (Host unreachable)
7972 53.878302721 10.23.128.1 10.22.128.3 ICMP
590 Destination unreachable (Host unreachable)
7973 53.878308143 10.23.128.1 10.22.128.3 ICMP
590 Destination unreachable (Host unreachable)
7974 53.878314734 10.23.128.1 10.22.128.3 ICMP
590 Destination unreachable (Host unreachable)
7975 53.878320545 10.23.128.1 10.22.128.3 ICMP
590 Destination unreachable (Host unreachable)
7976 53.878326301 10.23.128.1 10.22.128.3 ICMP
590 Destination unreachable (Host unreachable)
<after that, just arp packets and the usrp broadcasting small udp packets>
8014 137.075344888 NationalInst_35:aa:da Broadcast ARP
60 ARP Announcement for 10.23.128.3
8015 137.075304321 NationalInst_35:aa:d9 Broadcast ARP
60 ARP Announcement for 10.22.128.3
8016 140.701925975 10.23.128.1 10.23.128.255 UDP 50
38981 → 1534 Len=8
8017 140.701942078 10.23.128.1 10.23.128.255 UDP 50
38981 → 1534 Len=8
8018 142.361983307 10.23.128.1 10.23.128.255 UDP 50
59572 → 1534 Len=8
8019 150.005535184 10.23.128.1 10.23.128.255 UDP 50
1534 → 1534 Len=8
8020 150.005558707 10.23.128.1 10.23.128.255 UDP 50
1534 → 1534 Len=8
8021 152.097709946 NationalInst_35:aa:d9 Broadcast ARP
60 ARP Announcement for 10.22.128.3
8022 152.097809876 NationalInst_35:aa:da Broadcast ARP
60 ARP Announcement for 10.23.128.3
8023 155.702401576 10.23.128.1 10.23.128.255 UDP 50
38981 → 1534 Len=8
8024 155.702431967 10.23.128.1 10.23.128.255 UDP 50
38981 → 1534 Len=8
8025 157.378508296 10.23.128.1 10.23.128.255 UDP 50
59572 → 1534 Len=8
2. ILA results
With my block I see a continuously asserted TREADY, with TLAST’s at exactly the
correct sample counts, until streaming stops where I see TREADY deasserted for
20-odd clocks, and then reasserted (without further streaming).
Regards, Kevin
From: Brian Padalino <bpadal...@gmail.com>
Sent: Monday, 28 July 2025 16:49
To: Kevin Williams <kevin.willi...@vastech.co.za>
Cc: martin.br...@ettus.com; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Re: [EXTERNAL]Re: remote streaming starts, but stops
after a few packets received
On Mon, Jul 28, 2025 at 10:15 AM Kevin Williams <kevin.willi...@vastech.co.za
<mailto:kevin.willi...@vastech.co.za> > wrote:
I did an experiment today with just this (Ettus blocks only):
connections:
- { srcblk: radio0, srcport: out_0, dstblk: ep0, dstport: in0}
- { srcblk: ep6, srcport: out0, dstblk: ddc0, dstport: in_0 }
- { srcblk: ddc0, srcport: out_0, dstblk: ep6, dstport: in0 }
Which did not work – the remote streaming stopped.
Changing the destination EP to a new one, ep7, worked again.
>From the RFNoC 4 workshop slides I was under the impression blocks could start
>and end on the same SEP?
For what it's worth, I'm using remote streaming with a custom block and it's
working well.
In fact, the way remote streaming works (at least for an X440) is that the
Ethernet/UDP information is written here:
https://github.com/EttusResearch/uhd/blob/40403b7c00154e4559c47bd6dde924f092992d45/fpga/usrp3/lib/rfnoc/xport_sv/chdr_xport_adapter.sv#L671
<https://url.za.m.mimecastprotect.com/s/A3G4Cqj5nnSkYL0cZfqiEiSn-?domain=github.com>
The kv_map uses the destination EPID as the key for the ethernet information
which gets looked up for every packet.
So if the streaming works when not doing remote streaming it might be something
else since all data paths go through here.
If you get the first few packets and it stops, is there any way you're
providing `enable_fc` as an argument? That would enable flow control which
obviously wouldn't be good if you aren't doing any flow control processing on
your RX side.
Lastly, I agree with Martin that you should probably add an ILA to your block
and the SEP interfaces to see where the AXI stream is getting stopped up.
Good luck.
Brian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
