On Mon, Nov 14, 2011 at 7:54 AM, Erich Weiler wei...@soe.ucsc.edu wrote:
Have you considered empty ACK prioritization? I implemented this a year
ago on a pair of production edge routers and noticed significant
improvement on throughput. I have production code examples if you
require them, but
So, I have a FreeBSD 8.1 box that I'm using as a firewall (pfSense 2.0
really, which uses 8.1 as a base), and I'm filtering packets inbound and
I'm seeing a typical sawtooth pattern where I get high bandwidth, then a
packet drops somewhere, and the TCP connections back off a *lot*, then
slowly
Erich,
Slow start is actually just the initial ramp up limited by RFC 3390 being
enabled by default (usually 3/4 packets), but this is only the case for the
first few seconds of the stream. You can effectively speed that up with
something like this though:
net.inet.tcp.rfc3390=0
Erich,
Forgot to mention net.inet.tcp.delayed_ack can be a detriment in latent
paths, might try setting it to 0 to see if it improves your throughput.
Jason Wolfe
On Sun, Nov 13, 2011 at 2:48 PM, Jason Wolfe nitrobo...@gmail.com wrote:
Erich,
Slow start is actually just the initial ramp up
On 11/14/2011 08:16, Erich Weiler wrote:
So, I have a FreeBSD 8.1 box that I'm using as a firewall (pfSense
2.0 really, which uses 8.1 as a base), and I'm filtering packets
inbound and I'm seeing a typical sawtooth pattern where I get high
bandwidth, then a packet drops somewhere, and the TCP
Thanks Jason!
Is it possible to upgrade to 8.2-STABLE? Cubic has shown some really
great improvement in my latent paths, a steady 10% overall increase in
same cases.
Alas no, my OS is a pre-baked install for pfSense, and if I tried to
upgrade it, it would likely break some of the
If your firewall
isn't the cause of the packet losses, then you don't really have much
control -- the TCP source(s) _will_ detect the packet losses, either due
to duplicate ACKs coming back from the destination or timeout waiting for
ACK from destination.
I suspect my firewall *is* the cause
I suspect my firewall *is* the cause of the packet loss, unfortunately.
We're sending multiple streams in from multiple sources and
destinations, but the aggregate bandwidth coming into the firewall is
consistent no matter how many sources and destinations we have. It maxes
at about 2Gb/s. That's
On Sun, Nov 13, 2011 at 4:53 PM, Erich Weiler wei...@soe.ucsc.edu wrote:
I suspect my firewall *is* the cause of the packet loss, unfortunately.
We're sending multiple streams in from multiple sources and
destinations, but the aggregate bandwidth coming into the firewall is
consistent no
Yeah, skimming fail, I didn't realize the machine was not the
termination point of your connections. I do have patches back ported
that would likely get the modular congestion control working on 8.1,
but neither my suggestions nor the implementation of Cubic will help
much as mentioned.
Given
Actually, another question might be: How can I prove that my firewall
really is dropping packets in transit, as it forwards them on? Is there
some sysctl oid that would show dropped packets, so some netstat counter
I can look at?
On 11/13/11 4:22 PM, Erich Weiler wrote:
Yeah, skimming
On 11/13/11 4:22 PM, Erich Weiler wrote:
Yeah, skimming fail, I didn't realize the machine was not the
termination point of your connections. I do have patches back ported
that would likely get the modular congestion control working on 8.1,
but neither my suggestions nor the implementation of
On 13.11.2011 17:45, Julian Elischer wrote:
On 11/13/11 4:22 PM, Erich Weiler wrote:
Yeah, skimming fail, I didn't realize the machine was not the
termination point of your connections. I do have patches back
ported
that would likely get the modular congestion control working on
8.1,
but
On Monday 14 November 2011 01:33:11 Erich Weiler wrote:
Actually, another question might be: How can I prove that my firewall
really is dropping packets in transit, as it forwards them on? Is there
some sysctl oid that would show dropped packets, so some netstat counter
I can look at?
Sorry this is a little more proper of a thread.
http://freebsd.1045724.n5.nabble.com/The-tale-of-a-TCP-bug-td4262914.html
On Sun, Nov 13, 2011 at 03:38:57PM -0800, Erich Weiler wrote:
Thanks Jason!
Is it possible to upgrade to 8.2-STABLE? Cubic has shown some really
great improvement in
Have you considered this thread ?
A Tale of a TCP bug...
http://lists.freebsd.org/pipermail/freebsd-net/2011-April/028448.html
This was fixed in 8-STABLE before 8.2 release but after 8.1-RELEASE.
A pcap dump of the traffic at the routing end and the recieving end might just
reveal this as
Have you considered empty ACK prioritization? I implemented this a year
ago on a pair of production edge routers and noticed significant
improvement on throughput. I have production code examples if you
require them, but this link should be more than enough to get you started:
Fascinating.
On 11/13/11 10:54 PM, Erich Weiler wrote:
Have you considered empty ACK prioritization? I implemented this a
year
ago on a pair of production edge routers and noticed significant
improvement on throughput. I have production code examples if you
require them, but this link should be more than
18 matches
Mail list logo
