I'm not quite understanding expected total of packets sent and was wondering if i'm on the right path. I have 4 computers, A, B, C, D and they relay the message from A, so A->B->C->D and I don't count transmitting back from D. And they have a packet loss of 3%. UDP on ipv4 and message must arrive for the expected destination
Say if i was to send 1000mb along a 350 byte payload
= 1000mb = 1024*1024*1000 bytes =
1048576000 bytes / 350 = 2995931.4286 packets sent
If i also had a 3% packet loss for every 100 packets
2995931.42857 * .03/100 = 8987.7943 packet loss
Does that mean i'd compute,
2995931.42857 + 8987.7943 * 3 for each transmission by each computer for extra resubmitted packets?
-Thanks heaps
Related
Currently I am capturing network packets using tcpreplay at a speed of 800 MBPS but I want to scale it over 5 GBPS.
I am running Joy on a server with 16GB Ram and 8 Cores
Tcpreplay Output:
`Actual: 2427978 packets (2098973496 bytes) sent in 20.98 seconds
Rated: 100003501.6 Bps, 800.02 Mbps, 115678.59 pps
Flows: 49979 flows, 2381.11 fps, 2426216 flow packets, 1756 non-flow
Statistics for network device: vth0
Successful packets: 2427978
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0`
Total Packets Captured: 2412876
I am running Joy on 4 threads but even if I use 24 threads I am not able to see any drastic change in the capturing or receiving speed.
Joy is using af_packet with Zero Copy Ring Buffer and even Cisco mercury use the same mechanism to write packets but they claim that Mercury can write at 40 GBPS on a server-class hardware so anyone have any suggestion on this issue then please revert back.
I have a traffic dump in csv file containing packet arrival time, frame length and boolean values for multiple flags.
Can someone please explain how to calculate packet size from the traffic dump.
I further want to generate distribution of the packet size in python.
I am using istio sevrice mesh for EKS services.
I would like to capture packet info of every path based request that comes to my virtual sevrices.
What is the best approach to capture this info?
-- I would like to capture packet count, packet size, payload sz and URI say like this:
packet count = x, packet sz = y, payload sz = z, URI = GET //login HTTP/1.1
I have a question in order to understand how iperf is working, I am using the following command.
What i dont understand is "How can 6945 datagrams are send?" because if 9.66 MBytes are transfered, then 9.66M/1458 = 6625 data grams should be tranfereded according to my understanding.
If 10.125MBytes (2.7Mbps * 30 sec) would have been transfered then 6944 data grams would have been send (excluding udp and other header)
Please clerify if some one knows ..
(Also I have used wireshark on both client and server and checked and there the number of packets is greater then the number of packets shown by iperf)
umar#umar-VPCEB11FM:~$ iperf -t 30 -c 192.168.3.181 -u -b 2.7m -l 1458
------------------------------------------------------------
Client connecting to 192.168.3.181, UDP port 5001
Sending 1458 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.3.175 port 47241 connected with 192.168.3.181 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 9.66 MBytes 2.70 Mbits/sec
[ 3] Sent 6946 datagrams
[ 3] Server Report:
[ 3] 0.0-92318.4 sec 9.66 MBytes 878 bits/sec 0.760 ms 0/ 6945 (0%)
iperf uses base 2 for M and K, meaning that K = 1024 and M = 1024*1024.
When you do that math that way, you get 9.66 MB / 1458 B/d = 6947 datagrams which is within precision error (you have a max resolution of 0.01 MB which means a rounding error of 0.005 MB ~= 3.6 datagrams).
after ARP protocol in a frame, there are many 0 bytes. Does anyone know the reason for the existence of these 0 bytes?
Check the Ethernet II accordion, all the 0 are labelled as padding.
Ethernet requires that all packets be at least 60 bytes long (64 bytes if you include the Frame Check Sequence at the end), so if a packet is less than 60 bytes long (including the 14-byte Ethernet header), additional padding bytes have to be added to the end of the packet.
(Those padding bytes will not show up on packets sent by the machine running Wireshark; the padding is added by the Ethernet hardware, and packets being sent by the machine capturing the traffic are given to the program before being handed to the hardware, so they haven't been padded.)