Regarding 371 samples/frame in usrp2

GNU Radio
1

I have been playing with ioctl’s today and while browsing the USRP2-
code i found that max length of a packet is defined to 371 which results
in 1484 bytes of “data”, and 16 bytes left, leaving room for the 14 byte
ethernet header, but not a 372:nd sample, since each sample is 4 bytes.

But when I look at the output of ifconfig my MTU is set to 1500, but
when I print out how much data is received from a raw socket (listening
to some random network traffic), it tells me it reads max 1514 bytes,
which I figured is 1500 bytes of data, and 2*6 bytes mac- addresses + 2
bytes of protocol. This gives me two questions. Is there (probably)
something I missed here, or should we be able to increase U2_MAX_SAMPLES
to 375 (1500/4 = 375), not that four samples might make a huge
difference in the end, but still… And the other question, shouldn’t
one check for the MTU set by the nic and calculate this number, instead
of having it #defined? But then again, it would be a whole lot of re-
writing, since U2_MAX_SAMPLES is #defined… Or have I missed some
fundamental here?

BR
Mattias K.

2

On Wed, Nov 05, 2008 at 06:15:03PM +0100, Mattias K. wrote:

something I missed here, or should we be able to increase U2_MAX_SAMPLES
to 375 (1500/4 = 375), not that four samples might make a huge
difference in the end, but still… And the other question, shouldn’t
one check for the MTU set by the nic and calculate this number, instead
of having it #defined? But then again, it would be a whole lot of re-
writing, since U2_MAX_SAMPLES is #defined… Or have I missed some
fundamental here?

BR
Mattias K.

There are a couple of headers. See usrp2_eth_packet.h (This format is
all subject to change.) We’ll be modifying the code so that it checks
for the actual MTU and does the right thing. It’s ticket:310.

Thanks for your concern,
Eric

3

Eric B. wrote:

which I figured is 1500 bytes of data, and 2*6 bytes mac- addresses + 2
Mattias K.

There are a couple of headers. See usrp2_eth_packet.h
So I have. Regarding the channel and timestamp fields in “struct
u2_fixed_hdr_t”, channel is going to (when implemented) reflect which
usrp2 you want to “speak” with, when mimo- configured? For instance say
I have two usrp2 connected with a mimo- cable. Then I send data to
usrp2#1 on channel #1 and to usrp2#2 on channel #2, while I still use
channel #0 to configure them? Or is this functionality still to much on
the drawing- board to be able to say "this is how it’s (going to(?))
work.

The timestamp in the same header, supposed to reflect when it’s going to
be sent out on the antenna, when it was received to the usrp2, when it
left the host- computer, or any of the above, depending on what the
current time is, and what the timestamp is? Or is this function as well
in to early stages to say?

(This format is all subject to change.)
So I have noticed :wink:
We’ll be modifying the code so that it checks
for the actual MTU and does the right thing. It’s ticket:310.

I might have some code to do precisely this, but I don’t know if it is
as portable and neat as the rest of the code in here, and as I mentioned
earlier I’m not sure exactly where U2_MAX_SAMPLES is used, but I guess
“it’s just trail and error, compile and re- write”, that does the trick?

BR
//Mattias K.

4

Eric B. wrote:

usrp2#1 on channel #1 and to usrp2#2 on channel #2, while I still use
distinguish which logical pipeline (stream) the data is from or for.
The mimo stuff is really just a generalization of support for multiple
streams within a single USRP.

Then I probably have to read up on what VRT is…

about this on the list about a month ago with regard to the USRP1
inband code.

If the host cares, it’ll have to compute the delay from the head of
the DSP pipeline to the antenna. This is composed of at least the
pipeline delay, the group delay through the DSP filters, any internal
pipeline and group delays in the A/D, etc.

Well, at least now I know when the times are set, which means I have to
think about what it means :slight_smile: But another way would be to have a look at
the inband- code to usrp1 and try to understand what it actually does,
since the time- stamps are set at the “same places”, just to get a
crash- course in time- stamps, and maybe, just maybe be able to actually
use that to something useful.

as portable and neat as the rest of the code in here, and as I mentioned
MTU configured, we need some way to figure out if the interface can
handle jumbo frames or not.

If you’ve got code that figures this out on a variety of OS’s, I’d
love to take a look at it.

Well, I must say, you got me there, the code I have is only tested on
linux (Slackware and Ubuntu), and it doesn’t really deal with any
hardware. So there isn’t really any piece of code I have laying around
that would fit nicely into the gnuradio- trunk, what I do have is code
for reading/writing mtu (which isn’t anything to brag with or put on
ones resume…)

