Re: 2.6.18-rc[67] crashes in TCP ack handling
On Sun, 17 Sep 2006 12:11:01 +0200 bert hubert <[EMAIL PROTECTED]> wrote: > On Sun, Sep 17, 2006 at 08:32:14AM +0900, Stephen Hemminger wrote: > > > By building all the possiblities into the kernel, ie. not as modules > > you get the last one registered. TCP LP is probably the worst one > > to use, because it is designed for bulk low priority applications. > > It also is one of the newest least tested. Right now, I would rate > > Hehe, this seems to be a bad default configuration policy then. People > generally don't assume that if the kernel offers 10 policies that the most > unstable will be used by default if you compile them all in. > > I've attached a patch that reorders the choices per your suggested order, so > people are most likely to get a sane default. > > I've tried to make "reno" the default, no matter what you compiled in, but > it didn't work. The linker probably reorders tcp_cong.o in early. Reno is always builtin. To choose it use sysctl -w net.ipv4.tcp_congestion_control=reno Depending on load order is not good, and not a safe way to configure. If you want a particular value set it with sysctl! The more experimental ones are already labeled as EXPERIMENTAL. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc[67] crashes in TCP ack handling
On Sun, Sep 17, 2006 at 08:32:14AM +0900, Stephen Hemminger wrote: > By building all the possiblities into the kernel, ie. not as modules > you get the last one registered. TCP LP is probably the worst one > to use, because it is designed for bulk low priority applications. > It also is one of the newest least tested. Right now, I would rate Hehe, this seems to be a bad default configuration policy then. People generally don't assume that if the kernel offers 10 policies that the most unstable will be used by default if you compile them all in. I've attached a patch that reorders the choices per your suggested order, so people are most likely to get a sane default. I've tried to make "reno" the default, no matter what you compiled in, but it didn't work. The linker probably reorders tcp_cong.o in early. > Without a back trace, it will be hard to find the bug in TCP LP Indeed. Many thanks for your quick answer Stephen! -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services --- linux-2.6.18/net/ipv4/Makefile~ 2006-09-17 11:48:33.0 +0200 +++ linux-2.6.18/net/ipv4/Makefile 2006-09-17 11:48:45.0 +0200 @@ -7,7 +7,7 @@ ip_output.o ip_sockglue.o inet_hashtables.o \ inet_timewait_sock.o inet_connection_sock.o \ tcp.o tcp_input.o tcp_output.o tcp_timer.o tcp_ipv4.o \ -tcp_minisocks.o tcp_cong.o \ +tcp_minisocks.o \ datagram.o raw.o udp.o arp.o icmp.o devinet.o af_inet.o igmp.o \ sysctl_net_ipv4.o fib_frontend.o fib_semantics.o @@ -37,16 +37,20 @@ obj-$(CONFIG_IP_ROUTE_MULTIPATH_CACHED) += multipath.o obj-$(CONFIG_INET_TCP_DIAG) += tcp_diag.o obj-$(CONFIG_NET_TCPPROBE) += tcp_probe.o -obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o -obj-$(CONFIG_TCP_CONG_CUBIC) += tcp_cubic.o -obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o + +obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o +obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o +obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o +obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_highspeed.o obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o +obj-$(CONFIG_TCP_CONG_CUBIC) += tcp_cubic.o +obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o -obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o -obj-$(CONFIG_TCP_CONG_VENO) += tcp_veno.o -obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o -obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o +obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o + +# make sure the built in congestion scheme is the default +obj-y += tcp_cong.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o
Re: 2.6.18-rc[67] crashes in TCP ack handling
On Sun, 17 Sep 2006 00:19:48 +0200 bert hubert <[EMAIL PROTECTED]> wrote: > The bad news is that I haven't yet been able to capture traces. > Once every three days or so I get a crash of 2.6.18-rc[67] which > *probably* end in tcp_ack(), but I don't have the exact dump. > > My .config is indeed heavy on TCP congestion stuff: > > $ zcat /proc/config.gz | grep -i tcp > CONFIG_INET_TCP_DIAG=y > CONFIG_TCP_CONG_ADVANCED=y > # TCP congestion control > CONFIG_TCP_CONG_BIC=y > CONFIG_TCP_CONG_CUBIC=y > CONFIG_TCP_CONG_WESTWOOD=y > CONFIG_TCP_CONG_HTCP=y > CONFIG_TCP_CONG_HSTCP=y > CONFIG_TCP_CONG_HYBLA=y > CONFIG_TCP_CONG_VEGAS=y > CONFIG_TCP_CONG_SCALABLE=y > CONFIG_TCP_CONG_LP=y > CONFIG_TCP_CONG_VENO=y > CONFIG_IP_VS_PROTO_TCP=y > CONFIG_NETFILTER_XT_MATCH_TCPMSS=m > CONFIG_IP_NF_TARGET_TCPMSS=y > # CONFIG_NET_TCPPROBE is not set > # CONFIG_ISCSI_TCP is not set > # CONFIG_NFSD_TCP is not set > > However, I haven't specifically configured anything. > $ dmesg | grep -i tcp > [ 33.106317] TCP established hash table entries: 131072 (order: 8, 1048576 > bytes) > [ 33.107086] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) > [ 33.107476] TCP: Hash tables configured (established 131072 bind 65536) > [ 33.107605] TCP reno registered > [ 40.985770] IPVS: Registered protocols (TCP, UDP, AH, ESP) > [ 41.105710] TCP bic registered > [ 41.105833] TCP cubic registered > [ 41.105957] TCP westwood registered > [ 41.106080] TCP highspeed registered > [ 41.106203] TCP hybla registered > [ 41.106328] TCP htcp registered > [ 41.106452] TCP vegas registered > [ 41.106574] TCP veno registered > [ 41.106698] TCP scalable registered > [ 41.106822] TCP lp registered > > $ cat ipv4/tcp_congestion_control > lp > > I hope to follow up this message with the actual backtrace, but this is > already an heads up. > > Sorry for not yet being able to be more specific. > > bert By building all the possiblities into the kernel, ie. not as modules you get the last one registered. TCP LP is probably the worst one to use, because it is designed for bulk low priority applications. It also is one of the newest least tested. Right now, I would rate the choices as: Stable: reno, bic, htcp, westwood, cubic Testing: hybla, highspeed, scaleable, vegas Unstable: veno, lp The stable ones seem to be reliable and have no known issues. The testing group are only interesting for comparison, and need more tuning. The unstable group, are new and need even more testing for fairness and robustness. Without a back trace, it will be hard to find the bug in TCP LP - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.18-rc[67] crashes in TCP ack handling
The bad news is that I haven't yet been able to capture traces. Once every three days or so I get a crash of 2.6.18-rc[67] which *probably* end in tcp_ack(), but I don't have the exact dump. My .config is indeed heavy on TCP congestion stuff: $ zcat /proc/config.gz | grep -i tcp CONFIG_INET_TCP_DIAG=y CONFIG_TCP_CONG_ADVANCED=y # TCP congestion control CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=y CONFIG_TCP_CONG_HTCP=y CONFIG_TCP_CONG_HSTCP=y CONFIG_TCP_CONG_HYBLA=y CONFIG_TCP_CONG_VEGAS=y CONFIG_TCP_CONG_SCALABLE=y CONFIG_TCP_CONG_LP=y CONFIG_TCP_CONG_VENO=y CONFIG_IP_VS_PROTO_TCP=y CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_IP_NF_TARGET_TCPMSS=y # CONFIG_NET_TCPPROBE is not set # CONFIG_ISCSI_TCP is not set # CONFIG_NFSD_TCP is not set However, I haven't specifically configured anything. $ dmesg | grep -i tcp [ 33.106317] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 33.107086] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 33.107476] TCP: Hash tables configured (established 131072 bind 65536) [ 33.107605] TCP reno registered [ 40.985770] IPVS: Registered protocols (TCP, UDP, AH, ESP) [ 41.105710] TCP bic registered [ 41.105833] TCP cubic registered [ 41.105957] TCP westwood registered [ 41.106080] TCP highspeed registered [ 41.106203] TCP hybla registered [ 41.106328] TCP htcp registered [ 41.106452] TCP vegas registered [ 41.106574] TCP veno registered [ 41.106698] TCP scalable registered [ 41.106822] TCP lp registered $ cat ipv4/tcp_congestion_control lp I hope to follow up this message with the actual backtrace, but this is already an heads up. Sorry for not yet being able to be more specific. bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
