The resolution is that the x310 has the rfnoc_chdr clock (which I used to clock my block) slower than the radio clock, whereas with my previous n300 that clock is faster..!
I need to create many output channels from my block now, so I think I will just ignore handshaking, and design on the basis of the radio streaming continuously. From: Martin Braun <martin.br...@ettus.com> Sent: Tuesday, 29 July 2025 10:01 Cc: usrp-users@lists.ettus.com Subject: [USRP-users] Re: [EXTERNAL]Re: remote streaming starts, but stops after a few packets received Normally flow control is the thing that will let the radio stall, but maybe it's something else. From what I can see, there's two potential culprits: 1) Your block is not permanently processing samples, but has some bubble cycles or something like that. 2) The SEP->SEP connection has an issue. If you can, connect everything statically and see how that fares. --M On Tue, Jul 29, 2025 at 9:52 AM Kevin Williams <kevin.willi...@vastech.co.za <mailto:kevin.willi...@vastech.co.za> > wrote: Hi Martin, I do see a single “O”, but this is remote streaming so I didn’t think that should occur? Yes, this is a radio -> my custom block dynamic connection. Regards, Kevin From: Martin Braun <martin.br...@ettus.com <mailto:martin.br...@ettus.com> > Sent: Tuesday, 29 July 2025 09:44 Cc: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> Subject: [USRP-users] Re: [EXTERNAL]Re: remote streaming starts, but stops after a few packets received Kevin, based on the src port, this looks like it's going from Device to Host, not the other way around. This means it's an async message from an RFNoC block, with address 0x1000. I can't tell for sure from this screenshot, but I think this is coming from the radio, and 0x1000 is the "RX Error" address. The data is incorrectly formatted (probably an issue of the CHDR dissector, but I think it's telling us the data is "2" (if we read this in network order). Put these together, and we're looking at a simple overrun. Something in your chain is holding up the radio after a few packets. Are you sure you're not seeing an "O" anywhere in your output? You are using a radio block, right? --M On Tue, Jul 29, 2025 at 9:19 AM Kevin Williams <kevin.willi...@vastech.co.za <mailto:kevin.willi...@vastech.co.za> > wrote: Hi, Another observation is the every time the streaming stalls, whether remote streaming or normal rx_streamer operation, I see this packet from the host to the x310 a few data packets before it stops. What is this control write address (0x01000), and is it perhaps relevant? From: Kevin Williams Sent: Tuesday, 29 July 2025 07:53 To: 'bpadal...@gmail.com <mailto:bpadal...@gmail.com> ' <bpadal...@gmail.com <mailto:bpadal...@gmail.com> > Cc: 'martin.br...@ettus.com <mailto:martin.br...@ettus.com> ' <martin.br...@ettus.com <mailto:martin.br...@ettus.com> >; 'usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> ' <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> >; Werner Bode <werner.b...@vastech.co.za <mailto:werner.b...@vastech.co.za> > Subject: RE: [USRP-users] Re: [EXTERNAL]Re: remote streaming starts, but stops after a few packets received 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 <mailto:bpadal...@gmail.com> > Sent: Monday, 28 July 2025 16:49 To: Kevin Williams <kevin.willi...@vastech.co.za <mailto:kevin.willi...@vastech.co.za> > Cc: martin.br...@ettus.com <mailto:martin.br...@ettus.com> ; usrp-users@lists.ettus.com <mailto: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/H9mfCKOByytM7xBsMfri5-4wa?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
