On Wednesday 02 September 2015 19:47:43 Sven Eckelmann wrote:
[...]
> | kernel          | br-nf-* global | nf-call* iface | download | upload   |
> |-----------------|----------------|----------------|----------|----------|
> | default         | 0              | -              |      209 |      268 |
> | brfilter-global | 0              | -              |      185 |      243 |
> | brfilter-local  | 0              | -              |      187 |      243 |
> | brfilter-local  | 0              | br-lan         |      157 |      226 |
> | brfilter-local  | 0              | br-lan br-wlan |      139 |      161 |
> | brfilter-global | 1              | -              |      136 |      162 |

For people interested for the numbers in a simpler setup (only one bridge and
both eth0 and wlan0 in it):

| kernel          | br-nf-* global | nf-call* iface | download | upload   |
|-----------------|----------------|----------------|----------|----------|
| default         | 0              | -              |      235 |      252 |
| brfilter-global | 0              | -              |      229 |      254 |
| brfilter-local  | 0              | -              |      234 |      251 |
| brfilter-local  | 0              | br-lan         |      195 |      254 |
| brfilter-global | 1              | -              |      194 |      256 |

Download/upload results in Mibit/s

Of course, the br-filter local setup with bridge-nf-call-iptables enabled on
one bridge and disabled on the other bridge is not possible. This is the
reason why the routing test was more interesting for me.

But it can be seen quite good that the relative results for the download are
similar to the ones shown in the routing setup. But the results from the
upload test and the download results for the default kernel are more or less
useless because the wifi is the limiting factor. A barplot of the download
numbers is attached.

I've created a second test to make the CPU the limiting factor. Both eth0 and
wlan0 were added to an HTB filter qdisc limiting the performance to 1 Gibit/s.
This a lot more than the wifi chip can handle.

| kernel          | br-nf-* global | nf-call* iface | download | upload   |
|-----------------|----------------|----------------|----------|----------|
| default         | 0              | -              |      152 |      218 |
| brfilter-global | 0              | -              |      139 |      167 |
| brfilter-local  | 0              | -              |      140 |      170 |
| brfilter-local  | 0              | br-lan         |       97 |      120 |
| brfilter-global | 1              | -              |       94 |      116 |

Now both download and upload show the same relative results as shown in
initial routing test.

Kind regards,
        Sven

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to