netdev - Re: [RFC] SFQ planned changes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Jan 2012 01:14:58 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Dave Taht <dave.taht@...il.com>
Cc:	Michal Kubeček <mkubecek@...e.cz>,
	netdev@...r.kernel.org,
	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>
Subject: Re: [RFC] SFQ planned changes

Le mercredi 04 janvier 2012 à 00:57 +0100, Dave Taht a écrit :
> On Tue, Jan 3, 2012 at 5:08 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > Here is the code I ran on my test server with 200 netperf TCP_STREAM
> > flows with pretty good results (each flow gets 0.5 % of bandwidth)
> 
> Can I encourage you to always simultaneously run a fping and/or a
> netperf -t TCP_RR
> 

ping is pretty nice ;)

# ping -c 20 192.168.20.112
PING 192.168.20.112 (192.168.20.112) 56(84) bytes of data.
64 bytes from 192.168.20.112: icmp_req=1 ttl=64 time=0.251 ms
64 bytes from 192.168.20.112: icmp_req=2 ttl=64 time=0.123 ms
64 bytes from 192.168.20.112: icmp_req=3 ttl=64 time=0.124 ms
64 bytes from 192.168.20.112: icmp_req=4 ttl=64 time=0.108 ms
64 bytes from 192.168.20.112: icmp_req=5 ttl=64 time=0.131 ms
64 bytes from 192.168.20.112: icmp_req=6 ttl=64 time=0.126 ms
64 bytes from 192.168.20.112: icmp_req=7 ttl=64 time=0.156 ms
64 bytes from 192.168.20.112: icmp_req=8 ttl=64 time=0.123 ms
64 bytes from 192.168.20.112: icmp_req=9 ttl=64 time=0.111 ms
64 bytes from 192.168.20.112: icmp_req=10 ttl=64 time=0.129 ms
64 bytes from 192.168.20.112: icmp_req=11 ttl=64 time=0.112 ms
64 bytes from 192.168.20.112: icmp_req=12 ttl=64 time=0.138 ms
64 bytes from 192.168.20.112: icmp_req=13 ttl=64 time=0.118 ms
64 bytes from 192.168.20.112: icmp_req=14 ttl=64 time=0.119 ms
64 bytes from 192.168.20.112: icmp_req=15 ttl=64 time=0.121 ms
64 bytes from 192.168.20.112: icmp_req=16 ttl=64 time=0.125 ms
64 bytes from 192.168.20.112: icmp_req=17 ttl=64 time=0.128 ms
64 bytes from 192.168.20.112: icmp_req=18 ttl=64 time=0.108 ms
64 bytes from 192.168.20.112: icmp_req=19 ttl=64 time=0.149 ms
64 bytes from 192.168.20.112: icmp_req=20 ttl=64 time=0.126 ms

--- 192.168.20.112 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 18999ms
rtt min/avg/max/mdev = 0.108/0.131/0.251/0.031 ms


> latency under load test when doing stuff like this?
> 
> The amount of backlogged bytes is rather impressive...

200 tcp flooding flows... thats pretty normal.

If I add to this load a TCP_RR one I get :

# netperf -H 192.168.20.110 -v 0 -l 10 -t TCP_RR
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.20.110 (192.168.20.110) port 0 AF_INET : demo
7606.18 


If I stop the flood and start the TCP_RR alone :

# netperf -H 192.168.20.110 -v 0 -l 10 -t TCP_RR
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.20.110 (192.168.20.110) port 0 AF_INET : demo
12031.39 

And a ping on idle link :
#  ping -c 20 192.168.20.112
PING 192.168.20.112 (192.168.20.112) 56(84) bytes of data.
64 bytes from 192.168.20.112: icmp_req=1 ttl=64 time=0.119 ms
64 bytes from 192.168.20.112: icmp_req=2 ttl=64 time=0.090 ms
64 bytes from 192.168.20.112: icmp_req=3 ttl=64 time=0.085 ms
64 bytes from 192.168.20.112: icmp_req=4 ttl=64 time=0.087 ms
64 bytes from 192.168.20.112: icmp_req=5 ttl=64 time=0.084 ms
64 bytes from 192.168.20.112: icmp_req=6 ttl=64 time=0.084 ms
64 bytes from 192.168.20.112: icmp_req=7 ttl=64 time=0.088 ms
64 bytes from 192.168.20.112: icmp_req=8 ttl=64 time=0.085 ms
64 bytes from 192.168.20.112: icmp_req=9 ttl=64 time=0.083 ms
64 bytes from 192.168.20.112: icmp_req=10 ttl=64 time=0.082 ms
64 bytes from 192.168.20.112: icmp_req=11 ttl=64 time=0.082 ms
64 bytes from 192.168.20.112: icmp_req=12 ttl=64 time=0.085 ms
64 bytes from 192.168.20.112: icmp_req=13 ttl=64 time=0.086 ms
64 bytes from 192.168.20.112: icmp_req=14 ttl=64 time=0.084 ms
64 bytes from 192.168.20.112: icmp_req=15 ttl=64 time=0.089 ms
64 bytes from 192.168.20.112: icmp_req=16 ttl=64 time=0.081 ms
64 bytes from 192.168.20.112: icmp_req=17 ttl=64 time=0.084 ms
64 bytes from 192.168.20.112: icmp_req=18 ttl=64 time=0.086 ms
64 bytes from 192.168.20.112: icmp_req=19 ttl=64 time=0.084 ms
64 bytes from 192.168.20.112: icmp_req=20 ttl=64 time=0.084 ms

--- 192.168.20.112 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19000ms
rtt min/avg/max/mdev = 0.081/0.086/0.119/0.012 ms


I can do a test on full Gigabit speed (removing the HTB) and 1000 flows
and post results


--
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