Ah, yes -- that is, in fact, the entire purpose of the CE clock. If you're doing sample processing, always use that clock. On all devices, we provide that clock in a way that will let you do sample processing fast enough.
--M On Tue, Jul 29, 2025 at 1:03 PM Kevin Williams <[email protected]> wrote: > 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 <[email protected]> > *Sent:* Tuesday, 29 July 2025 10:01 > *Cc:* [email protected] > *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 < > [email protected]> 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 <[email protected]> > *Sent:* Tuesday, 29 July 2025 09:44 > *Cc:* [email protected] > *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 < > [email protected]> 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:* '[email protected]' <[email protected]> > *Cc:* '[email protected]' <[email protected]>; ' > [email protected]' <[email protected]>; Werner Bode < > [email protected]> > *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 <[email protected]> > *Sent:* Monday, 28 July 2025 16:49 > *To:* Kevin Williams <[email protected]> > *Cc:* [email protected]; [email protected] > *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 < > [email protected]> 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 > >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
