Jaye Mathisen writes:
> Maybe it could be made a sysctl knob...
No, a socket option would be more appropriate.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Jaye Mathisen <[EMAIL PROTECTED]> writes:
> Maybe it could be made a sysctl knob...
No, a socket option would be more appropriate.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
PRUS_MORETOCOME is indeed too complex to solve the microcosmic problem
of writes between 100 and 208 bytes; however, it solves the more general
problem of the Nagle/MTU interaction even when the MTU is larger than a
cluster (e.g. loopback, ATM, FDDI, etc). Try the atomic patch (and
remove PRUS_MO
PRUS_MORETOCOME is indeed too complex to solve the microcosmic problem
of writes between 100 and 208 bytes; however, it solves the more general
problem of the Nagle/MTU interaction even when the MTU is larger than a
cluster (e.g. loopback, ATM, FDDI, etc). Try the atomic patch (and
remove PRUS_M
:I wrote it in rev 1.41 and gave it to the squid folks; it turned out
:to cause X to fail in unexplained ways so we reverted it. Then I added
:PRUS_MORETOCOME in rev 1.50, which was supposed to have fixed the problem.
:Let's please not put the hack back in; if PRUS_MORETOCOME is broken
:let's fix
:I wrote it in rev 1.41 and gave it to the squid folks; it turned out
:to cause X to fail in unexplained ways so we reverted it. Then I added
:PRUS_MORETOCOME in rev 1.50, which was supposed to have fixed the problem.
:Let's please not put the hack back in; if PRUS_MORETOCOME is broken
:let's fi
>I think committing this would be beneficial. Would someone w/ commit
>privs care to review and then commit this bit?
I wrote it in rev 1.41 and gave it to the squid folks; it turned out
to cause X to fail in unexplained ways so we reverted it. Then I added
PRUS_MORETOCOME in rev 1.50,
>I think committing this would be beneficial. Would someone w/ commit
>privs care to review and then commit this bit?
I wrote it in rev 1.41 and gave it to the squid folks; it turned out
to cause X to fail in unexplained ways so we reverted it. Then I added
PRUS_MORETOCOME in rev 1.50,
I believe this will solve the previously reported problems.
With the original patch if I set net.inet.tcp.sendspace=63 and tried
to run xterm from that machine to my local workstation, I got an X error.
If I set sendspace=31 the xterm process just locked up and did nothing
unt
I believe this will solve the previously reported problems.
With the original patch if I set net.inet.tcp.sendspace=63 and tried
to run xterm from that machine to my local workstation, I got an X error.
If I set sendspace=31 the xterm process just locked up and did nothing
un
::It's been committed before, and broke many things (X and CVSup come to
::mind). I have it compiled in locally on a few machines but it's
::definitely not suitable for general distribution until a solution is
::found that doesn't break applications.
::
::Jason Young
::accessUS Chief Network Engin
:
:It's been committed before, and broke many things (X and CVSup come to
:mind). I have it compiled in locally on a few machines but it's
:definitely not suitable for general distribution until a solution is
:found that doesn't break applications.
:
:Jason Young
:accessUS Chief Network Engineer
> Matthew Dillon
> > Sent: Thursday, July 22, 1999 3:57 PM
> > To: Papezik Milon
> > Cc: hack...@freebsd.org
> > Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c
> >
> >
> > This isn't really a bug since this is a TCP connection.
&
etwork Engineer
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org
> [mailto:owner-freebsd-hack...@freebsd.org]on Behalf Of
> Matthew Dillon
> Sent: Thursday, July 22, 1999 3:57 PM
> To: Papezik Milon
> Cc: hack...@freebsd.org
> Subject: Re: Squid - a bug in sr
::It's been committed before, and broke many things (X and CVSup come to
::mind). I have it compiled in locally on a few machines but it's
::definitely not suitable for general distribution until a solution is
::found that doesn't break applications.
::
::Jason Young
::accessUS Chief Network Engi
:
:It's been committed before, and broke many things (X and CVSup come to
:mind). I have it compiled in locally on a few machines but it's
:definitely not suitable for general distribution until a solution is
:found that doesn't break applications.
:
:Jason Young
:accessUS Chief Network Engineer
Sent: Thursday, July 22, 1999 3:57 PM
> > To: Papezik Milon
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c
> >
> >
> > This isn't really a bug since this is a TCP connection.
> > TCP makes
> > n
etwork Engineer
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Matthew Dillon
> Sent: Thursday, July 22, 1999 3:57 PM
> To: Papezik Milon
> Cc: [EMAIL PROTECTED]
> Subject: Re: Squid - a bug in src/sys/kern/uipc_socket.c
>
>
This isn't really a bug since this is a TCP connection. TCP makes
no guarentees that atomic writes will show up as atomic reads, and
the squid code shouldn't be making that assumption.
On the otherhand, the proposed fix appears to be an excellent performance
optimization. It
This isn't really a bug since this is a TCP connection. TCP makes
no guarentees that atomic writes will show up as atomic reads, and
the squid code shouldn't be making that assumption.
On the otherhand, the proposed fix appears to be an excellent performance
optimization. I
Hi,
please don't kill me if it's "well known issue":
I've found that there is a report on Squid site, which
describes a problem with FreeBSD IPC and includes suggested fix.
I verified that this suggested fix is not included in 3.2-RELEASE.
I wonder, if it is really a bug, as I cannot find it in
Hi,
please don't kill me if it's "well known issue":
I've found that there is a report on Squid site, which
describes a problem with FreeBSD IPC and includes suggested fix.
I verified that this suggested fix is not included in 3.2-RELEASE.
I wonder, if it is really a bug, as I cannot find it in
22 matches
Mail list logo
