1
Networking / inetcfg.ini - window size, but why this result?
« on: March 03, 2025, 05:13:19 am »
So a couple of days ago the AOS testers list was asked with giving some new SEND & RECEIVE window sizes a try.
Ever since I went to a 1Gig fibre line I had tweaked my inetcfg.ini to use the max allowable value for both TCP & UDP windows.
However this request prompted me to test and surprisingly enough I found that the smaller window size actually caused a repeatable 20-25% improvement when doing a speedtest run.
OK, nice...so I permanently updated my inetcfg.ini with these values, and carried along.
Today I needed to reboot my machine, all was good. The box re-started fine, I brought up my regular apps: PMMail, Thunderbird, RDP, Firefox...but whoa...hang on...why isn't Firefox taking me anywhere?
Yeah, it just sat there, spinning, "connecting..." but it would never go anywhere.
So I check the other apps: PMMail is good, but TB...nope, same story as FF.
I whip up the speedtest CLI...nope, not going anywhere either.
After numerous trials I determined that the window sizing was impacting certain apps. Further on, I found that on my machine anything smaller than 131,072 (so 128K) would cause the above described "stall", while anything bigger consistenty 'just works'!!! ugh???
Can anyone explain this please?
Here are the contents of my inetcfg.ini:
Ever since I went to a 1Gig fibre line I had tweaked my inetcfg.ini to use the max allowable value for both TCP & UDP windows.
However this request prompted me to test and surprisingly enough I found that the smaller window size actually caused a repeatable 20-25% improvement when doing a speedtest run.
OK, nice...so I permanently updated my inetcfg.ini with these values, and carried along.
Today I needed to reboot my machine, all was good. The box re-started fine, I brought up my regular apps: PMMail, Thunderbird, RDP, Firefox...but whoa...hang on...why isn't Firefox taking me anywhere?

Yeah, it just sat there, spinning, "connecting..." but it would never go anywhere.
So I check the other apps: PMMail is good, but TB...nope, same story as FF.
I whip up the speedtest CLI...nope, not going anywhere either.
After numerous trials I determined that the window sizing was impacting certain apps. Further on, I found that on my machine anything smaller than 131,072 (so 128K) would cause the above described "stall", while anything bigger consistenty 'just works'!!! ugh???
Can anyone explain this please?
Here are the contents of my inetcfg.ini:
Code: [Select]
#Inetcfg: CURRENT DEFAULT MINIMUM MAXIMUM
keepalive 60 7800 0 7800 KeepAlive (sec)
tcpswinsize 131072 32768 1024 246723 TCP SendWindow Size
tcprwinsize 131072 32768 1024 246723 TCP RecvWindow Size
udpswinsize 131072 9216 1024 246723 UDP SendWindow Size
udprwinsize 131072 41600 1024 246723 UDP RecvWindow Size
lingertime 120 120 0 65535 Linger Time (sec)
probecnt 8 8 1 8 Number Of KeepAlive Probes
ipforward 0 0 0 1 IP Forwarding flag ON/OFF
mtudiscover 1 1 0 1 TCP Path MTU Discovery ON/OFF
arpkillc 1200 1200 180 15300 ARP Complete TimeOut (sec)
arpkilli 180 180 60 1200 ARP InComplete TimeOut (sec)
lipcstswinsize 10240 10240 1024 246723 LIPC Stream SendWindow Size
lipcstrwinsize 10240 10240 1024 246723 LIPC Stream RecvWindow Size
lipcdgswinsize 2048 2048 1024 246723 LIPC Dgram SendWindow Size
lipcdgrwinsize 4096 4096 1024 246723 LIPC Dgram RecvWindow Size
synattack 0 0 0 1 SYN Attack Flag ON/OFF
syncookie 0 0 0 1 SYN Cookie Flag ON/OFF
firewall 0 0 0 1 FIREWALL ON/OFF
multidefrt 1 1 0 1 Multiple Default Routes ON/OFF
winscale 1 1 0 1 TCP Window Scale ON/OFF
timestmp 1 0 0 1 TCP TimeStamps ON/OFF
realslow 20 20 1 100 TCP TW Q Slow Timeout ticks
perfhttp 1 1 0 1 Fast Path HTTP ON/OFF
tcpttl 64 64 1 255 TCP TTL (hops)
udpttl 64 64 1 255 UDP TTL (hops)
icmpttl 64 64 1 255 ICMP TTL (hops)
fragttl 60 60 1 255 Fragment TTL (sec)
reusetw 1 1 0 1 Reuse Time Wait ON/OFF
msl 30 30 1 16384 TCP MaxSegLifeTime (sec)
cc 0 0 0 1 TTCP function ON/OFF
sack 1 0 0 1 Selective ACK ON/OFF