[pfSense-discussion] Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
- Forwarded message from Dennis - From: Dennis Date: Wed, 29 Jun 2011 17:49:50 -0700 To: Eugen Leitl Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) On Wed, Jun 29, 2011 at 7:58 AM, Eugen Leitl wrote: > - Forwarded message from William Salt - > > From: William Salt > Date: Wed, 29 Jun 2011 13:16:32 +0100 > To: supp...@pfsense.com > Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Reply-To: supp...@pfsense.com > > Hi all, thanks for the input. > We have now swapped the cards to em card at both ends, instead of igb at one > end, and em at the other. We are now seeing near gig speeds in both > directions. Before, we saw very different speeds in each direction. > > We have now managed to reach around 860-900mbps each way with the following > values in our sysctl.conf: > > kern.ipc.maxsockbuf=20971520 > net.inet.tcp.recvbuf_max=20971520 > net.inet.tcp.sendbuf_max=20971520 > net.inet.tcp.recvbuf_inc=524288 > net.inet.tcp.sendbuf_inc=524288 I am looking at this and wondering if these buffer sizes are maxing out your RAM, or there are other things going on that's making the box crash. These seem really high. Also, could it be because the provider is rate-limiting this along the path? Dennis O. - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com For additional commands, e-mail: discussion-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense-discussion] Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
- Forwarded message from Cameron Byrne - From: Cameron Byrne Date: Tue, 28 Jun 2011 09:16:13 -0700 To: Leigh Porter Cc: Andreas Ott , Eugen Leitl , "williamejs...@googlemail.com" , NANOG list Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) On Tue, Jun 28, 2011 at 9:11 AM, Leigh Porter wrote: > > >> -Original Message- >> From: Cameron Byrne [mailto:cb.li...@gmail.com] >> Sent: 28 June 2011 16:53 >> To: Leigh Porter >> Cc: Andreas Ott; Eugen Leitl; williamejs...@googlemail.com; NANOG list >> Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 >> (+3) >> In the 3G world, i have had good results overcoming longish RTT by >> using the Hybla TCP algorithm http://hybla.deis.unibo.it/ >> >> I am hoping it gets more default traction, especially in wireless >> where the radio link is a pretty big latency source >> >> Cameron > > How do you implement this for lots of clients and servers that have out of > the box implementations? The FastSoft box is a TCP man-in-the-middle box that > essentially implements the FAST TCP algorithm without either end having to > worry about it. > You don't, the full benefits only come with a Linux kernel patch. The good news is that it only has to be implemented on the client end. > I have also used home-fudged TCP proxies with some success. > > Some 3G/wireless/VSAT vendors implement their own TCP modification stacks but > they usually only fiddle with window sizes and such. > That's why i said i hope it catches on as default :) If Android implemented Hybla, i think it would be a great improvement for user experience. Nobody likes the middleboxes that proxy TCP they cost money, don't scale well, and are generally fragile. Hybla is not a solution for the OPs issue, just a solution for high RTT links where the client can do Hybla. It an evolutionary step that i think would make a great fit in smartphones like Android. Cameron > -- > Leigh > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ > - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com For additional commands, e-mail: discussion-h...@pfsense.com Commercial support available - https://portal.pfsense.org
[pfSense-discussion] Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3)
- Forwarded message from Andreas Ott - From: Andreas Ott Date: Tue, 28 Jun 2011 08:23:46 -0700 To: Eugen Leitl , williamejs...@googlemail.com Cc: NANOG list Subject: Re: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) User-Agent: Mutt/1.2.5.1i Hi, On Tue, Jun 28, 2011 at 10:52:55AM +0200, Eugen Leitl wrote: > - Forwarded message from William Salt - > From: William Salt > Date: Tue, 28 Jun 2011 08:03:25 +0100 > To: supp...@pfsense.com > Subject: [pfSense Support] Strange TCP connection behavior 2.0 RC2 (+3) > Reply-To: supp...@pfsense.com > Each TCP connection starts very slowly, and will max out at around 190mbps, > taking nearly 2 minutes to climb to this speed before *plateauing*. > > We have to initiate many (5+) connections to saturate the link with tcp > connections with iperf. > - End forwarded message - You pretty much solved your own puzzle right there: the throughput on a single TCP connection will max out at the value determined by the bandwidth delay product (excluding other strange conditions, such as deep buffers). Here is a calculator online: http://www.switch.ch/network/tools/tcp_throughput/ -andreas [who has to explain this about once a week to customers who think that they bought a GigE connection but then can't "ftp" a file from coast to coast at 1Gbps throughput. Use multiple TCP streams!] - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE - To unsubscribe, e-mail: discussion-unsubscr...@pfsense.com For additional commands, e-mail: discussion-h...@pfsense.com Commercial support available - https://portal.pfsense.org
