lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 4 Apr 2007 10:39:44 -0700 From: Stephen Hemminger <shemminger@...ux-foundation.org> To: Baruch Even <baruch@...en.org> Cc: davef1624@....com, netdev@...r.kernel.org Subject: Re: TCP congestion control for fast, short-distance networks ? On Wed, 4 Apr 2007 19:11:21 +0300 Baruch Even <baruch@...en.org> wrote: > * davef1624@....com <davef1624@....com> [070404 19:03]: > > Thanks - so you are suggesting we enable 802.3 flow-control / pause-frames? > > (it's currently disabled) > > I do, but do test it before you bet on it. I've never tested such a > scenario but from my experience the lower the rtt the lesser are the > problems that the high speed algorithms are trying to solve. > > Baruch > > > > > -----Original Message----- > > From: baruch@...en.org > > To: davef1624@....com > > Cc: shemminger@...ux-foundation.org; netdev@...r.kernel.org > > Sent: Wed, 4 Apr 2007 8:39 AM > > Subject: Re: TCP congestion control for fast, short-distance networks ? > > > > * davef1624@....com <davef1624@....com> [070404 18:29]: > > >Hello, > > > > > >We are currently using both 1 Gb & 10 Gb links, that interconnect > > several > > servers that are very *local* to > > >each other. > > >Typical RTT times range from 0.2 ms - 0.3 ms. > > > > > >We are currently using TCP reno - is there a more suitable congestion > > control > > algorithm for our > > >application, > > >especially using the 10 Gb links ? > > >(Most of the High-Speed TCP algorithms seem suitable for large RTT, > > long-distance networks). > > > > I'm not aware of any tests for high speed links with very low RTTs, but > > I suspect that the new algorithms will not change much, if the > > connections you have are indeed local than the Ethernet pause mechanism > > is more effective for the flow control you need. > > > > Baruch Pause helps (if the hardware works). But on very high speed links with low RTT, your main source of throttling is lack of bus bandwidth on receiver. -- Stephen Hemminger <shemminger@...ux-foundation.org> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists