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 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, 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 >