Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Question on Receiving Data Samples on USRP N210 (Josh Blum)
2. USRP N210 Maximum MTU Size (Robert Palumbo)
3. Re: USRP N210 Maximum MTU Size (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Sat, 16 Jun 2012 09:44:39 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Question on Receiving Data Samples on USRP
N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/15/2012 04:29 PM, Robert Palumbo wrote:
> Hello,
>
> I have a question regarding how receive data packets are handled
> within the UHD ( I am currently using version 003.003.001). When I
> make a call to 'recv' for a single buffer of data samples, how is that
> receive action actually implemented? What I mean is, does the UHD:
>
> a.) Have a separate thread running that constantly receives packets
> and dumps them into some internal buffer, so that when a receive call
> is made you are just receiving data from that internal buffer.
> b.) The call to 'recv' effectively just reads data directly from the
> socket, without any internal buffering.
> c.) Some other method I don't know about :)
>
The stream->recv() call is basically a layer on top of the "transport"
(UDP, USB, etc) that converts samples to the user's requested data type
and parses the VITA header. Any buffering or threading is internal to
the transport. In the case of N210, it depends how your OS implements
the user space socket... which is probably a kernel thread and a lot of
buffering.
This kernel socket buffering is configurable, and you can actually not
call stream->recv() and have the thing entirely fill up with samples all
on its own. Careful, once its full, the kernel will start throwing away
packets.
A little not on resizing this buffer:
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers
And how overflows occur on network devices:
http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes
-Josh
------------------------------
Message: 2
Date: Sat, 16 Jun 2012 21:27:42 -0400
From: Robert Palumbo <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP N210 Maximum MTU Size
Message-ID:
<CAKwzk9wkcFXM5wppaMzm3z=xa3wwap-c3js0xddwh-rgarv...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
Does anyone know if the N210 has a limit on the maximum MTU /
recv_frame_size that it can support? I know that this is also limited
by my network card and configuration, but does the N210 have a limit
on the size of the packets it can send? My network card supports jumbo
packets up to 9KB, so I'd like to increase the MTU on the N210 above
the default 1472bytes.
Thanks for any help,
Rob
--
Robert A Palumbo
[email protected]
------------------------------
Message: 3
Date: Sat, 16 Jun 2012 21:55:41 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N210 Maximum MTU Size
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/16/2012 06:27 PM, Robert Palumbo wrote:
> Hello,
>
> Does anyone know if the N210 has a limit on the maximum MTU /
> recv_frame_size that it can support? I know that this is also limited
> by my network card and configuration, but does the N210 have a limit
> on the size of the packets it can send? My network card supports jumbo
> packets up to 9KB, so I'd like to increase the MTU on the N210 above
> the default 1472bytes.
>
> Thanks for any help,
>
> Rob
With the stock FPGA build you can have up to 4KiB per frame.
Leave a little room for headers.
-josh
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 22, Issue 17
******************************************
