From: Ross Vandegrift <ross@kallisti.us>
To: Andi Kleen <andi@firstfloor.org>
Cc: Glenn Griffin <ggriffin.kernel@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Add IPv6 support to TCP SYN cookies
Date: Thu, 7 Feb 2008 14:44:46 -0500 [thread overview]
Message-ID: <20080207194446.GA25463@kallisti.us> (raw)
In-Reply-To: <20080206085357.GA1402@one.firstfloor.org>
On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
> That would be useful yes -- for different bandwidths.
My initial test is end-to-end 1000Mbps, but I've got a few different
packet rates.
> If the young/old heuristics do not work well enough anymore most
> likely we should try readding RED to the syn queue again. That used
> to be pretty effective in the early days. I don't quite remember why
> Linux didn't end up using it in fact.
I'm running juno-z with 2, 4, & 8 threads of syn flood to port 80.
wireshark measures 2 threads at 350pps, 4 threads at 750pps, and 8
threads at 1200pps. Under no SYN flood, the server handles 750 HTTP
requests per second, measured via httping in flood mode.
With a default tcp_max_syn_backlog of 1024, I can trivially prevent
any inbound client connections with 2 threads of syn flood.
Enabling tcp_syncookies brings the connection handling back up to 725
fetches per second.
If I raise the backlog to 16384, 4 threads gives me about 650 legit
requests per sec. Going to 8 threads makes connections very unreliable - a
handful will get through every 15 to 20 seconds. Again,
tcp_syncookies returns performance almost totally back to normal.
Cranking juno-z to the max generates me about 16kpps. Any syn backlog
is easily overwhelmed and nothing gets through. tcp_syncookies gets
me back to 650 requests per second.
At these levels the CPU impact of tcp_syncookies is nothing. I can't
measure a difference. In the real world, a 16kpps syn flood is small.
People with a distributed botnet can easily get to the hundreds of
thousands, and I have seen over million packets per second of SYN flood.
BTW, I can trigger a soft lockup BUG when I restart apache to change the
backlog during the 16kpps test-case:
BUG: soft lockup detected on CPU#1!
[<c044d1ec>] softlockup_tick+0x96/0xa4
[<c042ddb0>] update_process_times+0x39/0x5c
[<c04196f7>] smp_apic_timer_interrupt+0x5b/0x6c
[<c04059bf>] apic_timer_interrupt+0x1f/0x24
[<c045007b>] taskstats_exit_send+0x152/0x371
[<c05c007b>] netlink_kernel_create+0x5/0x11c
[<c05a7415>] reqsk_queue_alloc+0x32/0x81
[<c05a5aca>] lock_sock+0x8e/0x96
[<c05ce8c4>] inet_csk_listen_start+0x17/0x106
[<c05e720f>] inet_listen+0x3c/0x5f
[<c05a3e55>] sys_listen+0x4a/0x66
[<c05a4f4d>] sys_socketcall+0x98/0x19e
[<c0407ef7>] do_syscall_trace+0xab/0xb1
[<c0404eff>] syscall_call+0x7/0xb
=======================
BUG: soft lockup detected on CPU#3!
[<c044d1ec>] softlockup_tick+0x96/0xa4
[<c042ddb0>] update_process_times+0x39/0x5c
[<c04196f7>] smp_apic_timer_interrupt+0x5b/0x6c
[<c04059bf>] apic_timer_interrupt+0x1f/0x24
[<c045007b>] taskstats_exit_send+0x152/0x371
[<c05c007b>] netlink_kernel_create+0x5/0x11c
[<c05a7415>] reqsk_queue_alloc+0x32/0x81
[<c05a5aca>] lock_sock+0x8e/0x96
[<c05ce8c4>] inet_csk_listen_start+0x17/0x106
[<c05e720f>] inet_listen+0x3c/0x5f
[<c05a3e55>] sys_listen+0x4a/0x66
[<c05a4f4d>] sys_socketcall+0x98/0x19e
[<c0407ef7>] do_syscall_trace+0xab/0xb1
[<c0404eff>] syscall_call+0x7/0xb
=======================
--
Ross Vandegrift
ross@kallisti.us
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
next prev parent reply other threads:[~2008-02-07 19:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-04 23:01 [PATCH] Add IPv6 support to TCP SYN cookies Glenn Griffin
2008-02-05 15:55 ` Andi Kleen
2008-02-05 15:42 ` Alan Cox
2008-02-05 16:39 ` Andi Kleen
2008-02-05 16:03 ` Alan Cox
2008-02-05 16:48 ` Andi Kleen
2008-02-05 16:14 ` Alan Cox
2008-02-05 20:50 ` Willy Tarreau
2008-02-05 18:29 ` Glenn Griffin
2008-02-05 19:25 ` Ross Vandegrift
2008-02-05 20:11 ` Andi Kleen
2008-02-05 21:23 ` Ross Vandegrift
2008-02-06 8:53 ` Andi Kleen
2008-02-07 19:44 ` Ross Vandegrift [this message]
2008-02-08 12:07 ` Andi Kleen
2008-02-12 20:38 ` Ross Vandegrift
2008-02-05 20:02 ` Andi Kleen
2008-02-05 20:39 ` Evgeniy Polyakov
2008-02-05 20:53 ` Andi Kleen
2008-02-05 21:50 ` Evgeniy Polyakov
2008-02-05 21:20 ` Alan Cox
2008-02-05 21:52 ` Evgeniy Polyakov
2008-02-05 21:20 ` Willy Tarreau
2008-02-05 22:05 ` Alan Cox
2008-02-06 1:52 ` Glenn Griffin
2008-02-06 7:50 ` Andi Kleen
2008-02-06 17:36 ` Glenn Griffin
2008-02-06 18:45 ` Andi Kleen
2008-02-06 23:03 ` Glenn Griffin
2008-02-06 9:13 ` Evgeniy Polyakov
2008-02-06 18:30 ` Glenn Griffin
2008-02-07 7:24 ` Evgeniy Polyakov
2008-02-07 9:40 ` Eric Dumazet
2008-02-08 5:32 ` Glenn Griffin
2008-02-08 5:49 ` Glenn Griffin
2008-02-11 16:07 ` YOSHIFUJI Hideaki / 吉藤英明
2008-02-18 23:45 ` Glenn Griffin
2008-02-13 7:31 ` YOSHIFUJI Hideaki / 吉藤英明
2008-02-05 19:57 ` Jan Engelhardt
2008-02-05 21:25 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2008-02-04 23:01 Glenn Griffin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080207194446.GA25463@kallisti.us \
--to=ross@kallisti.us \
--cc=andi@firstfloor.org \
--cc=ggriffin.kernel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.