I 2nd the "use a RAM disk if you can" approach. RAM is cheap compared to the
time to flush out the gremlins in high rate continuous (or almost continuous)
record applications.
Are you sending burst commands to achieve the 80us/1ms? Can you continuously
recv and just drop the samples you don't wa
On 24/01/2024 18:13, jmalo...@umass.edu wrote:
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 th
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 alway
On 24/01/2024 16:11, Rob Kossler wrote:
Hi Joe,
I noticed that you have 128GB RAM. If you turn this into a 120GB RAM
drive, is this sufficient memory depth for your needs? If this is
possible, there is a good chance it will solve your issue.
Prior to DPDK, I tried to save to fast SSD and I alwa
On Wed, Jan 24, 2024 at 2:43 PM Marcus D. Leech wrote:
>
> On 24/01/2024 13:00, jmalo...@umass.edu wrote:
> >
> > Hello,
> >
> >
> > I currently have an application where I am burst receiving(about 80
> > micro per milli second) with the ettus X410 at the full sample rate
> > across 4 channels. I
On 24/01/2024 13:00, jmalo...@umass.edu wrote:
Hello,
I currently have an application where I am burst receiving(about 80
micro per milli second) with the ettus X410 at the full sample rate
across 4 channels. I am getting occasional issues where data is
dropped (terminal messages show “D” e
