> From: "Jean-Michel Hemstedt" <[EMAIL PROTECTED]> > > > Since in my test, each connection is ephemeral (<10ms) ...
One question here is whether the traffic generator is acting like a real set of users or like an attacker. A real user would not keep trying to make connections at the same rate if the previous attempts were not being served. I suspect you're acting more like an attacker. > > So I'm guessing that large number of entries in conntrack table is > > evidence that packets are being lost. > not only: a crashed endpoint breaking the tcp sequence causes also > garbage entries in conntrack (known issue). Again, a crashed endpoint would likely not get as many hits. My guess is that the reason for all the conntrack entries is related to what I described in my earlier mail. Creating conntrack entries is expensive. My machine could only do it about 1000 time/sec. Off hand I don't know which packets are dropped. I'd guess that the ones that make it through the conntrack code do get forwarded, but I don't know. If, for example, the return packets are lost because we're too busy adding new conntrack entries, then there's nothing to cause the entries to go away, other than those timeouts. > > Just wondering, how did you measure cpu load? > procinfo -n10 ; [d] for showing differences, which in fact, computes > the differences of cumulated cpu time (got from > /proc/stat) on the given period: (tsys1-tsys0)/T I see /proc/stat - user, nice, system, idle. Thank you. Very useful. ================ > > Everybody agrees that NAT is evil and it should be avoided in all > circumstances. This is news to me! Is this just because the implementation is lacking or some more fundamental reason?
