Forum Discussion
marco_octavian_
Aug 06, 2013Nimbostratus
From what I know, you can't modify the delayed-ack parameters. Wouldn't you even know how to intelligently modify this if you could???
Modifying the rto_min is done at the route level on linux and you can do the same on the LTM (linux/tmos) but I would experiment to see what the results really are. Example:
[root@ltm1:Active:Disconnected] config ip route change default dev internal rto_min 60ms
[root@ltm1:Active:Disconnected] config ip route show table main
127.1.1.0/24 dev tmm0 proto kernel scope link src 127.1.1.1
127.3.0.0/24 dev mgmt_bp scope link
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.115
172.16.21.0/24 dev internal proto kernel scope link src 172.16.21.8
172.16.31.0/24 dev external proto kernel scope link src 172.16.31.8
1.1.1.0/24 dev HA proto kernel scope link src 1.1.1.1
default dev internal scope link rto_min lock 60ms
default via 192.168.5.5 dev eth0 metric 9
[root@ltm1:Active:Disconnected] config
You could also put in a "functional" iRule just to issue a pause/wait with the "after" commmand for each VS.
Having said all this, I would not change anything. Is it causing any issues right now ?It seems odd to inject delay, cell network or otherwise. Why do you want this long delay? How does this streamline your app performance?