irement, so it would be good if any AQM standard actually defined this
mechanism and it was part of the description.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
it's my belief that your measurements means most people don't actually
put congestion pressure on their accesses, thus the large buffers are
seldom used and you're not seeing buffering.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
__
ke to know if anyone
else is aware of work in this area?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
On Fri, 22 Mar 2013, grenville armitage wrote:
On 03/22/2013 15:27, Mikael Abrahamsson wrote:
[..]
I am not aware of any such work going on, so I'd like to know if
anyone else is aware of work in this area?
Of possible relevance, recent FreeBSDs have SIFTR -- a kernel res
.
I would really like to see statistics come out of it, so if you're in
contact with the authors, it would be really nice if they could include
code that presented how much mosh "helped", due to hiding packet loss, PDV
etc.
Of course, I would first like to get proper IPv6 suppor
ss
downloading/uploading done there.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
On Thu, 28 Mar 2013, Mikael Abrahamsson wrote:
What platform is used? ASR9000? It has ~50 ms of FIFO buffering per port if
nothing is configured if I remember correctly.
According to <http://technet.gathering.org/page/2/> it's 6500 so my guess
is that the buffering you're see
then you need
to interact with the APIs provided to do traffic prioritization the 3GPP
way. These are called "Traffic Flow Templates", but they basically just
sorts packets according to criteria into different parallell queues
(bearers) with different priority in the radio network. So you
I could imagine that most USB sticks use a similar approach.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
lanation is likely though.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
from being designed in the late
90:ties, but I know people who still have them in production because if
you don't have too many flows (they have a per-destination based
forwarding cache), they still work fairly well.
--
Mikael Abrahamssonemail: swm...@swm.
tgear-WNDR3800-N600-Premium-Edition-Wireless-Router-Dual-Band-Gigabit-Genie-/400459361354?pt=COMP_EN_Routers&hash=item5d3d3cec4a
for instance.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.
o equipment such as ASR9k, 12000, CRS etc, all support
WRED, and here it makes sense since they all have ~50ms worth of buffering
or more. They also come with FIFO as default setting.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
ce and how much difference it makes.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
with spacing between packets instead of in line-rate
bursts. If everybody started doing that then I would imagine there would
be less tail-drop in large RTT environments with large TCP windows?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat ma
On Fri, 27 Sep 2013, Eggert, Lars wrote:
On Sep 27, 2013, at 4:59, Mikael Abrahamsson wrote:
Do you know of simulations or similar that investigates this? I would like to
understand why having RED on a 3ms buffer depth device makes a difference and
how much difference it makes.
Because
ds. I believe some implementations
already do this.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
record for a mobile network is 180 seconds RTT. They *really*
*really* want to deliver the packets, and if the radio environment go bad
they'll still buffer 400 packets (or so).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
ff and you want to put it *before* it
goes out the radio network (because that's the expensive resource), so
that's why my guess it's doing the image-rewriting not in the end user
box, but in a centrally placed device in their network.
--
Mikael Abrahamssonem
then
serve it to the requesting client), but since the data is now hopefully
smaller, it shouldn't cause additional buffering.
Guess it comes down to how you define "bloat".
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloa
speed. Now with a lot of users this is of course
less, but sometimes if you're alone in the cell you can still get this.
I'm actually surprised that they only get 8 up, usually much more up speed
should be possible.
(I used to work for one of the swedish mobile operators)
--
Mik
L (at least in the places where the DSL
providers aren't congesting their uplinks at peak hour).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
e WNDR3800 not being able to push this is of course
relevant, so I guess we need a better platform if we want to do testing
for these higher speeds.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
ms interleaving, and also their safety margin to 6, 9 or 12 dB. Fast
or 4ms interleaving worked well with 12 dB SNR margin (which means lower
latency but also lower access speeds), whereas 6dB margin often required
16ms interleaving to work well.
em less.
In our DSLAM we could see the frequency band profile via a show command,
have you done this?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
ut it, it was never implemented (at least not when I was
there). We however made the different profiles available to customer
service, so customers could call in and have their profiles set to
whatever suited them best.
--
Mikael Abrahamssonemail: swm...@swm.
be ADSL2+ at around
25ms and 3G at around 50-100ms.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
. So while I agree that understanding the
effect of latency is important, it's no longer a meaningful way of selling
fiber access. If your last-mile is fiber instead of ADSL2+ won't improve
your long distance latency.
--
Mikael Abrahamsson
used in Sweden is usually cheap
ethernet switches which don't have buffering and might also use policing
instead of shaping which makes bufferbloat problem basically go away, but
on the other hand creates other problems.
--
Mikael Abrahamssonemail: swm...
o to avoid lost packets due to impulse noise, most set this to 16+4, and
plus the regular encoding delay for ADSL2+, you often end up with around
25ms RTT to the DSLAM.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing
ons aren't all intuitive,
and +1 on the experience of running these kinds of networks being
important.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
ell when we try to create
TCP to handle everything from 1500ms to 0.1ms of RTT, and everything from
19200bps to 100GE in speed.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
at once? Or it can
hint that hey, it seems most times I get pretty large TCP window sizes, so
it's ok to start with IW10?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
pete fairly with $normaltraffic)
Errr, google and IW10? So, already done!?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
On Thu, 25 Sep 2014, David Lang wrote:
What is the problem with making this assumption? Why should we try to
change every device on the Internet to provide this information instead
of just using this as the default?
Read the email that started this thread.
--
Mikael Abrahamssonemail
very slow ADSL lines etc.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
I'm sure there are ways to solve this, but my take from the "TCP people"
was that there was not seen to be any need to do anything else than what
is done today, ie all TCP connections are self contained and learns
nothing from each other.
--
Mikael Abrahamsson
slope at certain buffer depths, and
that's it. It doesn't react or change depending on conditions. You have to
guess at configure-time.
What we need are mechanisms that work better in real life and that are
adaptive.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
where this would be the case. Could
you please elaborate?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
not going to see high speed FQ on higher end ISP aggregation routers. So
if we want FQ, we're going to have to do it in the CPEs.
I am using terminology that is explained in this article:
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-polic
actually done this in a lab and found out
how well it works in RRUL tests etc.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
be 10-20% should be enough, but I don't know.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
iciencies will be crystal clear and business consequences will be
substantially different.
Please elaborate. I'd say FIFO is less harmful at these speeds because of
TCP inefficiencies meaning most end systems won't come up in high enough
transfer rates to saturate that part of th
ed to work with their special hardware.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
-virtualization
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
what should be done.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
ted a certain queuing behaviour and this ended up defined
by the API description, more vendors might implement the same thing.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/lis
promising:
http://www.marvell.com/embedded-processors/armada-38x/
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
requirement document that makes sense to the people
programming these ASICs for vendors? When I try to explain what needs to
be done I usually run into very frustrating discussions.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat
ments, outlining exactly what
they need to do.
Do we have this currently? In that case, whereto should I point them?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
aps a solution would be to
assure 5% of the link bandwidth for ICMP?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
t of information in our TCP stacks that either are
locked in there and not used properly to help users figure out what's
going on, and there is basically zero information flow between the
applications using TCP and the TCP stack itself. Each just tries to do its
best on its own la
r_User_Guide_revA/aw1001299.html
says the same.
However, I find devices that do differently by default as you have already
discovered.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://list
On Tue, 3 Mar 2015, valdis.kletni...@vt.edu wrote:
On Mon, 02 Mar 2015 11:17:33 +0100, Mikael Abrahamsson said:
We have a huge amount of information in our TCP stacks that either are
locked in there and not used properly to help users figure out what's
going on, and there is basically
On Wed, 4 Mar 2015, dpr...@reed.com wrote:
DSCP should not be changed en route, so the receiver of the echo reply
should be able to know what DSCP was used on the reply packet.
Changing the DSCP bits by the ISP is definitely not unheard of, so don't
count on it.
--
Mikael Abraha
s. If they do fix
it, then whatever new standard they come up with will drive sales because
now Wifi will work better and there would be a driver to upgrade for the
userbase, for instance that they can watch multicast TV on their wifi
(which plain doesn't work today).
--
Mikael Abrahamsso
On Mon, 9 Mar 2015, David Lang wrote:
On Mon, 9 Mar 2015, Mikael Abrahamsson wrote:
They need to make sure multicast works much better than it does today. IPv6
relies on it.
why does IPv6 rely on multicast?
Because that's how it was designed back in the 90ties, as an evolution to
erything is working
perfectly. If there are other problems, the drain rate might be slower
than half a megabit/s and this might induce further latency.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
On Sat, 11 Apr 2015, sahil grover wrote:
Actually i want to explore fq_codel also but the thing is NS2(tool which
i am using for my work) supports codel and sfqcodel only.
http://www.researchgate.net/post/What_are_the_differences_between_NS2_NS3
--
Mikael Abrahamssonemail: swm
ss in this area...
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
more valid.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
newer modem, mine is a few
years old.
It's actually remarkably un-bloated...
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
On Thu, 23 Apr 2015, Mikael Abrahamsson wrote:
It's actually remarkably un-bloated...
I re-did the test again at 6 in the morning,
http://www.dslreports.com/speedtest/353094 , and it's still not bloated.
I'm actually very happy for my connection from a bloat point of view, I
delay-details.html
but RTT of over 500ms is not fun. You basically can't have a heated
argument/discussion when the RTT is higher than this :P
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
M-VoIP and potentially even more conversions due
to VoIP/PSTN/Mobile interaction.
So this is one reason I am interested in the bufferbloat movement, because
with less bufferbloat then one can get away with smaller PDV buffers,
which means less end-to-end delay for realtime applications.
--
Mikael A
duced delays in each direction.
Depending on the length of the test, it might make sense to aim for 95th
or 99th percentile, ie throw away the one or few worst values as these
might be outliers. But generally I agree with your proposed terminology.
--
Mikael Abrahamssonema
er traffic, and
then you present max, 99th percentile, 95th percentile and average pdv, I
think all of those values are valuable. To a novice user, I would probably
choose the 99th and/or 95th percentile PDV value from baseline.
--
Mikael Abrahamsso
em with
static 40ms PDV buffers, which behave exactly as you describe.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
have adaptive
jitter buffers, which I didn't encounter back then but I really hope is a
lot more common today.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
something), and then display PDV from that "floor" value, ie
PDV can't ever be negative, it can only be positive.
Apart from that, the above multi-place RTT test is really really nice,
thanks for doing this!
--
Mikael Abrahamssonemail: s
"status window" where these values could be
seen in a graph or something similar to "task manager" in windows.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
oked it up,
and it's still not bloated. I haven't seen more than 20ms PDV on my 250/50
connection. It's easier to get these low PDV values at these speeds I
guess though, compared to 25/5 or even lower speeds.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
x IF that box were producing significant traffic of
its own, in addition to all the LAN side boxes?
Correct. If it for instance was running a http proxy server (and thus
terminating TCP sessions), turning on ECN on the box itself would make
sense.
--
Mikael Abrahamssonemail: swm...@swm.p
PMTUD blackholing, but no ECN related problems. I had
ECN related problems back in 2001 (or whenever it was) when Linux first
introduced it due to a lot of firewalls being very paranoid about it, but
then I turned it back on again 5-7 years ago and by then all problems were
gone.
--
Mikael Abraha
eports.com/speedtest/545457
I get occasional delay spikes but at least 95% of the time this is kept
very well under control.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
-policing/19645-policevsshape.html
With this kind of rate limiting, there is never any buffering or increase
in latency, you're only seeing packet drops, no other congestion signal.
Anyone have any insight?
--
Mikael Abrahamssonemail: swm...@swm.
usually a
good megaphone to bring attention to these kinds of issues...
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
o what is being
done here.
At least DNSSEC still works between the Internet and the ISP DNS64
resolver, but the end host won't be able to verify the response using
DNSSEC.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloa
e seems desirable.
forwarding with permission.
-- Forwarded message --
From: Dave Taht
Date: Sun, Jun 14, 2015 at 8:41 AM
Subject: Re: performance testing on the WRT1200AC
To: Mikael Abrahamsson , Aaron Wood
Dear Mikael:
netperf-wrapper has been renamed to flent. :) Quite a b
FYI in case some aren't on the cerowrt-devel ml.
-- Forwarded message --
Date: Tue, 23 Jun 2015 14:55:30 +0200 (CEST)
From: Mikael Abrahamsson
To: cerowrt-devel
Subject: [Cerowrt-devel] performance numbers from WRT1200AC (Re: Latest build
test - new sqm-scripts se
in a car, it's
not that hard, but if you don't know how to do it, you need to study first
and find correct tools in order to do it. Also, if you get it wrong you
might damage things.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
On Tue, 7 Jul 2015, Joe Touch wrote:
Some questions:
On 7/6/2015 11:16 PM, Mikael Abrahamsson wrote:
...
You can flash back the factory firmware without serial, you just use
sysupgrade with the Linksys factory image.
How does that differ from mtd, e.g., as indicated here (which doesn&#
ings started working properly.
"sysupgrade -n " does this as well, but I am not sure the
Linksys configuration data is stored in the same place so that might or
might not help.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
__
with
for instance max-ttl 5), but I don't know how much of this is available to
your web application?
If you sent 5 packets with TTL 1-5 and measured the time to get back the
ttl-expired-in-transit ICMP, you could get an indication where the latency
increase was happening.
--
M
n the upload speed? I would imagine that if it's
5-10 megabit/s, then using Codel or similar technique that doesn't allow
the buffer to grow to hundreds of milliseconds, would improve things a
lot?
For a 500 kilobit/s link, I'm not sure even that would work...?
--
Mikael Abrah
make wifi worse?
And 802.11 isn't really open either, and the unlicensed spectrum still
requires that devices are approved to be operated there, right, so if FCC
and the likes do their job properly then these technologies should
work together at least on the RF level?
--
Mikael Abr
On Tue, 8 Sep 2015, Dave Taht wrote:
On Tue, Sep 8, 2015 at 1:22 AM, Mikael Abrahamsson wrote:
On Tue, 8 Sep 2015, Dave Taht wrote:
wifi, and the carriers... which bugs me. 5.x ghz is the people's
spectrum, that we should be free to use any way we want... and to make
Please note tha
eems only to be of a concern on
the DFS channels around a limited number of airports.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
egabytes of memory.
Then you have the real "service edge" routers with 128.000 queues that's
used to aggregate tens of thousands of customers, where a linecard can
have many gigabytes of packet buffer memory.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
_
reate midrange enterprise routers with 1GE/10GE ports using this
technology, then it would of course make a lot of sense to have proper
AQM. I have no idea what kind of performance one can expect out of a low
power Intel CPU that might fit into one of these...
--
Mikael
C64/Amiga that I was involved
in in the 80ties. Lots of small optimisations needed to yield these
results.
So yes, cache is extremely important for VPP.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
might very well
be completely off, but I think it'd be interesting to know.
I'll take a look at your flent data, thanks for posting them!
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.b
and BBR4 just kills both CUBIC
flows. Same with PIE.
So it seems my intuition was wrong, at least for these scenarios. It
wasn't CUBIC that would kill BBR, it's the other way around. Great to have
testing tools! Thanks Flent!
--
Mikael Abrahams
hardware is programmed... but that's a different but related
struggle to make sure that these aren't as bloated as yesteryears
implementations.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
al part of the shared resource, and gives people an
incentive to try to improve radio reception if they have trouble, and
doesn't starve everybody else of airtime just because one device is having
a bad radio day.
So full support for this approac
difference.
(I have 250/50 on my DOCSIS3.0 connection, but perhaps it's common
knowledge what speeds Comcast customers typically has, that I don't know?)
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.buffe
r way
around, these devices typically have 128 kilobyte of buffer shared between
all ports which is way too little.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
r 3-4ms of bloat is excessive for the
applications we see today. Most of the time you're not going to notice
10-20ms bloat even when using quite time sensitive applications, and that
10-20ms PDV range is probably a better tradeoff between performance and
potential interactive performance downsi
what device has ~13-15 megabyte buffer so it can
induce 1200ms buffer lag at 1 gigabit/s.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
ot uncommon for people to have 250, 500 or 1000
downstream. If they then actually start using their bw then you'd have to
rebuild to either go higher speed for some CPE (complicated and
expensive), or rebuild to have smaller splitter domains.
I guess the answer depends a lot on y
1 - 100 of 223 matches
Mail list logo
