One thing to keep in mind: If you have many many virtual channels, then you probably still have a lot of blocks. The control crossbar also increases with N^2 in size, where N is the number of blocks (not the number of stream endpoints, which affects the size of the CHDR crossbar).
Maybe what you're trying to do is better handled at the application level. Meaning that you have bigger blocks that do some kind of channelization internally, and then pull apart the stream in your application. After all, there are very few rules on what kind of data you can stream to the host (or vice versa). For example, when we stream FFT data to the host, we don't separate the bins into virtual channels, but we put the onus on the application to understand that every vector of FFT-size needs to be understood as such. Not sure if this is helpful to you -- of course, for most cases, RFNoC should be doing all the hard work for you. But in some cases, it might be easier to do some of the work in your app. --M On Thu, May 1, 2025 at 4:42 AM Wade Fife <wade.f...@ettus.com> wrote: > I don't think static routing will help in your case. Stream endpoints are > only for communicating over dynamic routes and the EPID is used for that > routing. > > Wade > > > On Mon, Apr 28, 2025 at 9:37 AM Brian Padalino <bpadal...@gmail.com> > wrote: > >> On Mon, Apr 28, 2025 at 10:33 AM Wade Fife <wade.f...@ettus.com> wrote: >> >>> In practice, you can't have a large number of stream endpoints in a >>> single USRP, because the crossbar and associated logic adds up. Something >>> on the order of 16 or so might be a practical limit, depending a lot on >>> what's on those endpoints. If you need to distinguish between more data >>> streams, then you'd want to use something like virtual channels or >>> prepending your data with some kind of identifier. >>> >> >> Thanks for this answer. >> >> Does static routing help with this or not particularly? >> >> I have only a single configuration I ever want to run, and it's endpoints >> directly into a modified radio block - no other blocks. >> >> Thanks, >> Brian >> >>> _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