Jumbo- frames, as I have come to understand it, is just a large frame,
but as far as I have seen there isn’t any easy method to test for
support of it.

Basically, I would as well love to see the code that does all the things
above.

Regarding the available memory on the usrp2. There is another field
amongst the headers I’m a bit curious about.
uint16_t fifo_status in the transport header. How should this be
interpreted? As 16 bits which represent full/empty line of 32 bit. That
would give 16bit*32bit = 128 byte of Rx- fifo?

Best regards
Mattias K.

5

On Wed, Nov 05, 2008 at 07:30:01PM +0100, Mattias K. wrote:

the drawing- board to be able to say "this is how it’s (going to(?))
work.

Probably too early on this. We’ll probably be moving to something
that looks like VRT (“Virtual Radio Transport” a.k.a VITA 49 – a
format for digitized IF data), and possibly over UDP instead of raw
ethernet. In any event there will be some way to distinguish control
packets from data packets, and for each of those types, some way to
distinguish which logical pipeline (stream) the data is from or for.
The mimo stuff is really just a generalization of support for multiple
streams within a single USRP.

The timestamp in the same header, supposed to reflect when it’s going to
be sent out on the antenna, when it was received to the usrp2, when it
left the host- computer, or any of the above, depending on what the
current time is, and what the timestamp is? Or is this function as well
in to early stages to say?

On Tx, the timestamp is the time when the samples will be clocked into
the DSP pipeline. On Rx, the timestamp is the time that the first
sample was clocked out of the DSP pipeline. There was a discussion
about this on the list about a month ago with regard to the USRP1
inband code.

If the host cares, it’ll have to compute the delay from the head of
the DSP pipeline to the antenna. This is composed of at least the
pipeline delay, the group delay through the DSP filters, any internal
pipeline and group delays in the A/D, etc.

(This format is all subject to change.)
So I have noticed :wink:

We’ll be modifying the code so that it checks
for the actual MTU and does the right thing. It’s ticket:310.

I might have some code to do precisely this, but I don’t know if it is
as portable and neat as the rest of the code in here, and as I mentioned
earlier I’m not sure exactly where U2_MAX_SAMPLES is used, but I guess
“it’s just trail and error, compile and re- write”, that does the trick?

The header in question is used by the firmware and the host. We need
to represent (somewhere) the maximum physical buffer size that’s
available in the USRP and then derive a maximum number of samples that
the USRP can possibly handle based on that number and the sizes of the
various headers. That will set one upper bound. The MTU of the link,
if configured, is another upper bound. For interfaces that have no
MTU configured, we need some way to figure out if the interface can
handle jumbo frames or not.

If you’ve got code that figures this out on a variety of OS’s, I’d
love to take a look at it.

Eric

6

On Thu, Nov 06, 2008 at 05:02:46PM +0100, Mattias K. wrote:

Eric B. wrote:

Then I probably have to read up on what VRT is…

about this on the list about a month ago with regard to the USRP1
since the time- stamps are set at the “same places”, just to get a
crash- course in time- stamps, and maybe, just maybe be able to actually
use that to something useful.

FYI, I’m not up-to-date on the status of the USRP1 inband code. Eric
Schneider was working on bugfixing/rewriting part of it, but we
haven’t heard from him in a while. Eric, anything to report?

If you’ve got code that figures this out on a variety of OS’s, I’d
love to take a look at it.

Well, I must say, you got me there, the code I have is only tested on
linux (Slackware and Ubuntu), and it doesn’t really deal with any
hardware. So there isn’t really any piece of code I have laying around
that would fit nicely into the gnuradio- trunk, what I do have is code
for reading/writing mtu (which isn’t anything to brag with or put on
ones resume…)

In any event, I’d like to see what you’ve got.

Regarding the available memory on the usrp2. There is another field
amongst the headers I’m a bit curious about.
uint16_t fifo_status in the transport header. How should this be
interpreted? As 16 bits which represent full/empty line of 32 bit. That
would give 16bit*32bit = 128 byte of Rx- fifo?

The 32-bit reference means that it’s counting in units of 32-bit
integers (4 bytes). The field is currently a place holder. They idea
is to use some kind of a window to flow control the host -> usrp
direction. The usrp -> host direction doesn’t require flow control
since the usrp sends at a constant rate determined by the host.
If the host can’t keep up, the host is by definition misconfigured or
broken.

Eric