Okay that is interesting, Could I convince you to try to enable SACK
on the server and test whether you still see the catastrophic results?
And/or try another tcp variant instead of westwood+, like the default
cubic.
Would love to, but can not. I have read only access to settings on that
Hi Jerry,
On Aug 29, 2014, at 13:33 , Jerry Jongerius jer...@duckware.com wrote:
Okay that is interesting, Could I convince you to try to enable SACK
on the server and test whether you still see the catastrophic results?
And/or try another tcp variant instead of westwood+, like the default
On 08/29/2014 09:16 AM, Scheffenegger, Richard wrote:
Hi Gorry,
Given QUIC includes FEC to hide losses, I guess it is a good example to
consider whether ECN still offers sufficient benefits over and above
just removing losses.
GF: And then, isn't the implication of AQM to significantly
A ‘boost’ has never been seen. Bandwidth graphs where there is no packet loss
look like:
From: Jonathan Morton [mailto:chromati...@gmail.com]
Sent: Thursday, August 28, 2014 2:15 PM
To: Jerry Jongerius
Cc: bloat
Subject: RE: [Bloat] The Dark Problem with AQM in the Internet?
If
did you check to see if packets were re-sent even if they weren't lost? on
of
the side effects of excessive buffering is that it's possible for a packet
to
be held in the buffer long enough that the sender thinks that it's been
lost and retransmits it, so the packet is effectivly 'lost' even
A ‘boost’ has never been seen. Bandwidth graphs where there is no packet
loss look like:
That's very odd, if true. Westwood+ should still be increasing the
congestion window additively after recovering, so even if it got the
bandwidth or latency estimates wrong, it should still recover full
The additive increase is there in the raw data.
From: Jonathan Morton [mailto:chromati...@gmail.com]
Sent: Friday, August 29, 2014 12:31 PM
To: Jerry Jongerius
Cc: bloat
Subject: RE: [Bloat] The Dark Problem with AQM in the Internet?
A ‘boost’ has never been seen. Bandwidth graphs where
Comcast has upped the download rates in my area, from 50Mbps to 100Mbps.
This morning I tried to find the limit of the WNDR3800. And I found it.
50Mbps is still well within capabilities, 100Mbps isn't.
And as I've seen Dave say previously, it's right around 80Mbps total
(download + upload).
On 08/29/2014 09:57 AM, Aaron Wood wrote:
Or, we need to find a way to implement the system such that it doesn't
max out a 680MHz mips core just to push 100Mbps of data. That's roughly
10K cpu cycles per packet, which seems like an awful lot. Unless the
other problem is that the memory bus
On Fri, Aug 29, 2014 at 09:57:26AM -0700, Aaron Wood wrote:
It looks like it's definitely time for a new router platform (for me).
Everyone's needs are different, of course, but I've found that having a dual
HTPC+router (in the form of a simple little Atom box) works well for me.
As a bonus,
On 29 Aug, 2014, at 7:57 pm, Aaron Wood wrote:
Comcast has upped the download rates in my area, from 50Mbps to 100Mbps.
FWIW, it looks like the unshaped latency has about halved with the doubling of
capacity. That's consistent with the buffer size and (lack of) management
remaining the
Hi Aaron,
On Aug 29, 2014, at 18:57 , Aaron Wood wood...@gmail.com wrote:
Comcast has upped the download rates in my area, from 50Mbps to 100Mbps.
This morning I tried to find the limit of the WNDR3800. And I found it.
50Mbps is still well within capabilities, 100Mbps isn't.
And as
On Fri, Aug 29, 2014 at 9:57 AM, Aaron Wood wood...@gmail.com wrote:
Comcast has upped the download rates in my area, from 50Mbps to 100Mbps.
This morning I tried to find the limit of the WNDR3800. And I found it.
50Mbps is still well within capabilities, 100Mbps isn't.
And as I've seen Dave
13 matches
Mail list logo
