Reply To: Tuning packet size? High PPS/bw from ACKs over VPN bond link

Home Page Forums Network Management VPN Tuning packet size? High PPS/bw from ACKs over VPN bond link Reply To: Tuning packet size? High PPS/bw from ACKs over VPN bond link

#50967

houkouonchi
Member

Ok and I see:

http://www.zeroshell.net/eng/forum/viewtopic.php?t=821

which seems to verify my suspicion that ACKs are being sent over both lines and thus duplicated. Using some of the things listed in that thread did help with my bandwidth usage (upload was only around 3 meg instead of 4 meg) and now iperf shows better speeds atleast on the downstream side:

root@zeroshell root> ./iperf -c 10.99.98.2


Client connecting to 10.99.98.2, TCP port 5001
TCP window size: 16.0 KByte (default)


[ 3] local 10.99.98.1 port 48910 connected with 10.99.98.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 83.1 MBytes 69.3 Mbits/sec

Upstream was not so good:

root@zeroshell root> ./iperf -s


Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)


[ 4] local 10.99.98.1 port 5001 connected with 10.99.98.2 port 50552
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.3 sec 29.6 MBytes 24.1 Mbits/sec

So I think my problem is just the duplicate ACKs. Is there anyway I can stop them? Running this web100 NDT test to my server (server that is not a ZS box) I get a crapton of duplicate ACKs:

admin@zeroshell: 06:48 AM :/proc# web100clt -l -n 208.97.141.21
Testing network path for configuration and performance problems — Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 64.47 Mb/s
running 10s inbound test (server to client) . . . . . . 64.43 Mb/s
The slowest link in the end-to-end path is a 10 Gbps 10 Gigabit Ethernet/OC-192 subnet
Information: Other network traffic is congesting the link
Information: The receive buffer should be 20593 kbytes to maximize throughput
Server ‘208.97.141.21’ is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]


Web100 Detailed Analysis



Web100 reports the Round trip time = 16.87 msec;the Packet size = 1350 Bytes; and
There were 31 packets retransmitted, 11327 duplicate acks received, and 57519 SACK blocks received
Packets arrived out-of-order 18.92% of the time.
This connection is sender limited 30.29% of the time.
Increasing the current send buffer (256.00 KB) will improve performance
This connection is network limited 69.71% of the time.

When running the same test from my desktop here at work I get way less duplicate ACKs even though way more packets/data was sent/received due to the much faster link speed:

root@sigito: 06:44 AM :~# web100clt -l -n 208.97.141.21
Testing network path for configuration and performance problems — Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 553.38 Mb/s
running 10s inbound test (server to client) . . . . . . 565.91 Mb/s
The slowest link in the end-to-end path is a a 622 Mbps OC-12 subnet
Information: Other network traffic is congesting the link
Server ‘208.97.141.21’ is not behind a firewall. [Connection to the ephemeral port was successful]
Client is probably behind a firewall. [Connection to the ephemeral port failed]


Web100 Detailed Analysis



Web100 reports the Round trip time = 3.64 msec;the Packet size = 1368 Bytes; and
There were 2 packets retransmitted, 392 duplicate acks received, and 393 SACK blocks received
Packets arrived out-of-order 0.15% of the time.
This connection is sender limited 97.60% of the time.
This connection is network limited 2.40% of the time.