netdev - Re: TCP congestion control for fast, short-distance networks ?

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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