On 8/21/2011 1:47 AM, Ask Bjørn Hansen wrote:
On Aug 19, 2011, at 1:30, Paul Herman wrote:
--010305010708060807000808
Content-Type: application/gzip;
name=carp_ip6_alias.patch.gz
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename
The following reply was made to PR kern/127050; it has been noted by GNATS.
From: Paul Herman pher...@frenchfries.net
To: bug-follo...@freebsd.org
Cc: Wouter de Jong maddo...@maddog2k.net, Jacek Zapala ja...@it.pl
Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces
[regression
Hi -net,
While pondering sending large files across a jumbo frame network
using FreeBSD, I decided to first see how well the loopback
interface does. Using ttcp on the same machine:
ttcp -s -r
ttcp -s -t 127.0.0.1
I noticed that although the MSS is 16k, I don't ever see a full 16k
On Mon, 14 Oct 2002, Steve Francis wrote:
Kirill Ponomarew wrote:
is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with
heavy network traffic ?
If you want to increase your network traffic for no particular reason,
and increase load on your server, then yes.
On Tue, 15 Oct 2002, Lars Eggert wrote:
Paul Herman wrote:
Not true. Although some bugs have been fixed in 4.3, FreeBSD's
delayed ACKs will still degrade your performance dramatically in
some cases.
I'm sorry, but such statements without a packet trace that exhibits the
problem
On Fri, 23 Nov 2001, Paul Herman wrote:
On Thu, 22 Nov 2001, Ruslan Ermilov wrote:
On Wed, Nov 21, 2001 at 05:32:27PM -0800, Paul Herman wrote:
Hi,
I'd like to pick some brains before I file a PR.
There's already a PR open on this, kern/29170.
[...]
Here's a patch
On Thu, 10 May 2001, jayanth wrote:
I would like to back out the DELAY_ACK macro changes for now. The
ttcp code behavior has changed because of the addition of the
DELAY_ACK macro.
The macro is forcing the ttcp code to send an immediate SYN, ACK
for an initial ttcp segment which has the
On Sat, 24 Feb 2001, Jonathan Lemon wrote:
On Sat, Feb 24, 2001 at 11:19:02AM -0800, Mark Peek wrote:
Was there ever a final resolution to this problem?
The patches are still sitting in my tree, as I've been unable
to come up with a test case that actually makes a difference.
The "tar cf
