| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-id: <fbbd26f52a58.48038f49@fnal.gov> Date: Mon, 14 Apr 2008 17:07:21 -0500 From: Wenji Wu <wenji@...l.gov> To: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> Cc: 'Netdev' <netdev@...r.kernel.org> Subject: Re: RE: A Linux TCP SACK Question > Hmm, now there are even less retransmissions (barely some with > the SACK in the end). > > I suppose the reordering detection is good enough to kill them. ...You > > could perhaps figure that out from MIBs if you would want to. > Yes, the web100 shows that the tcp_reordering could be as large as 127. I just rerun the following experimetns to show why there are few retransmissions in my previous posts. (1) Flush the sytem routing cache by running "ip route flush cache" before running and tcpdumping the traffic (2) Before running and tcpdumping the traffic, run a data transmission test to generate tcp_reordering in the routing cache. Do not flush the routing cache. Then running and tcpdumping the traffic. Both experiments with sack off. The results is posted to https://plone3.fnal.gov/P0/WAN/Members/wenji/adaptive_tcp_reordering/ So, the few retransmissions in my previous post are really caused by the routing cache. But flushing cahce has nothing to do with SACK on/off. Still the trhoughput with SACK off is better than that of with SACK on. wenji -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists