1

I've done a simple test on my little home LAN.

I have enabled broadcast ICMP echo responses with

sysctl net.ipv4.icmp_echo_ignore_broadcasts=0

on just a single host and then pinged a multicast address to see the responses of that host. The round-trip time was consistently around 2-3 milliseconds.

--- 224.0.0.1 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 1000322ms
rtt min/avg/max/mdev = 1.956/3.666/163.318/10.781 ms

However, unicast ping of the peer directly by its IP address measured 0.7-1.5 milliseconds.

--- 192.168.8.23 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 999270ms
rtt min/avg/max/mdev = 0.498/2.459/227.312/12.608 ms

For the sake of completeness, the LAN has wifi link bridged with a 100Mbit Ethernet between the hosts.

So, what's the explanation? Could that be a software problem? Does broadcasting theoretically imply increase in transmission latency? How?

1 Answer 1

5

WiFi link could be your problem if it is in the path. Most broadcast/multicast in WiFi goes at the lowest base/required data rate since it needs to go to all stations. This means it can often get slowed down dramatically.

Multicast across the WiFi link could be going as low as 1Mbps depending on the configuration. This is why multicast is often not allowed on WiFi networks and a number of enterprise vendors implement proprietary solutions (such as multicast to unicast conversions).

2
  • Also many routers and bridges can handle unicast in a faster path then multicast. For example, unicast might be hardware and multicast at interrupt level or unicast might be at interrupt level and multicast at process level. Apr 6, 2013 at 1:33
  • Very true. Since he didn't give much detail in the topology, but did mention WiFi, I picked that out as the most likely source of the delay.
    – YLearn
    Apr 6, 2013 at 4:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .