File Sink slow?

Hello Newsgroup,

I tried to create a simple graph in GRC using a UHD Source (at 2MS/s)
and a file
sink which is simply dumping the binary data from the USRPN210.
I constantly receive Overruns in the form of “O”'s at the console
output.
That should mean the PC isn’t able to handle at least 8MB/s to write
onto the
disk.
I also tried to resize the socket buffer according to the instructions.
I have got a pretty new PC with SATA and an i5(QuadCore).

Can anybody point out where this overruns might come from?

Thanks and Greets,
Eral Türkyilmaz

On 07 Nov 2012 08:16, Eral Türkyilmaz wrote:

Hello Newsgroup,

I tried to create a simple graph in GRC using a UHD Source (at 2MS/s)
and a file
sink which is simply dumping the binary data from the
USRPN210.
I constantly receive Overruns in the form of “O”'s at the
console output.
That should mean the PC isn’t able to handle at least
8MB/s to write onto the
disk.
I also tried to resize the socket
buffer according to the instructions.
I have got a pretty new PC with
SATA and an i5(QuadCore).

Can anybody point out where this overruns
might come from?

Thanks and Greets,
Eral Türkyilmaz


Discuss-gnuradio
mailing list
[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Show us your
flow-graph. I agree, it shouldn’t be doing that.

<mleech ripnet.com> writes:

Show us your flow-graph. I agree, it shouldn’t be doing that.

Hello,

It looks like this: http://s14.postimage.org/ndqrbh6xt/dump_test.jpg
so both real parts are written interleaved into a file.

On 07 Nov 2012 10:07, Eral Türkyilmaz wrote:

ripnet.com>
writes:

Show us your flow-graph. I agree, it shouldn’t be doing
that.

Hello,

It looks like this:
http://s14.postimage.org/ndqrbh6xt/dump_test.jpg
so both real parts
are written interleaved into a file.


Discuss-gnuradio
mailing list
[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Try re-enabling
buffering.

Try simplifying your flow, so that you’re doing less
conversion to various forms – each of those steps costs some number of
operations, and your total data flow is 4Msps, because you’re looking at
two channels of 2Msps.

<mleech ripnet.com> writes:

Try re-enabling buffering.
Try simplifying your flow, so that you’re doing less conversion to various
forms – each of those steps costs some number of operations, and your
total
data flow is 4Msps, because you’re looking at two channels of 2Msps.

Ok I tried now to dump both channels directly to a file and turned
buffering on
again. (see http://s14.postimage.org/r5ekme5pd/dump_test.jpg)

The whole datarate is now 22MS/s = 4 MS/s and the disk writing speed
should be
at least 2
2MS/s*4byte/S (I and Q) = 16MB/s. I still get some overruns.

On 07 Nov 2012 10:36, Eral Türkyilmaz wrote:

ripnet.com>
writes:

Try re-enabling buffering. Try simplifying your flow, so
that you’re doing less conversion to various

forms – each of those
steps costs some number of operations, and your total
data flow is
4Msps, because you’re looking at two channels of 2Msps.

Ok I
tried now to dump both channels directly to a file and turned buffering
on
again. (see http://s14.postimage.org/r5ekme5pd/dump_test.jpg)

The whole datarate is now 2*2MS/s = 4 MS/s and the disk writing speed
should be

at least 22MS/s4byte/S (I and Q) = 16MB/s. I still get
some overruns.


Discuss-gnuradio mailing list

[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

What is your
CPU clock speed?

How much memory do you have?

What type of 1GiGE
network interface do you have? This is on an N210?

<mleech ripnet.com> writes:

Discuss-gnuradio Info Page

It’s a Quadcore Intel Core i5-3470CPU (4* 3.2 GHz), I’ve got 8GB RAM and
the
network interface is Intel 82579LM. Yes it is a N210.

<mleech ripnet.com> writes:

There have been problems with the 82579LM dropping packets,
even when there’s no
reason to. There’s a horrible bug in its FIFO logic, apparently.
Various driver
patches have been applied over the years in Linux to try to get around
it,
but at
the end of the day, it’s the hardware.
It wouldn’t surprise me if your problem is
related to that.

Thank you very much for that hint. Do you recommend any special network
card?

On 07 Nov 2012 12:30, Eral Türkyilmaz wrote:

ripnet.com>
writes:

There have been problems with the 82579LM dropping
packets,

even when there’s no
reason to. There’s a horrible bug
in its FIFO logic, apparently.
Various driver
patches have been
applied over the years in Linux to try to get around it,
but at

the end of the day, it’s the hardware.

It wouldn’t surprise me if
your problem is
related to that.

Thank you very much for
that hint. Do you recommend any special network card?


Discuss-gnuradio
mailing list
[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

To be clear,
the 82579LM issue is something you should look in to. Not guaranteed
that’s you’re problem, but I can’t think of another reason.

Also, to
be sure. You are using this interface in 1GiGE mode, right? Connected
directly to the N210 without any switches or other detritus in the
middle?

I use a number of different network interfaces on my machines,
they all work. Even the cheezy RealTek $25.00 1GiGe PCI or PCIe cards
should work for you, particularly at lower sample rates.

On 07 Nov 2012 10:56, Eral Türkyilmaz wrote:

ripnet.com>
writes:

What is your CPU clock speed? How much memory do you have?
What type of 1GiGE network interface do you have? This is on an N210?
_______________________________________________ Discuss-gnuradio mailing
list Discuss-gnuradio gnu.org
Discuss-gnuradio Info Page [1]

It’s a
Quadcore Intel Core i5-3470CPU (4* 3.2 GHz), I’ve got 8GB RAM and the

network interface is Intel 82579LM. Yes it is a N210.


Discuss-gnuradio
mailing list
[email protected]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

There have been
problems with the 82579LM dropping packets, even when there’s no reason
to. There’s a horrible bug in its FIFO logic, apparently. Various driver
patches have been applied over the years in Linux to try to get around
it, but at the end of the day, it’s the hardware. It wouldn’t surprise
me if your problem is related to that.

Links:

<mleech ripnet.com> writes:

To be clear, the 82579LM issue is something you should look in to.
Not guaranteed that’s you’re problem, but I can’t think of another
reason.
Also, to be sure. You are using this interface in 1GiGE mode, right?
Connected directly to the N210 without any switches or other
detritus in the middle?
I use a number of different network interfaces on my machines, they all work.
Even the cheezy RealTek $25.00 1GiGe PCI or PCIe cards should work for
you,
particularly at lower sample rates.

All cards are in gigabit ethernet mode and the USRP is directly
connected to
the network card, so nothing in between.

To be clear, the 82579LM issue is something you should look in to. Not
guaranteed that’s you’re problem, but I can’t think of another reason.
Also, to be sure. You are using this interface in 1GiGE mode, right?
Connected directly to the N210 without any switches or other detritus in
the
middle?
I use a number of different network interfaces on my machines, they all work.
Even the cheezy RealTek $25.00 1GiGe PCI or PCIe cards should work for
you,
particularly at lower sample rates.

I have now tested the same graph
(http://s14.postimage.org/r5ekme5pd/dump_test.jpg) at a lower speed of 1
MS/s
with the 82579LM. It still produces over-runs.

Then I have tested it with two other Intel Network cards (82583V,
82574L)
also at 1 MS/s. They don’t produce overruns. But if I double the sample
rate to 2MS/s I get overruns again.

So the 82579LM definitely performs worse. But the other cards are not
really
much better.

I would like to ask if anybody could try to capture data (see flowgraph)
with
the USRP N210 at such speeds > 2MS/s upto 10MS/s for a longer period of
time
and look if there are overflows?