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;
The following reply was made to PR kern/127050; it has been noted by GNATS.
From: Paul Herman
To: bug-follo...@freebsd.org
Cc: Wouter de Jong , Jacek Zapala
Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces
[regression]
Date: Fri, 19 Aug 2011 10:13:46 +0200
This is a
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
segment
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 statemen
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 ye
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.
> > &
Hi,
I'd like to pick some brains before I file a PR.
I've got 4.4-RELEASE running on FreeBSD-alpha with more than one
alias on my network interface. I decided to try out routed, and
started noticing gobs and gobs of messages:
Nov 15 11:38:10 tick /kernel: arp_rtrequest: bad gateway value
N
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 t
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
On Thu, 25 Jan 2001, Garrett Wollman wrote:
> <
>said:
>
> The important part was the
> if (callout_pending(tp->tt_delack)) {
> ...
> tp->t_flags |= TF_ACKNOW;
> }
>
> bit. This causes us to ack immediately where previously we would just
> delay an alread
On Thu, 25 Jan 2001, Garrett Wollman wrote:
> < said:
>
> > could you test this patch and compare the results.
> > By generating an ACK for every segment with the TH_PSH flag set
> > I found a significant increase in throughput.
>
> I don't think this is right.
I don't think it is either -- tryi
Hi Jonathan,
On Wed, 24 Jan 2001, Jonathan Lemon wrote:
> >10:49:54.279497 16.1035 > 10.40438: . ack 19433 win 17520 (DF)
> >10:49:54.371025 16.1035 > 10.40438: . ack 21481 win 17520 (DF)
>
> Are you sure the trace has delayed ack turned off?
Sorry, wasn't clear there. Yes, this trace is w
A question for the TCP stack gurus...
We were testing a FreeBSD 4.1 client with a Solaris 7 Oracle server.
The FreeBSD client would take 10 times longer (60 sec) than a Linux
client (~6 sec.) to complete an *identical* request. Configuration,
client software and hardware problems have been rule
Hello Roman,
On Mon, 22 Jan 2001, Roman Le Houelleur wrote:
> I use FreeBSD 4.2 stable + bridge + dummynet + ipfw. I would like
> to calculate the bandwidth of each authorized IP source flowing
> through the bridge from a user program.
>
> As this bandwidth calculation should be done very ofte
14 matches
Mail list logo
