* [Cake] WAN ingress rate with concurrent downloads
[not found] <mailman.5.1477497601.28053.cake@lists.bufferbloat.net>
@ 2016-10-27 0:10 ` G. Amanakis
2016-10-27 0:16 ` G. Amanakis
0 siblings, 1 reply; 10+ messages in thread
From: G. Amanakis @ 2016-10-27 0:10 UTC (permalink / raw)
To: cake
[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]
Hi All,
I noticed that the ingress rate on the WAN interface as reported by bmon or bwm-ng does not reflect the setting in cake (on ifb ingress or on LAN egress) when one of the hosts is using bittorrent or when there are more than 3 concurrent downloads on a 3300kbit/s bandwidth (router behind cable modem). With 1-2 concurrent downloads (i.e. connections) the ingress rate reported on WAN matches the limit set in cake. The same thing happens with HTB, TBF, or the police action. Any ideas why?
Greetings,
George
On October 26, 2016 12:00:01 PM EDT, cake-request@lists.bufferbloat.net wrote:
>Send Cake mailing list submissions to
> cake@lists.bufferbloat.net
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.bufferbloat.net/listinfo/cake
>or, via email, send a message with subject or body 'help' to
> cake-request@lists.bufferbloat.net
>
>You can reach the person managing the list at
> cake-owner@lists.bufferbloat.net
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Cake digest..."
>
>
>Today's Topics:
>
> 1. what if you don't need conntracking? (Dave Taht)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 26 Oct 2016 07:19:25 -0700
>From: Dave Taht <dave.taht@gmail.com>
>To: cake@lists.bufferbloat.net
>Subject: [Cake] what if you don't need conntracking?
>Message-ID:
> <CAA93jw7mp-ht-vATvnSuq_6uSUJK=i_T_-br+pAMoHLpGM4aOA@mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>At least in my case I have several places where I don't use conntrack
>(a firewall elsewhere) - does trying to use conntrack by default in
>cake pull in the module?
>
>https://developers.soundcloud.com/blog/shoot-yourself-in-the-foot-with-iptables-and-kmod-auto-loading
>
>--
>Dave Täht
>Let's go make home routers and wifi faster! With better software!
>http://blog.cerowrt.org
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Cake mailing list
>Cake@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cake
>
>
>------------------------------
>
>End of Cake Digest, Vol 19, Issue 27
>************************************
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2416 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
2016-10-27 0:10 ` [Cake] WAN ingress rate with concurrent downloads G. Amanakis
@ 2016-10-27 0:16 ` G. Amanakis
2016-10-27 6:41 ` Sebastian Moeller
2016-10-28 1:34 ` Georgios Amanakis
0 siblings, 2 replies; 10+ messages in thread
From: G. Amanakis @ 2016-10-27 0:16 UTC (permalink / raw)
To: cake
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
I mean that the ingress limit on WAN (or egress limit on LAN) seems to be ignored, and the rate bmon and bwm-ng report is the maximum achievable. I.e. on 450kbyte/s ingress with the limit set at 400kbyte/s, when bittorrent is in use bmon reports 450kbyte/s after 10-20 seconds.
[-- Attachment #2: Type: text/html, Size: 277 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
2016-10-27 0:16 ` G. Amanakis
@ 2016-10-27 6:41 ` Sebastian Moeller
2016-10-27 16:42 ` Noah Causin
2016-10-28 1:34 ` Georgios Amanakis
1 sibling, 1 reply; 10+ messages in thread
From: Sebastian Moeller @ 2016-10-27 6:41 UTC (permalink / raw)
To: G. Amanakis, cake
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]
Could you set the ingress shaper to 50% of you true ingress rate and try again, please?
Also could you post the results of 'tc -d qdisc' with your current settings and with the 50% settings (I will probably ask for more data...)? And finally I believe you are on an ADSL link, what are the sync rates reported by the modem, and which ISP are you with (I ask, as some ISPs actually employ a shaper at their BRAS, so the modem sync rate might not be the actual bottleneck bandwidth). That said, with wrong shaper settings I would rather expect increased latency under load, but not bandwidth violations.
Best Regards
Sebastian
On October 27, 2016 2:16:06 AM GMT+02:00, "G. Amanakis" <g_amanakis@yahoo.com> wrote:
>I mean that the ingress limit on WAN (or egress limit on LAN) seems to
>be ignored, and the rate bmon and bwm-ng report is the maximum
>achievable. I.e. on 450kbyte/s ingress with the limit set at
>400kbyte/s, when bittorrent is in use bmon reports 450kbyte/s after
>10-20 seconds.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Cake mailing list
>Cake@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cake
[-- Attachment #2: Type: text/html, Size: 1545 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
2016-10-27 6:41 ` Sebastian Moeller
@ 2016-10-27 16:42 ` Noah Causin
0 siblings, 0 replies; 10+ messages in thread
From: Noah Causin @ 2016-10-27 16:42 UTC (permalink / raw)
To: cake
[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]
I notice this behavior as well. I believe it is the fact that SQM is
not the true bottleneck. Senders continue to increase their transfer
rate until active queue management on your router causes them to slow down.
If I watch LEDE's built-in realtime traffic graphs, I do see incoming
rates higher than the set limit.
On 10/27/2016 2:41 AM, Sebastian Moeller wrote:
> Could you set the ingress shaper to 50% of you true ingress rate and
> try again, please?
> Also could you post the results of 'tc -d qdisc' with your current
> settings and with the 50% settings (I will probably ask for more
> data...)? And finally I believe you are on an ADSL link, what are the
> sync rates reported by the modem, and which ISP are you with (I ask,
> as some ISPs actually employ a shaper at their BRAS, so the modem sync
> rate might not be the actual bottleneck bandwidth). That said, with
> wrong shaper settings I would rather expect increased latency under
> load, but not bandwidth violations.
>
> Best Regards
> Sebastian
>
> On October 27, 2016 2:16:06 AM GMT+02:00, "G. Amanakis"
> <g_amanakis@yahoo.com> wrote:
>
> I mean that the ingress limit on WAN (or egress limit on LAN)
> seems to be ignored, and the rate bmon and bwm-ng report is the
> maximum achievable. I.e. on 450kbyte/s ingress with the limit set
> at 400kbyte/s, when bittorrent is in use bmon reports 450kbyte/s
> after 10-20 seconds.
>
> ------------------------------------------------------------------------
>
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
[-- Attachment #2: Type: text/html, Size: 2844 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
2016-10-27 0:16 ` G. Amanakis
2016-10-27 6:41 ` Sebastian Moeller
@ 2016-10-28 1:34 ` Georgios Amanakis
2016-10-28 7:45 ` Sebastian Moeller
1 sibling, 1 reply; 10+ messages in thread
From: Georgios Amanakis @ 2016-10-28 1:34 UTC (permalink / raw)
To: cake
Hi Sebastian,
the ISP is Comcast in MD, USA, residential connection. It is a cable
connection (i.e. the WAN port on the modem is a coaxial one) and not a
DSL one. Maximum ingress rate is ~450kbytes/s which is what the modem
syncs at. By using "test_WAN_dual-isolate__piece_of_cake.qos", "tc -d
qdisc show" reports (enp0s13 is WAN, enp0s14 is LAN):
-------8<--------
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq_codel 0: dev enp0s14 root refcnt 2 limit 10240p flows 1024
quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc cake 8002: dev enp0s13 root refcnt 2 bandwidth 900Kbit besteffort
dual-srchost nat rtt 100.0ms raw
qdisc ingress ffff: dev enp0s13 parent ffff:fff1 ----------------
qdisc fq_codel 0: dev ifb0 root refcnt 2 limit 10240p flows 1024
quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc cake 8003: dev ifb4enp0s13 root refcnt 2 bandwidth 3300Kbit
besteffort dual-dsthost nat rtt 100.0ms raw
-------8<--------
If one of the hosts on LAN is running bittorrent, bmon on the gateway
reports:
RX bps RXpps TX bps TXpps
enp0s14 23.55KiB 303 402.87KiB 322
enp0s13 457.26KiB 369 25.04KiB 307
Setting the ingress rate at 1900kbps (instead of 3300kbps as above),
"tc -d qdisc show" reports:
-------8<--------
qdisc noqueue 0: dev lo root refcnt 2
qdisc fq_codel 0: dev enp0s14 root refcnt 2 limit 10240p flows 1024
quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc cake 8008: dev enp0s13 root refcnt 2 bandwidth 900Kbit besteffort
dual-srchost nat rtt 100.0ms raw
qdisc ingress ffff: dev enp0s13 parent ffff:fff1 ----------------
qdisc fq_codel 0: dev ifb0 root refcnt 2 limit 10240p flows 1024
quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc cake 8009: dev ifb4enp0s13 root refcnt 2 bandwidth 1900Kbit
besteffort dual-dsthost nat rtt 100.0ms raw
-------8<--------
Using bittorrent, bmon on the gateway reports:
RX bps RXpps TX bps
TXpps
enp0s14 19.25KiB 219 232.51KiB 184
enp0s13 393.36KiB 304 20.25KiB 220
In both cases the ingress rate limit on the WAN interface (enp0s13) is
not obeyed. I verified these data by using tcpdump and doing an IO-
Graph with wireshark.
Looking forward to your feedback,
George
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
2016-10-28 1:34 ` Georgios Amanakis
@ 2016-10-28 7:45 ` Sebastian Moeller
0 siblings, 0 replies; 10+ messages in thread
From: Sebastian Moeller @ 2016-10-28 7:45 UTC (permalink / raw)
To: Georgios Amanakis; +Cc: cake
Hi Georgios,
> On Oct 28, 2016, at 03:34, Georgios Amanakis <g_amanakis@yahoo.com> wrote:
>
> Hi Sebastian,
>
> the ISP is Comcast in MD, USA, residential connection. It is a cable
> connection (i.e. the WAN port on the modem is a coaxial one) and not a
> DSL one.
Interesting, from the bandwidth I had assumed ADSL ;)
> Maximum ingress rate is ~450kbytes/s which is what the modem
> syncs at.
MMh typically sync-rates are soecified in Kbps or 10^3 Bits per second, not KiloBytes and certainly not 2^10 Bytes; could you clarify what exactly your modem reports and what the best numbers you get from speedtests (like dslreoorts.com) without active AQM/cake/htb, please?
> By using "test_WAN_dual-isolate__piece_of_cake.qos", "tc -d
> qdisc show" reports (enp0s13 is WAN, enp0s14 is LAN):
> -------8<--------
> qdisc noqueue 0: dev lo root refcnt 2
> qdisc fq_codel 0: dev enp0s14 root refcnt 2 limit 10240p flows 1024
> quantum 1514 target 5.0ms interval 100.0ms ecn
> qdisc cake 8002: dev enp0s13 root refcnt 2 bandwidth 900Kbit besteffort
> dual-srchost nat rtt 100.0ms raw
> qdisc ingress ffff: dev enp0s13 parent ffff:fff1 ----------------
> qdisc fq_codel 0: dev ifb0 root refcnt 2 limit 10240p flows 1024
> quantum 1514 target 5.0ms interval 100.0ms ecn
> qdisc cake 8003: dev ifb4enp0s13 root refcnt 2 bandwidth 3300Kbit
> besteffort dual-dsthost nat rtt 100.0ms raw
> -------8<--------
>
> If one of the hosts on LAN is running bittorrent, bmon on the gateway
> reports:
> RX bps RXpps TX bps TXpps
> enp0s14 23.55KiB 303 402.87KiB 322
> enp0s13 457.26KiB 369 25.04KiB 307
>
Okay so:
900Kbps = 900 * 1000 / (8 * 1024) = 109.86328125 KiB
3300Kbps = 3300 * 1000 / (8 * 1024) = 402.83203125 KiB
So it looks like enp0s14-TX actually shows the specified internet-download rate, (internet upload is not maxed out)
>
> Setting the ingress rate at 1900kbps (instead of 3300kbps as above),
> "tc -d qdisc show" reports:
> -------8<--------
> qdisc noqueue 0: dev lo root refcnt 2
> qdisc fq_codel 0: dev enp0s14 root refcnt 2 limit 10240p flows 1024
> quantum 1514 target 5.0ms interval 100.0ms ecn
> qdisc cake 8008: dev enp0s13 root refcnt 2 bandwidth 900Kbit besteffort
> dual-srchost nat rtt 100.0ms raw
> qdisc ingress ffff: dev enp0s13 parent ffff:fff1 ----------------
> qdisc fq_codel 0: dev ifb0 root refcnt 2 limit 10240p flows 1024
> quantum 1514 target 5.0ms interval 100.0ms ecn
> qdisc cake 8009: dev ifb4enp0s13 root refcnt 2 bandwidth 1900Kbit
> besteffort dual-dsthost nat rtt 100.0ms raw
> -------8<--------
>
> Using bittorrent, bmon on the gateway reports:
> RX bps RXpps TX bps
> TXpps
> enp0s14 19.25KiB 219 232.51KiB 184
> enp0s13 393.36KiB 304 20.25KiB 220
>
Okay so:
900Kbps = 900 * 1000 / (8 * 1024) = 109.86328125 KiB
3300Kbps = 1900 * 1000 / (8 * 1024) = 231.93359375 KiB
And again enp0s14-TX shows the specified internet-download rate, (internet upload is not maxed out)
For me this looks like bwmon accounts the incoming packets before cake sees and drops them (the enp0s14-TX shows that cake does only transmit the specified rate into the LAN, so cake does its job)). Then the fact that enp0s13 (btw these new interface names have not yet grown on me, yuck) sees more incoming packets simply means that the bit torrent peers are an unruly bunch and do not react nicely to cakes drops and marks (are the packets ECN labeled?). Bit-torrent, when using its µTP protocol tries to use increasing delay as signal to throttle, but cake removes that latency increase under load, which mjight make the torrent peers not scale back their TX rates based on a wrong believe that there is more link capacity available. Not that anybody asks me, but I believe µTP actively is a bad thing and all torrent peers shoud default to TCP instead of µTP?UDP, but I digress.
> In both cases the ingress rate limit on the WAN interface (enp0s13) is
> not obeyed. I verified these data by using tcpdump and doing an IO-
> Graph with wireshark.
Well that is true in that cake does not run a lower rate on the ethernet interface, but what it does happens after packets are passed from the NIC to the OS. Again I believe you just show bit-torrent misbehaving, a nice illustration why we can’t have nice things, erm why non-latency-inducing shapers, like cake and HTB+fq_codel have a hard time ruling in bit-torrent… BTW, can you see from your packet captures how long a typical torrent-flow actually exists and is active? So are these say a few dozend long-term flows or a swarm of dozens of flows that come and go on a seconds time-frame?
Best Regards
Sebastian
>
> Looking forward to your feedback,
P.S.: I am just an amateur in these matters, so other’s on the cake list will surely be able to give better advice. So @experts, please holler if my theory above does not make sense...
> George
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
2016-12-09 19:11 ` George Amanakis
@ 2016-12-10 19:33 ` Benjamin Cronce
0 siblings, 0 replies; 10+ messages in thread
From: Benjamin Cronce @ 2016-12-10 19:33 UTC (permalink / raw)
To: George Amanakis; +Cc: cake
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
It sounds like the sender has a buffer bloat issue. I see the same thing
with bittorrent and tcp. If I rate limit my 150mb connection to 100mb, I
will see about 30-40mb of retransmissions, for a total of ~135mb of
ingress. Even though I limit only to 100mb.
If I trace route the offending senders, I always see a 3000ms+ ping 1-2
hops before I reach them.
Tcp treats the buffer bloat as packet loss, flooding the receiver.
On Dec 9, 2016 1:20 PM, "George Amanakis" <g_amanakis@yahoo.com> wrote:
> Dear All,
>
> regarding the issue about WAN ingress rate with many concurrent TCP
> downloads, it seems that all the excess ingress rate on the WAN interface
> are TCP retransmission packets (Wireshark). After the latest commit 78ff814
> in cobalt, ping times while using TCP BitTorrent improved from ~1000ms to
> ~300ms (concurrent connections 55). If I reduce the concurrent connections
> to 30 I get ping times lower than 70ms.
>
> Best regards,
> George
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
[-- Attachment #2: Type: text/html, Size: 1653 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
[not found] <1462124589.1190968.1481310707746.ref@mail.yahoo.com>
@ 2016-12-09 19:11 ` George Amanakis
2016-12-10 19:33 ` Benjamin Cronce
0 siblings, 1 reply; 10+ messages in thread
From: George Amanakis @ 2016-12-09 19:11 UTC (permalink / raw)
To: cake
Dear All,
regarding the issue about WAN ingress rate with many concurrent TCP downloads, it seems that all the excess ingress rate on the WAN interface are TCP retransmission packets (Wireshark). After the latest commit 78ff814 in cobalt, ping times while using TCP BitTorrent improved from ~1000ms to ~300ms (concurrent connections 55). If I reduce the concurrent connections to 30 I get ping times lower than 70ms.
Best regards,
George
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
2016-10-30 16:43 ` Georgios Amanakis
@ 2016-10-30 19:27 ` Sebastian Moeller
0 siblings, 0 replies; 10+ messages in thread
From: Sebastian Moeller @ 2016-10-30 19:27 UTC (permalink / raw)
To: Georgios Amanakis; +Cc: cake
Hi Georgios,
> On Oct 30, 2016, at 17:43, Georgios Amanakis <g_amanakis@yahoo.com> wrote:
>
> Dear All,
>
> I think Sebastian's theory has a weak point.
Oh, I do not claim to be an expert on these matters, so would cherish input from others, but I do think my hypothesis is not to be dismissed completely (see below).
>
>> Again I believe you just show bit-torrent misbehaving ...
>
> I can easily reproduce this behaviour if one LAN-host downloads
> multiple files using TCP (e.g. 2 or more kernels simultaneously from ht
> tp://www.kernel.org).
>
>> For me this looks like bwmon accounts the incoming packets before
>> cake sees and drops them ...
>
> If only one download takes place then the bandwidth bmon reports on
> WAN-ingress is the same as the limit set in cake. I don't think that
> bmon accounts the incoming packets before cake sees them.
That could be true, but also should be testable. According to http://bwmon.sourceforge.net bwmon reads /proc/net/dev to get its estimates, so “cat /proc/net/dev” should show you what is in there:
Directly after reboot:
root@turris:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
wlan0: 526875 2287 0 0 0 0 0 0 693742 2001 0 0 0 0 0 0
sit0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
gretap0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
lo: 2175 26 0 0 0 0 0 0 2175 26 0 0 0 0 0 0
ifb4eth1: 740189 2097 0 0 0 0 0 0 740189 2097 0 0 0 0 0 0
eth0: 0 0 0 0 0 0 0 0 17543 84 0 0 0 0 0 0
eth1: 752467 2167 0 0 0 0 0 0 541001 2390 0 0 0 0 0 0
eth2: 0 0 0 0 0 0 0 0 17497 83 0 0 0 0 0 0
ip6tnl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
wlan1: 0 0 0 0 0 0 0 0 17875 76 0 0 0 0 0 0
br-lan: 494863 2288 0 0 0 0 0 0 627972 1881 0 0 0 0 0 0
ifb0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
teql0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ifb1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
After a dslreports speedtest with 16/16 streams:
root@turris:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
wlan0: 20160809 37095 0 0 0 0 0 0 48570975 44819 0 0 0 0 0 0
sit0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
gretap0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
lo: 2453 28 0 0 0 0 0 0 2453 28 0 0 0 0 0 0
ifb4eth1: 47764269 44632 0 0 0 0 0 0 47764269 44632 0 0 0 0 0 0
eth0: 0 0 0 0 0 0 0 0 20435 100 0 0 0 0 0 0
eth1: 48135827 45333 0 0 0 0 0 0 19357920 36538 0 0 0 0 0 0
eth2: 0 0 0 0 0 0 0 0 20389 99 0 0 0 0 0 0
ip6tnl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
wlan1: 0 0 0 0 0 0 0 0 21047 92 0 0 0 0 0 0
br-lan: 19641491 37097 0 0 0 0 0 0 47617521 44254 0 0 0 0 0 0
ifb0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
teql0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ifb1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
root@turris:~#
Please notice how eth1 reports initially 2167-2097 = 70 packets more than ifb4eth1 (the shapers ingress qdisc is attached to the IFB as linux does not allow shapers on ingress without the ifb trick, policers however can directly act in ingress). After the test we see 45333-44632 = 701 Packets more on eth1 than ifb4eth1. I take this as supporting evidence for my hypothesis...
> Furthermore,
> Wireshark reports that all bittorrent traffic in my case are TCP
> packets, and reports the same bandwidth usage as bmon on WAN-ingress.
Well, if both look at the raw enp0s13 interface I would expect both of them to report the traffic before packets can be dropped.
>
> The only way I have found that WAN-ingress limit is obeyed, is using
> act_police with the in-kernel bandwidth estimator (i.e. tc filter add
> dev enp0s13 parent ffff: protocol all estimator 10msec 80msec u32 match
> u32 0 0 police avrate 3300kbit drop flowid :1).
As stated above, I believe I recall that policers can directly act on ingress and hence affect the number of packets reported for that interface...
> But then there is an
> discrepancy between WAN-ingress and LAN-egress (i.e. WAN-ingress is at
> ~400kbytes/s and LAN-egress on the host running bittorrent is
> ~220kbytes/s). Unfortunately I cannot see the bandwidth my cable-modem
> syncs at (I searched the web-interface but did not find it; it is a
> Comcast-provided Arris TG1682G).
With DOCSIS systems there is no clear and easy way to get hod on the relevant numbers (which would be the numbers your ISP plugged into the CMTS shaper and information about potentially allowed bursts).
>
> Noah, could you try and see what happens if instead of bittorrent a
> LAN-host downloads multiple files using TCP?
I would also be interested in the outcome of that test, please keep posting to the list.
Best Regards
Sebastian
>
> Thank you all for your feedback,
> George
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Cake] WAN ingress rate with concurrent downloads
[not found] <mailman.1.1477670401.20617.cake@lists.bufferbloat.net>
@ 2016-10-30 16:43 ` Georgios Amanakis
2016-10-30 19:27 ` Sebastian Moeller
0 siblings, 1 reply; 10+ messages in thread
From: Georgios Amanakis @ 2016-10-30 16:43 UTC (permalink / raw)
To: cake
Dear All,
I think Sebastian's theory has a weak point.
> Again I believe you just show bit-torrent misbehaving ...
I can easily reproduce this behaviour if one LAN-host downloads
multiple files using TCP (e.g. 2 or more kernels simultaneously from ht
tp://www.kernel.org).
> For me this looks like bwmon accounts the incoming packets before
> cake sees and drops them ...
If only one download takes place then the bandwidth bmon reports on
WAN-ingress is the same as the limit set in cake. I don't think that
bmon accounts the incoming packets before cake sees them. Furthermore,
Wireshark reports that all bittorrent traffic in my case are TCP
packets, and reports the same bandwidth usage as bmon on WAN-ingress.
The only way I have found that WAN-ingress limit is obeyed, is using
act_police with the in-kernel bandwidth estimator (i.e. tc filter add
dev enp0s13 parent ffff: protocol all estimator 10msec 80msec u32 match
u32 0 0 police avrate 3300kbit drop flowid :1). But then there is an
discrepancy between WAN-ingress and LAN-egress (i.e. WAN-ingress is at
~400kbytes/s and LAN-egress on the host running bittorrent is
~220kbytes/s). Unfortunately I cannot see the bandwidth my cable-modem
syncs at (I searched the web-interface but did not find it; it is a
Comcast-provided Arris TG1682G).
Noah, could you try and see what happens if instead of bittorrent a
LAN-host downloads multiple files using TCP?
Thank you all for your feedback,
George
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-12-10 19:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.5.1477497601.28053.cake@lists.bufferbloat.net>
2016-10-27 0:10 ` [Cake] WAN ingress rate with concurrent downloads G. Amanakis
2016-10-27 0:16 ` G. Amanakis
2016-10-27 6:41 ` Sebastian Moeller
2016-10-27 16:42 ` Noah Causin
2016-10-28 1:34 ` Georgios Amanakis
2016-10-28 7:45 ` Sebastian Moeller
[not found] <mailman.1.1477670401.20617.cake@lists.bufferbloat.net>
2016-10-30 16:43 ` Georgios Amanakis
2016-10-30 19:27 ` Sebastian Moeller
[not found] <1462124589.1190968.1481310707746.ref@mail.yahoo.com>
2016-12-09 19:11 ` George Amanakis
2016-12-10 19:33 ` Benjamin Cronce
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox