Re: [Cake] total download rate with many flows

> On Nov 20, 2017, at 9:06 AM, Jonathan Morton wrote: > It's a kind offer, and since I'm in Finland (also EU), there shouldn't be any > problem with VAT. > > However, I just managed to find a copy of the failsafe code on one of my > other machines, and merged it to

Re: [Cake] total download rate with many flows

It's a kind offer, and since I'm in Finland (also EU), there shouldn't be any problem with VAT. However, I just managed to find a copy of the failsafe code on one of my other machines, and merged it to cobalt branch. I honestly thought it had been pushed already, and that the only reason for it

Re: [Cake] total download rate with many flows

> From: Jonathan Morton <chromati...@gmail.com> > To: Georgios Amanakis <gamana...@gmail.com>, > cake@lists.bufferbloat.net > Subject: Re: [Cake] total download rate with many flows > Message-ID: <464c2c38-8ecc-b232-19b3-bf3eb0146...@gmail.com> > Con

Re: [Cake] total download rate with many flows

On 16/11/17 19:06, Georgios Amanakis wrote: I am skimming through the code but cannot see where the failsafe shaper's rate of advance is set at one-quarter rate. Could you point this out? Oddly enough, I can't find it either. It could be that the code wasn't pushed yet - or even that it

Re: [Cake] total download rate with many flows

I'm curious as to why you think Cobalt is more aggressive than Codel. It does use more accurate approximations to the mathematical ideal than the "reference" codel does. It is however very odd that the Diffserv mode has any effect on this at all. It could be explained if a lot of the traffic is

Re: [Cake] total download rate with many flows

gt;> Cake@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cake >>> >>> >>> -- Forwarded message -- >>> From: "G. Amanakis" <g_amana...@yahoo.com> >>> To: Dave Taht <d...@taht.net>, George

Re: [Cake] total download rate with many flows

at.net/listinfo/cake -- Forwarded message -- From: "G. Amanakis" <g_amana...@yahoo.com> To: Dave Taht <d...@taht.net>, George Amanakis via Cake <cake@lists.bufferbloat.net> Cc: Bcc: Date: Tue, 14 Nov 2017 17:13:16 -0500 Subject: Re: [Cake] total

Re: [Cake] total download rate with many flows

t; To: Dave Taht <d...@taht.net>, George Amanakis via Cake > <cake@lists.bufferbloat.net> > Cc: > Bcc: > Date: Tue, 14 Nov 2017 17:13:16 -0500 > Subject: Re: [Cake] total download rate with many flows > Yes, it is. I am building from the cobalt branch. What makes you b

Re: [Cake] total download rate with many flows

George Amanakis via Cake <cake@lists.bufferbloat.net> writes: > From: George Amanakis <g_amana...@yahoo.com> > Subject: Re: [Cake] total download rate with many flows > To: David Lang <da...@lang.hm> > Cc: cake@lists.bufferbloat.net > Date: Mon, 13 Nov 2017 21:

Re: [Cake] total download rate with many flows

--- Begin Message --- Dear David, I agree. My point is that currently ingress mode seems to be dropping more packets than necessary to keep senders from bottlenecking the connection (when there is a large number of concurrent flows, >8). And right now, ingress mode is the only mode that

Re: [Cake] total download rate with many flows

Ingres and Egress are fundamentally different due to the fact that in ingress mode you are having to throw away data that has successfully traversed the bottleneck (deliberatly wasting your limited resource now to avoid having senders bottleneck the queue on the far side of the link) in

Re: [Cake] total download rate with many flows

--- Begin Message --- I meant proportionally to (1-1/sqrt(x)). On 11/13/2017 8:51 PM, George Amanakis wrote: I am exploring this idea further. If q->time_next_packet is incremented for dropped packets proportionally to (1-1/x), where x is the count of all flows in the tin that is being

Re: [Cake] total download rate with many flows

--- Begin Message --- I am exploring this idea further. If q->time_next_packet is incremented for dropped packets proportionally to (1-1/x), where x is the count of all flows in the tin that is being served, ingress mode works much more smoothly: latency is still <50ms and throughput is very

Re: [Cake] total download rate with many flows

--- Begin Message --- I totally understand what you are saying. However, I believe cake's egress and ingress modes currently behave as two extremes. One could argue that neither of them is the golden mean. With a patch in ingress mode (see below) and a single host using 32 flows to download I

Re: [Cake] total download rate with many flows

In fact, that's why I put a failsafe into ingress mode, so that it would never stall completely. It can happen, however, that throughput is significantly reduced when the drop rate is high. If throughput is more important to you than induced latency, switch to egress mode. Unfortunately it's

Re: [Cake] total download rate with many flows

--- Begin Message --- Indeed. Also interplanetary essentially omits cake_advance_shaper for dropped packets (since cobalt never drops that way), almost disabling ingress mode. Which leads to other hosts having pings to WAN > 500ms when one of them is using many flows. What I think is

Re: [Cake] total download rate with many flows

Interplanetary basically disables codel for most applications. > On 11/1/2017 6:01 PM, Dave Taht wrote: >> Awesome. thx. I will try to make time to look at these over the weekend. I still haven't had that weekend. ___ Cake mailing list

Re: [Cake] total download rate with many flows

--- Begin Message --- I did more testing regarding this issue. I found out that if I use "interplanetary", I do not observe the behaviour I mentioned before. I still need to test the responsiveness of other hosts while one of them is using too many flows with this setting. Setup is the same,

Re: [Cake] total download rate with many flows

Awesome. thx. I will try to make time to look at these over the weekend. ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] total download rate with many flows

--- Begin Message --- Dear Dave, I could get the following dumps: *lan.cake.pcap captured on router, lan iface, with cake #lan.cake.ping.pcap captured on router, lan iface, with cake, ping from host other than w10 update $lan.nocake.pcap captured on router, lan iface, without cake

Re: [Cake] total download rate with many flows

--- Begin Message --- I think I have another install not updated to "Fall Creators Update". I will try and get a capture using Wireshark. Or should I rather capture on the router? George On 10/31/2017 9:06 PM, Antoine Deschênes wrote: Fall Creators update, killed my whole internet connection

Re: [Cake] total download rate with many flows

I would *dearly* love a packet capture of a windows 10 update in this case. ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake