On Mondayen den 18 March 2002 16.35, Harald Welte wrote:
Just as a small note to all people maintaining conntrack/NAT helpers:
Please port your helpers to the newnat code, I will have to temporarily
remove them from CVS as soon as newnat apprears in the mainstream kernel.
This applies to all
I'm working on a proxy type program, using REDIRECT to catch (tcp) traffic,
and I'm seeing severe network degradation above ~2000 connection.
(computer: 1Gb p3, 2Gb memory, kernel 2.4.18 + aa1 patch)
Two questions first: how many packets/second is these 2000 connections?
And, do you have a
On Sat, 16 Mar 2002, Takuya Satoh wrote:
Hi,
Does the old FTOS target zero the ECN bits?
Quick Answer = YES
Long Answer - FTOS takes whatever HEX code you specify and overwrites
_all_ 8 bits of the TOS field. So if you only specify say 0xf0 then the
ECN are overwritten with 0's. make sense?
Hello Martin,
thanks for your numbers.
with 16384 hashbuckets and a maximum of 131072 tracked connections it took
7.5 seconds to perform 1 million lookups in the hashtable (using
__ip_conntrack_find from userspace).
Was this 1 million lookups to a random hash bucket each, with guaranteed
no
Hi Harald,
the SMP fixups for the string match changed the max() to a 2.4.9 style
max() with 3 args... here's a patch to fix it.
/Martin
Never argue with an idiot. They drag you down to their level, then beat you with
experience.
--- netfilter/userspace/patch-o-matic/extra/string.patch.orig
with 16384 hashbuckets and a maximum of 131072 tracked connections it took
7.5 seconds to perform 1 million lookups in the hashtable (using
__ip_conntrack_find from userspace).
Was this 1 million lookups to a random hash bucket each, with guaranteed
no match? Assuming this in the
On Mon, 18 Mar 2002, Patrick Schaaf wrote:
Hello Martin,
thanks for your numbers.
with 16384 hashbuckets and a maximum of 131072 tracked connections it took
7.5 seconds to perform 1 million lookups in the hashtable (using
__ip_conntrack_find from userspace).
Was this 1 million
grep conntrack /proc/slabinfo (about 4200 connections at the time)
ip_conntrack4527 4532 352 412 412 1
8192 buckets, 65536 max
I guess the hash function fails for my setup (note: this is a test setup,
connection originating from a single ip to a single ip)
... and probably