At 8:56 AM -0600 2/25/01, Jonathan Lemon wrote:
>On Sun, Feb 25, 2001 at 11:10:54AM +0100, Paul Herman wrote:
>> 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?
>> >
>> > Th
On Sun, Feb 25, 2001 at 11:10:54AM +0100, Paul Herman wrote:
> 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
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 Sat, Feb 24, 2001 at 11:19:02AM -0800, Mark Peek wrote:
> At 11:19 PM +0100 1/25/01, Paul Herman wrote:
> >On Thu, 25 Jan 2001, Garrett Wollman wrote:
> >
> >> < >><[EMAIL PROTECTED]> said:
> >>
> >> The important part was the
> >>if (callout_pending(tp->tt_delack)) {
> >>...
At 11:19 PM +0100 1/25/01, Paul Herman wrote:
>On Thu, 25 Jan 2001, Garrett Wollman wrote:
>
>> <><[EMAIL PROTECTED]> said:
>>
>> The important part was the
>> if (callout_pending(tp->tt_delack)) {
>> ...
>> tp->t_flags |= TF_ACKNOW;
>> }
>>
>> bit. This cau
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
< said:
> Whatever happened to TF_DELACK anyway?
It was removed since it is no longer necessary. The same information
can be gleaned from callout_pending(tp->tt_delack).
> SW5kZXg6IHRjcF9pbnB1dC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp
< said:
> I'm not sure this is required. Expanding the context of the area in
> question:
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
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
In article [EMAIL PROTECTED]> you
write:
>< 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 think what we want to do is:
>
>
< 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 think what we want to do is:
if (callout_pending(tp->tt_delack)) {
Bruce,
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.
Index: tcp_input.c
===
RCS file: /home/ncvs/src/sys/netinet/tcp_i
On Wed, 24 Jan 2001, Jordan Hubbard wrote:
> > Something just doesn't sit well me. This shouldn't happen in a
> > 100Mbit LAN. This seems like a plain vanilla network transaction, and
> > FreeBSD is failing on something, where other OSes in the same
> > environment don't.
>
> You're almost cer
< said:
> Something just doesn't sit well me. This shouldn't happen in a
> 100Mbit LAN. This seems like a plain vanilla network transaction, and
> FreeBSD is failing on something, where other OSes in the same
> environment don't.
Is your Solaris server attempting to do tinygram avoidance and g
> Something just doesn't sit well me. This shouldn't happen in a
> 100Mbit LAN. This seems like a plain vanilla network transaction, and
> FreeBSD is failing on something, where other OSes in the same
> environment don't.
You're almost certainly correct that there's a misfeature lurking in
ther
it looks like the tcp code is not acking the data when the PUSH
flag is set. It would be useful to generate an immediate ACK
when the PUSH flag is set.
it would be interesting to see if the other sends two full sized
tcp segments if the freebsd stack will then immediately acknowledge
the data.
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
In article
[EMAIL PROTECTED]>
you write:
>
>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,
>cl
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
19 matches
Mail list logo
