Jeff Chua wrote:
On Jan 29, 2008 6:53 PM, Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote:
As the problem can be reproduced so easily, could you capture a full TCP
session and send the pcap file? Thus it could be analyzed, replayed, etc.
and found the reason why the patch above slows down the printing.
By reverting back it we loose TCP reopening support.
Not an expert here. I use 'tcpdump -i lo' and don't see anything
different between the good and bad. Anyway, attached are the good and
bad log files.
There's a slight pause of 27 seconds after 502 jobs (both good and bad
runs), then the good one will resume and transmit in burst until
completing all the 1000 times. The bad run will resume and transmit
one-by-one every 3 seconds.
Please tell me what options to use with tcpdump to dump more useful output.
A binary dump would be more useful:
tcpdump -i lo -w <outfile>
and I guess Jozsef also wants "-s 0" so the full packets are included.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
