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 <darem...@gmail.com > <mailto:darem...@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 <tkdgur7...@gmail.com > <mailto:tkdgur7...@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 <mailto: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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
