Increasing the ring buffer size does not seem to help either, or at least does not clear up the issue entirely, but I will keep the buffer size at its maximum (8192) for now. Same goes setting governing to “performance”
I forgot to add in my previous email that occasionally, (this does not always happen) data will drop in ‘sprints’, so instead of a small bit of data being dropped here and there, there may be a 10-15 second interval where a relatively large amount of data is dropped. If I bring the data rate slightly down by decreasing the number of samples per burst - for example, decreasing down to 85% of the preferred amount - it seems to act quite reliably(over hours and hours of testing I have yet to notice failure), so I am likely operating near a threshold. It does not get much worse when I increase the samples per burst, but as I have said I rather not lose any data. I do still find it peculiar that the returned value of recv() when data is dropped is less than the buffer size, then immediately returns 0 the next time its called. Going through the source code I could see why it returns a value smaller than the buffer size, but I dont understand why it would return 0.
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
