|
Home > Archive > Unix Programming > November 2006 > Possible resolution (Re: Odd TCP client/server throughput problem)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Possible resolution (Re: Odd TCP client/server throughput problem)
|
|
| Richard Eich 2006-11-28, 7:25 pm |
| maxim.yegorushkin@gmail.com wrote...
>
> I would try using another network card / driver to see if the hardware
> and the driver are good.
We changed /etc/sysctl.conf to
net.ipv4.tcp_fack = 0
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
then said
# sysctl -p
and have not seen any SEND-Q buildup or loss of througput at all,
under network load that stopped us dead before.
| |
| K-mart Cashier 2006-11-28, 7:25 pm |
|
Richard Eich wrote:
> maxim.yegorushkin@gmail.com wrote...
>
>
> We changed /etc/sysctl.conf to
>
> net.ipv4.tcp_fack = 0
> net.ipv4.tcp_sack = 0
> net.ipv4.tcp_dsack = 0
>
> then said
>
> # sysctl -p
>
> and have not seen any SEND-Q buildup or loss of througput at all,
> under network load that stopped us dead before.
miss_xtc@linux:~> uname -a
Linux linux 2.6.5-7.155.29-default #1 Thu Jun 2 12:07:05 UTC 2005 i686
athlon i386 GNU/Linux
miss_xtc@linux:~> man tcp
Reformatting tcp(7), please wait...
"tcp_fack
Enable TCP Forward Acknowledgement support. It is
enabled by default. "
"tcp_dsack
Enable RFC2883 TCP Duplicate SACK support. It is enabled
by default."
" tcp_sack
Enable RFC2018 TCP Selective Acknowledgements. It is
enabled by default."
"SEE ALSO
socket(7), socket(2), ip(7), bind(2), listen(2), accept(2),
connect(2), sendmsg(2), recvmsg(2), sendfile(2), sysctl(2),
getsockopt(2).
RFC793 for the TCP specification.
RFC1122 for the TCP requirements and a description of the Nagle
algorithm.
RFC1323 for TCP timestamp and window scaling options.
RFC1644 for a description of TIME_WAIT assassination hazards.
RFC2481 for a description of Explicit Congestion Notification.
RFC2581 for TCP congestion control algorithms.
RFC2018 and RFC2883 for SACK and extensions to SACK. "
I'm getting this sneaking suspicion that this is just some kind of
funky Linuxism. Okay, with that, I'm just going to go back to just
reading the newsgroups and continue to post questions when I get
confused.
| |
| K-mart Cashier 2006-11-28, 7:25 pm |
|
K-mart Cashier wrote:
> Richard Eich wrote:
>
> miss_xtc@linux:~> uname -a
> Linux linux 2.6.5-7.155.29-default #1 Thu Jun 2 12:07:05 UTC 2005 i686
> athlon i386 GNU/Linux
> miss_xtc@linux:~> man tcp
> Reformatting tcp(7), please wait...
>
> "tcp_fack
> Enable TCP Forward Acknowledgement support. It is
> enabled by default. "
>
> "tcp_dsack
> Enable RFC2883 TCP Duplicate SACK support. It is enabled
> by default."
>
> " tcp_sack
> Enable RFC2018 TCP Selective Acknowledgements. It is
> enabled by default."
>
> "SEE ALSO
> socket(7), socket(2), ip(7), bind(2), listen(2), accept(2),
> connect(2), sendmsg(2), recvmsg(2), sendfile(2), sysctl(2),
> getsockopt(2).
>
> RFC793 for the TCP specification.
> RFC1122 for the TCP requirements and a description of the Nagle
> algorithm.
> RFC1323 for TCP timestamp and window scaling options.
> RFC1644 for a description of TIME_WAIT assassination hazards.
> RFC2481 for a description of Explicit Congestion Notification.
> RFC2581 for TCP congestion control algorithms.
> RFC2018 and RFC2883 for SACK and extensions to SACK. "
>
>
> I'm getting this sneaking suspicion that this is just some kind of
> funky Linuxism. Okay, with that, I'm just going to go back to just
> reading the newsgroups and continue to post questions when I get
> confused.
Never mind. After taking a closer look at the entire thread and reading
RFC 2018, I'm starting to see what the real problem is and how the
original posters changes are having an impact on the network.
Chad
| |
| Maxim Yegorushkin 2006-11-29, 7:28 am |
|
Richard Eich wrote:
> maxim.yegorushkin@gmail.com wrote...
>
>
> We changed /etc/sysctl.conf to
>
> net.ipv4.tcp_fack = 0
> net.ipv4.tcp_sack = 0
> net.ipv4.tcp_dsack = 0
>
> then said
>
> # sysctl -p
>
> and have not seen any SEND-Q buildup or loss of througput at all,
> under network load that stopped us dead before.
Looks like a kernel bug. It would be interesting to see if the latest
kernel needs these settings in your environment.
| |
| K-mart Cashier 2006-11-29, 1:17 pm |
|
Maxim Yegorushkin wrote:
> Richard Eich wrote:
>
>
> Looks like a kernel bug. It would be interesting to see if the latest
> kernel needs these settings in your environment.
Maxim,
Please correct me if I'm wrong. You said in an earlier post that there
was no ACK on the last two packets on the final 6 TCP segments. If I
got the basic idea of RFC 2018 correct, when there are two or more
packet losses, then the entire segment has to be re-transmitted. The
two possible solutions are to either increase the window size or use
Selective Acknowledgment (what the OP in this case).
If this is correct, then wouldn't it be a screwup in the default
configuration as opposed to a kernel bug?
Chad
| |
| Maxim Yegorushkin 2006-11-29, 1:17 pm |
|
K-mart Cashier wrote:
> Maxim Yegorushkin wrote:
>
> Maxim,
>
> Please correct me if I'm wrong. You said in an earlier post that there
> was no ACK on the last two packets on the final 6 TCP segments. If I
> got the basic idea of RFC 2018 correct, when there are two or more
> packet losses, then the entire segment has to be re-transmitted.
If SACK is off, all the segments following the last ACKed segment have
to be retransmitted. If SACK is on, only not ACKed ones.
> The two possible solutions are to either increase the window size
Increasing window size may help if you have long fat pipe (rfc 1323).
This may not help here, as the receiver here never advertises the
recieve window of size 0.
> or use Selective Acknowledgment (what the OP in this case).
SACK should only minimize the number of segments the sender has to
retransmit. In either case (SACK on and off), not ACKed segments should
time out and be retransmitted, shouldn't they?
> If this is correct, then wouldn't it be a screwup in the default
> configuration as opposed to a kernel bug?
It may be as well. I've been using Fedora Core 5 servers for a while,
which has fack, sack and dsack enabled by default and it's been working
fine. Although it does not prove anything, as OP's environment is quite
different to mine.
| |
| K-mart Cashier 2006-11-30, 1:33 am |
|
Maxim Yegorushkin wrote:
> K-mart Cashier wrote:
>
>
> If SACK is off, all the segments following the last ACKed segment have
> to be retransmitted. If SACK is on, only not ACKed ones.
>
>
> Increasing window size may help if you have long fat pipe (rfc 1323).
> This may not help here, as the receiver here never advertises the
> recieve window of size 0.
>
One day when I get enough cash, I'm going to purchase TCP/IP
Illustrated Vol 2 by
the late Dr. Stevens. Long fat pipes are discussed in this book.
>
> SACK should only minimize the number of segments the sender has to
> retransmit. In either case (SACK on and off), not ACKed segments should
> time out and be retransmitted, shouldn't they?
>
I have no idea. I should have maybe taken a closer look at the RFC
before I started
to speculate what was going on.
>
> It may be as well. I've been using Fedora Core 5 servers for a while,
> which has fack, sack and dsack enabled by default and it's been working
> fine. Although it does not prove anything, as OP's environment is quite
> different to mine.
The fact that he changed the values to zero and it works seems to imply
that fack, sack, and
dsack were not not enabled by default.
Okay, with that, I'm just going to shut up before I make myself look
dumber than I already am.
|
|
|
|
|