Modify

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

Description

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

@nbd,

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 192.168.0.100

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

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

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

Or:

$ 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

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


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

 
Note: See TracTickets for help on using tickets.