Re: [Bloat] RE : DSLReports Speed Test has latency measurement built-in

[Simon Barber <simon@superduper.net>]

[-- Attachment #1: Type: text/plain, Size: 4740 bytes --]

Yes - the classic one is TCP Vegas.

Simon

Sent with AquaMail for Android
http://www.aqua-mail.com


On April 22, 2015 5:03:26 AM jb <justin@dslr.net> wrote:

> So I find a page that explains SO_RCVBUF is allegedly the most poorly
> implemented on Linux, vs Windows or OSX, mainly because the one you start
> with is the cap, you can go lower, but not higher, and data is needed to
> shrink the window to a new setting, instead of slamming it shut by
> setsockopt
>
> Nevertheless! it is good enough that if I set it on tcp connect I can at
> least offer the option to run pretty much the same test to the same set of
> servers, but with a selectable cap on sender rate.
>
> By the way, is there a selectable congestion control algorithm available
> that is sensitive to an RTT that increases dramatically? in other words,
> one that does the best at avoiding buffer size issues on the remote side of
> the slowest link? I know heuristics always sound better in theory than
> practice but surely if an algorithm picks up the idle RTT of a link, it can
> then pump up the window until an RTT increase indicates it should back off,
> Instead of (encouraged by no loss) thinking the end-user must be
> accelerating towards the moon..
>
> thanks.
>
> On Wed, Apr 22, 2015 at 6:51 PM, <luca.muscariello@orange.com> wrote:
>
> >  cons: large BDP in general would be negatively affected.
> > A Gbps access vs a DSL access to the same server would require very
> > different tuning.
> >
> >  sch_fq would probably make the whole thing less of a problem.
> > But running it in a VM does not sound a good idea and would not reflect
> > usual servers setting BTW
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------- Message d'origine --------
> > De : Eric Dumazet
> > Date :2015/04/22 12:29 (GMT+08:00)
> > À : "Steinar H. Gunderson"
> > Cc : bloat
> > Objet : Re: [Bloat] DSLReports Speed Test has latency measurement built-in
> >
> >   On Wed, 2015-04-22 at 06:04 +0200, Steinar H. Gunderson wrote:
> > > On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
> > > > As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket
> > buffers
> > > > for the application layer, they do not change the TCP window size
> > either
> > > > send or receive.
> > >
> > > I haven't gone into the code and checked, but from practical experience I
> > > think you're wrong. I've certainly seen positive effects (and verified
> > with
> > > tcpdump) from reducing SO_SNDBUF on a server that should have no
> > problems at
> > > all sending data really fast to the kernel.
> >
> > Well, using SO_SNDBUF disables TCP autotuning.
> >
> > Doing so :
> >
> > Pros:
> >
> > autotuning is known to enable TCP cubic to grow cwnd to bloat levels.
> > With small enough SO_SNDBUF, you limit this cwnd increase.
> >
> > Cons:
> >
> > Long rtt sessions might not have enough packets to utilize bandwidth.
> >
> >
> > >
> > > Then again, this kind of manual tuning trickery got obsolete for me the
> > > moment sch_fq became available.
> >
> > Note that I suppose the SO_MAX_PACING rate is really helping you.
> >
> > Without it, TCP cubic is still allowed to 'fill the pipes' until packet
> > losses.
> >
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> >
> > 
> _________________________________________________________________________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme 
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> > Thank you.
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> >
> >
>
>
>
> ----------
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 6353 bytes --]