OS/2, eCS & ArcaOS - Technical > Networking
Moved to UltraFibre 120 Mb/s but OS/2 chugs at 10 Mb/s...???
massimo s.:
you are lucky
here setting the same values to my stack IP i have no iprovements at all
still 500-600KiloBytes download from Firefox or from wget at the command prompt on my eCS2.1 desktop with an Intel pro 1000 XT PCI-X Nic… binded at gigabit ethernet to my Cisco gigabit ethernet switch
that communicate with my Cisco 8xx router that runs an FTTC 100Mb/sec…. :(
i've also tried changing NIC card with an Intel pro 100 (100Megabit so, it should be completely sufficient for a download datarate)
with no success at all, here allways max 500-600Kilobytes of download datarates :(
guys, any help?
i've this issue on all my eCS machines :(
the issue is spreading since now users are upgrading internet connections from hyperlan WADSLs (12/1) to FTTCs 50/10 & 100/20 :(
massimo
--- Quote from: Dariusz Piatkowski on October 07, 2017, 05:54:56 pm ---Ian and Remy,
Guys, another update...I thought I would max out the settings with the goal of achieving highest performance...then if I start running into problems I would dial things back a step at a time.
So here are my current applicable INETCFG.INI settings:
#Inetcfg: CURRENT DEFAULT MINIMUM MAXIMUM
keepalive 300 300 0 7800 KeepAlive (sec)
tcpswinsize 246723 32768 1024 246723 TCP SendWindow Size
tcprwinsize 246723 32768 1024 246723 TCP RecvWindow Size
udpswinsize 246723 41600 1024 246723 UDP SendWindow Size
udprwinsize 246723 41600 1024 246723 UDP RecvWindow Size
lingertime 120 120 0 65535 Linger Time (sec)
ipforward 0 0 0 1 IP Forwarding flag ON/OFF
timestmp 0 0 0 1 TCP TimeStamps ON/OFF
msl 30 30 1 16384 TCP MaxSegLifeTime (sec)
sack 1 0 0 1 Selective ACK ON/OFF
...the xxxwindsize have been set to MAX values.
I still need to research a bit to understand the impact of the following:
lingertime
ipforward
timestamp (I think this may be used by SACK, not sure though)
msl
....and drummroll for the results please!!! ;D
1) http://speedsmart.net/ => 87 Mb/s
2) http://testmy.net => 40 Mb/s
3) http://beta.speedtest.net => 91 Mb/s
4) FF download => 5000 KB/s, so roughly sustained 50 Mb/s
All in all, I would say that is basically what I'm seeing on my Winx boxes.
--- End quote ---
David McKenna:
Massimo,
Check inside your C:\TCPIP\BIN\B4TCP.CMD file and make sure it has this:
if exist %etc%\inetcfg.ini CALL inetcfg.exe -set all
If not add it. This command applies the inetcfg.ini file settings when you boot.
Regards,
Roderick Klein:
--- Quote from: Dariusz Piatkowski on October 07, 2017, 05:54:56 pm ---Ian and Remy,
Guys, another update...I thought I would max out the settings with the goal of achieving highest performance...then if I start running into problems I would dial things back a step at a time.
So here are my current applicable INETCFG.INI settings:
#Inetcfg: CURRENT DEFAULT MINIMUM MAXIMUM
keepalive 300 300 0 7800 KeepAlive (sec)
tcpswinsize 246723 32768 1024 246723 TCP SendWindow Size
tcprwinsize 246723 32768 1024 246723 TCP RecvWindow Size
udpswinsize 246723 41600 1024 246723 UDP SendWindow Size
udprwinsize 246723 41600 1024 246723 UDP RecvWindow Size
lingertime 120 120 0 65535 Linger Time (sec)
ipforward 0 0 0 1 IP Forwarding flag ON/OFF
timestmp 0 0 0 1 TCP TimeStamps ON/OFF
msl 30 30 1 16384 TCP MaxSegLifeTime (sec)
sack 1 0 0 1 Selective ACK ON/OFF
...the xxxwindsize have been set to MAX values.
I still need to research a bit to understand the impact of the following:
lingertime
ipforward
timestamp (I think this may be used by SACK, not sure though)
msl
....and drummroll for the results please!!! ;D
1) http://speedsmart.net/ => 87 Mb/s
2) http://testmy.net => 40 Mb/s
3) http://beta.speedtest.net => 91 Mb/s
4) FF download => 5000 KB/s, so roughly sustained 50 Mb/s
All in all, I would say that is basically what I'm seeing on my Winx boxes.
--- End quote ---
It makes sense... Windows XP also had IP stack tuners to change some of these value's as you had reduced performance duo to certain IP settings not being tuned automatically.
Roderick
Roderick Klein:
--- Quote from: Dariusz Piatkowski on October 07, 2017, 04:35:48 pm ---Hi Ian!
First of all, big Thank You for putting me on the right path here. The results so far are great, let me explain step at a time below...
--- Quote from: Ian Manners on October 06, 2017, 07:31:37 pm ---...
Manual MTU value depends on what your fibre is using but you are using mtudiscover for MTU so its fine.
You would normally use 1500 for PPPoA, 1492 for PPPoE but it's really depending on your provider. Some will only accept 1492 for PPPoA and 1452 for PPPoE as your on fibre I would expect you to use 1500 and then let mtudiscover look after it. I have no idea if your provider allows jumbo packets or not, I don't even know if OS/2 supports MTU values above 1500 either but normally smaller is better than larger, up to a point...
--- End quote ---
I re-set the value to 1500 in my \mptn\bin\setup.cmd. My old ISP which utilized PPPoE over DSL line specifically requested 1452, the new guys...well, I did not get any info because the tech doing the install was very tight lipped..LOL, he specifically asked me to call their tech line instead.
--- Quote from: Ian Manners on October 06, 2017, 07:31:37 pm ---...
If you have created an inetcfg.ini file in your x:\mptn\etc directory.
Note you should change your keepalive and sack values to reflect what is below as well.
...
--- End quote ---
Why do you suggest that SACK be off? I am basiing this on my understanding of that flag...the following article does a pretty nice job of explaining it's functionality => http://packetlife.net/blog/2010/jun/17/tcp-selective-acknowledgments-sack/. In short, if both the client and server support this, when an actual packet is dropped this will allow the re-transmission of ONLY the dropped data, as opposed to a full payload from the dropped point onwards until the end of the conversation. If successful this implies less data being re-sent.
Regarding the keepalive, I will change it to sync it up with my primary tcpip apps, that being Firefox and Privoxy. Specifically:
1) network.tcp.keepalive.idle_time 600
Beyond the above, what remains is to play with the sizes of the values for these key parameters you list below:
--- Quote from: Ian Manners on October 06, 2017, 07:31:37 pm ---...
The main values you want to play with are:-
tcpswinsize
tcprwinsize
udpswinsize
udprwinsize
...
--- End quote ---
So far here are the results for the following settings:
tcpswinsize 131072
tcprwinsize 131072
udpswinsize 41600
udprwinsize 41600
My FF based downloads are now moving at a speedy 50 Mb/s, a HUGE improvement from where I started!!!
Various internet connection speed test report a steady 90-95 Mb/s rates, this is substantially better as well.
--- End quote ---
If you want to see your machine go down quicker, do turn on SACK. We experimented with this setting at Mensys on some servers and as somebody else already reported, stay far clear from switching it on. It will cause more pain then its worth...
Roderick
Neil Waldhauer:
SpeedSmart gives my speed at 30 MbPS down for my cable modem.
Download from github gives 400 KBPS.
Firefox is the same for both. So Massimo may not have a network problem at all. If he runs SpeedSmart and it shows a good speed, it's likely to be something else. The fact that wget is also slow is probably a clue as to what is really causing slow download.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version