From: Dave Taht <dave.taht@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] SQM Question #3: How shall we recommend people set their upload/download speeds?
Date: Sun, 29 Dec 2013 05:52:23 -0800 [thread overview]
Message-ID: <CAA93jw6S_LDak+78qih_wQa0=z3mb_aEvPCk+JFwoguDzHydZA@mail.gmail.com> (raw)
In-Reply-To: <A2A9AA5C-48BD-402D-A5E7-8D9B61770F69@gmx.de>
On Sun, Dec 29, 2013 at 3:46 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi list,
> On Dec 29, 2013, at 09:53 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> On Sat, Dec 28, 2013 at 8:33 PM, Rich Brown <richb.hanover@gmail.com> wrote:
>>> QUESTION #3: How shall we recommend people set their upload/download speeds?
>>>
>>> Although we have already spent a lot of time on the list batting around ways to think about this, it seems to me that there are only two choices for recommendations, especially given that most people looking at CeroWrt are in a “TL;DR” mind set:
>>
>> What does TL;DR mean?
>
> Too Long; Didn't Read...
Hah. I've seen this abbreviation a lot recently, but I thought it was
wayward HTML!
>>
>>> 1) If you don’t have an accurate sense of your actual link speed (e.g., you haven’t done a link speed measurement), you should take your provider’s published specs, knock them down by 15%, and enter those values in the SQM Basic Settings tab. [Or should they take an additional 15% off that already reduced value?]
>>
>> 92% on the up, 85% on the down are starting points.
>>
>>>
>>> 2) If you have done measurements of your link speed, you should enter values that are 95% of each direction’s measured speed.
>>>
>>> Is this the right recommendation?
>
> That is what I thought, but it seems 95% was too optimistic… I have found that ShaperProbe's (http://www.measurementlab.net/tools/shaperprobe) capacity estimate is pretty good at least for the low speeds I could test.
>
>
>> A short rant on the inadaquacy of speedtest and other tests would be
>> nice. Netanalyzr is the closest thing to a good test these days but it
>> requires java and is inaccurate above 20mbit.
>
> The problem is that no one really wants to supply the large amount of bandwidth required that everyone can max out their download long enough for a reasonable test; this is why an often read recommendation is to use curl or wget to concurrently down or up load large files from several beefy servers, to actually be able to assess the local link capacity. The only redeeming feature of seediest and friends is, that underestimating the available link capacity will lead to decent latency and lean buffers :).
I do think the best way to get an estimate is to load up with multiple
streams going to multiple servers. Needent be tcp.... but there I'd
long hoped to get a grip on drop patterns and extrapolate from that.
>
> best
> Sebastian
>
>>
>>>
>>> NB: In the Details… section, we can recommend ways to measure current link speeds, encourage people to make the measurement during quiet times, link to the “Quick test for Bufferbloat” page, etc. for those who want to dig further.
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
prev parent reply other threads:[~2013-12-29 13:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-29 4:33 Rich Brown
2013-12-29 8:53 ` Dave Taht
2013-12-29 11:46 ` Sebastian Moeller
2013-12-29 13:52 ` Dave Taht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw6S_LDak+78qih_wQa0=z3mb_aEvPCk+JFwoguDzHydZA@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox