Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#10271 closed defect (wontfix)

multicast slow down wifi network dramatically

Reported by: sam.right@… Owned by: nbd
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: Backfire 10.03.1 RC5
Keywords: multicast Cc: ndb


I have a TP-LINK WR841ND running backfire r28215. Whenever I send multicast packages from the lan port of the router the wifi network will somehow becomes very very slow and latency shoots up very high (more than 200ms, typical 1-2 ms) and sometimes it appears it just stops working. The only solution is to stop the application sending multicast packages.

I have tried different multicast applications with the same result (pulseaudio and gstreamer).

It will affect all clients connected to the wifi network (a combination of windows 7, linux and openwrt client).

Attachments (0)

Change History (10)

comment:1 Changed 6 years ago by jow

  • Owner changed from developers to nbd
  • Status changed from new to assigned

comment:2 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from assigned to closed

That's normal. Multicast on wifi is highly inefficient, as it always transmits at low data rates.

comment:3 Changed 6 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened


The things is multicast package will affect tcp packages. When I start sending multicast packages I cannot use ssh session over wifi (latency is too high). I don't think that's a problem with early backfire RC4.

comment:4 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

It's a shared medium. If you waste all your airtime on multicast packets, then the rest is drowned out.

comment:5 Changed 6 years ago by anonymous

Here is the ping result carried out from router:

Sending udp unicast with data rate 180KB/s to wifi client

64 bytes from seq=0 ttl=64 time=2.169 ms
64 bytes from seq=1 ttl=64 time=1.823 ms
64 bytes from seq=2 ttl=64 time=1.954 ms
64 bytes from seq=3 ttl=64 time=4.185 ms
64 bytes from seq=4 ttl=64 time=1.966 ms
64 bytes from seq=5 ttl=64 time=1.712 ms
64 bytes from seq=6 ttl=64 time=1.772 ms
64 bytes from seq=7 ttl=64 time=1.872 ms
64 bytes from seq=8 ttl=64 time=1.679 ms
64 bytes from seq=9 ttl=64 time=2.068 ms
64 bytes from seq=10 ttl=64 time=1.729 ms

If I changed it to multicast to with the same data rate I will have ping latency of 495 ms

64 bytes from seq=6 ttl=64 time=332.718 ms
64 bytes from seq=7 ttl=64 time=288.716 ms
64 bytes from seq=8 ttl=64 time=360.506 ms
64 bytes from seq=9 ttl=64 time=467.513 ms
64 bytes from seq=10 ttl=64 time=535.823 ms
64 bytes from seq=11 ttl=64 time=602.423 ms
64 bytes from seq=12 ttl=64 time=723.464 ms
64 bytes from seq=13 ttl=64 time=770.879 ms
64 bytes from seq=14 ttl=64 time=873.501 ms
64 bytes from seq=15 ttl=64 time=939.214 ms
64 bytes from seq=16 ttl=64 time=102.203 ms
64 bytes from seq=17 ttl=64 time=154.208 ms
64 bytes from seq=18 ttl=64 time=184.460 ms
64 bytes from seq=19 ttl=64 time=209.937 ms
64 bytes from seq=20 ttl=64 time=305.959 ms
64 bytes from seq=21 ttl=64 time=363.927 ms
64 bytes from seq=22 ttl=64 time=425.938 ms
64 bytes from seq=23 ttl=64 time=474.164 ms
64 bytes from seq=24 ttl=64 time=576.083 ms
64 bytes from seq=25 ttl=64 time=628.175 ms
64 bytes from seq=26 ttl=64 time=763.641 ms
64 bytes from seq=27 ttl=64 time=812.229 ms
64 bytes from seq=28 ttl=64 time=883.051 ms
64 bytes from seq=29 ttl=64 time=945.278 ms
64 bytes from seq=30 ttl=64 time=353.831 ms
64 bytes from seq=31 ttl=64 time=121.705 ms
64 bytes from seq=32 ttl=64 time=178.086 ms

This is 27000% increase in latency.

comment:6 Changed 6 years ago by nbd

Yes, as I said: multicast packets use the lowest data rate, so they use *much* more airtime.

comment:7 Changed 5 years ago by anonymous

It seems there is a bug in OpenWRT as well.

When I send multicast from station A on 2.4GHz and do a tcpdump on station B on 2.4GHz as well as on OpenWRT on 2.4GHz, I see some packet loss on station B, but a multiple of packets on OpenWRT.

Seems like about 50% more packets are received by an interface-specific tcpdump running on the 2.4GHz interface on OpenWRT, than are actually transmitted from station A.

Additionally, if I move station B to the 5 GHz radio and start a tcpdump and run the test again, I see multicast packets broadcast on the 2.4 GHz band.

Seems like OpenWRT is actively forwarding multicast packets.

(Which it shouldn't, because radio is a shared medium, so other stations will see the multicast even without packets being re-broadcast by OpenWRT.)

comment:8 Changed 5 years ago by anonymous

Also, to everyone who is doing multicast tests, remember to disable power management. It should be disabled on OpenWRT by default, but might not be disabled on your stations. Do:

$ iwconfig wlan0 power off


$ iw dev wlan0 set_power off

You can also fine-tune which packets that wake up the radio circuitry, eg. set whether it is sensitive to any of {multicast,broadcast,unicast} (bitmask) and how many micro- or milliseconds of idle time the radio will let pass before it goes into power-save.

If you do not disable power save, one of the symptoms you will see is very high ping times (as seen above).

comment:9 Changed 5 years ago by anonymous

(incidentally, enabling wlan power save is a great way to decrease battery load on a linux laptop, if your driver supports it. buut that's entirely unrelated..)

comment:10 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.