Interruptions transmission over Gigabit Ethernet when receiving samples
from USRP can happen at highest data rates no matter how many tricks you
use with your network card (I have experience with N200/N210).
The loss of part of the signal results with synchronization loss in data
transmission systems. There is possibility to handle this problem by
catching rx_time stream tags.
But there might be a solution to keep synchronization that might work
quite well with gr-blocks that don’t handle stream tags.
What if USRP UHD Source gave user an option to fill all of the gaps in
signal with exact number of lost samples (for example with zeros).
Additionally it could produce stream tags with position and length of
each gap so it would be easy to store a file with continuous signal
stream paired with a file containing metadata describing where and for
how long the signal samples were lost.
Is it possible to do exactly what I’m describing with current gnuradio
blocks?
In my case it would often make many things I do easier.
But there might be a solution to keep synchronization that might work
blocks?
In my case it would often make many things I do easier.
–
Best Regards,
Piotr K.
It seems possible. And I recall that someone else asked about this
method before, too. Honestly, though, this falls into the category of
things that “we” (the maintainers) don’t have a strong interest in
doing or developing. Which just means that if you need it, experiment
with it and send us a patch if you get it to work really want to get
it into the main code.
One problem is that if you cannot keep up, adding in all-zeros data will
just make it harder to keep up. In general, modern PCs should be able
to
keep up with 25 MS/s without problem unless you are doing a lot of
processing. We are actually able to keep up with 300 MS/s on the X300.
So
the question is more about why the app can’t keep up.
An alternative might be to stream to a file. That should keep up
without
dropping as long as you have a fast drive. Then you can process samples
from that file at the pace your app can keep up with.
without dropping as long as you have a fast drive. Then you can
process samples from that file at the pace your app can keep up with.
Matt
And on a tangentially-related note, SSDs aren’t necessarily fast
writers. Particularly if they aren’t using an AHCI interface and/or,
they’re
early-generation. I found this out the hard way…
That’s true. You can fix some of the issues by using preemptible
kernels
and setting RTPRIO, but there can still be glitches. Certainly a block
which reads the streams tags and inserts zeros would not be too hard.
Interruptions transmission over Gigabit Ethernet when receiving samples
from USRP can happen at highest data rates no matter how many tricks you
use with your network card (I have experience with N200/N210).
The loss of part of the signal results with synchronization loss in data
transmission systems. There is possibility to handle this problem by
catching rx_time stream tags.
To sum up this thread, it’s probably better if you write your own block
that keeps track of rx_time tags and fills in zeros, instead of patching
gr-uhd to do this.
One problem is that if you cannot keep up, adding in all-zeros data will
just make it harder to keep up. In general, modern PCs should be able to
keep up with 25 MS/s without problem unless you are doing a lot of
processing. We are actually able to keep up with 300 MS/s on the X300. So
the question is more about why the app can’t keep up.
Well, sometimes the issue isn’t so much throughput but latency. Like
you have some ultra high priority task that decides to block all
processing for like 100 ms and some buffer fill up and you miss one
packet ever few minutes. I have that kind of stuff all the time on a
USRP1. It’s not a real time OS so it’s always better IMHO to be able
to cope gracefully with theses little glitches.
And if you’re app expects a continuous stream of data to maintain
alignement, filling with zero is easy enough.
Cheers,
Sylvain
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.