Re: [Discuss-gnuradio] Question about packet sequence

SangHyuk,

I'm really getting desparate.
The fact that your application generates 400B over-the-air packets has nothing to do with the size of the sample packets going through Ethernet. Stop assuming that.

I expected one send() be represented one packet at wireshark.

You should not expect that. send() can, and will, fragment your data. See the documentation[1] that explicitely explains that:

Send buffers containing samples described by the metadata.

Send handles fragmentation as follows: If the buffer has more items than the maximum per packet, the send method will fragment the samples across several packets. Send will respect the burst flags when fragmenting to ensure that start of burst can only be set on the first fragment and that end of burst can only be set on the final fragment.

So, to answer the question you've been asking several times, and got the same answer every time:

Why does number of packet shown in wireshark is differ from transmitted packets ?

Because what you consider "packets" has nothing to do with what wireshark sees as network packets.

Best regards,
Marcus

[1] http://files.ettus.com/manual/classuhd_1_1tx__streamer.html#aeb2e0f44810693d9da99ea1e04fad21f

On 14.04.2016 08:46, SangHyuk Kim wrote:

Hi,

I counted number of sending packet in code and wireshark.

I send 400Bytes packet, but wireshark packet be shown about 1500Bytes.

While coded counter shows about 50,000 packets (data packet), wireshark captured 450,000 packets.

I expected one send() be represented one packet at wireshark.

Why does number of packet shown in wireshark is differ from transmitted packets ?

Thanks for your help.

2016-04-14 15:20 GMT+09:00 Laur Joost <daremion@gmail.com>:

While UDP gives no order guarantee, the USRP still sends them out in order. The uncertainty comes in cases where routing happens between the USRP and the host. Still, within a LAN you can expect with relative certainty, that packets will still arrive in order, as there is usually only one route from device to host.

1. The sequence of the packets is important. It would be rather bad if two bunches of samples in your IQ stream suddenly switched places.

2. The host PC network stack does no reordering. It can't, by definition of UDP, as there's nothing to reorder by.

3. AFAIK, the UHD also does no reordering. However, the packets arriving from the USRP __are__ numbered. If UHD detects a missing packet, it* prints a D (to signify a Dropped packet) to stdout, and emits a new rx_time tag for the next packet.

* Actually, I don't know whether that's UHD or gr-uhd that does this.

Hope it helped

Laur

2016-04-14 8:41 GMT+03:00 SangHyuk Kim <tkdgur7896@gmail.com>:

Hi all,

I'm wondering about packet sequence.

USRP sends UDP packets which is result of sampling to host PC.

UDP packets tend to be out-of-order at high speed.

My question is:

- When USRP sends UDP packet high speed to host PC, the sequence of these packets is important ?

- Do host PC reorder these packet ? (Do PC waits for certain packet ?)

Thanks.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio