LinuxQuestions.org - Why RTTs of unicast are different to the RTTs of broadcast?

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - Why RTTs of unicast are different to the RTTs of broadcast? (https://www.linuxquestions.org/questions/linux-networking-3/why-rtts-of-unicast-are-different-to-the-rtts-of-broadcast-813872/)

Why RTTs of unicast are different to the RTTs of broadcast?

Greetings.

I was recently "playing" with ping in order to measure some RTT both in unicast and broadcast cases but ran into something that left me like O.o wtf!

Here is the output of a ping to a private host in my LAN, a normal unicast case:

Code:

64 bytes from 192.168.2.3: icmp_seq=1 ttl=64 time=0.617 ms

64 bytes from 192.168.2.3: icmp_seq=2 ttl=64 time=1.27 ms

64 bytes from 192.168.2.3: icmp_seq=3 ttl=64 time=0.595 ms

64 bytes from 192.168.2.3: icmp_seq=4 ttl=64 time=2.22 ms

64 bytes from 192.168.2.3: icmp_seq=5 ttl=64 time=0.654 ms

64 bytes from 192.168.2.3: icmp_seq=6 ttl=64 time=0.630 ms

And here is the sudo ping -b 255.255.255.255 with the answers of the same host as in the unicast case:

Code:

64 bytes from 192.168.2.3: icmp_seq=1 ttl=64 time=1.87 ms

64 bytes from 192.168.2.3: icmp_seq=2 ttl=64 time=66.5 ms

64 bytes from 192.168.2.3: icmp_seq=3 ttl=64 time=88.9 ms

64 bytes from 192.168.2.3: icmp_seq=4 ttl=64 time=1.88 ms

64 bytes from 192.168.2.3: icmp_seq=5 ttl=64 time=1.89 ms

64 bytes from 192.168.2.3: icmp_seq=6 ttl=64 time=53.5 ms

Can somebody explain me why do those ugly numbers appear? Is there a different process that ping uses to calculate RTTs in the case of a broadcast. As far as i know the RTTs to a host should be more or less equal either in unicast or broadcast case.

Is something I am forgetting here?

Thanks in advance for your help. =)

I am pretty sure that waits for all others to reply. What are you trying to do? Are you trying to smurf?

No, nothing like that. I am testing a virtual network and I needed to compare the RTTs in broadcast and in unicast. That's why I am interested in the high RTTs appreciated in the broadcast responses.

-b is looking for all replies on lan isn't it?

Yes, but shouldn't the process be like independent per reply? I mean, the broadcast message is sent to everybody and gets to each machine in different time, and each machine responses with different delay. But this delay should be similar to the delay of a normal ping to a machine. Becuase in the end the the physical path is the same for both unicast or broadcast. Or am I mistaken in the last?

If using a share media network (Wi-Fi, DOCSIS, Ethernet with hubs, Ethernet over coax) collisions between replies, followed by retransmission after a random delay are possible.

Quote:

Originally Posted by TimothyEBaldwin (Post 4005595)

If using a share media network (Wi-Fi, DOCSIS, Ethernet with hubs, Ethernet over coax) collisions between replies, followed by retransmission after a random delay are possible.

But in the case of a switched LAN, if there are no collisions why do the RTTs show a higher value? Is there something to do with the algorithm? Becuase doing a test, for example between two hosts at a distance of 0 hops, exactly in the same LAN there is a difference, slight, but a difference anyway. (such as 0.980ms for unicast and 1.2ms for broadcast)