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

Well, I have been running with SACK turned ON since (at least) the Fibre upgrade, so about 8 months now...no problems to report, at least nothing that I am aware of because it creates such a blatant issue.

However, as you and others have pointed out, the OS/2 tcpip stack apparently has a problem with this...so I'm now in the test mode having turned it OFF.

I will monitor for a while and will provide an update later on. Keep in mind, my extent of running a server process is the Web/2 application, nothing else. I suppose any tcpip apps may be impacted by this though, such as Firefox perhaps? So theoretically I should see something eventually...time will tell.

here setting the same values to my stack IP i have no iprovements at allstill 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 switchthat communicate with my Cisco 8xx router that runs an FTTC 100Mb/sec…. ...guys, any help?...

Yeah, I feel your pain...when it comes to on-line "feel" nothing beats a fast connection speed and when it's not there it gets pretty frustrating.

OK, so a couple of things:

1) various test servers will be impacted by your local tcpip stack settings, for example, take the SACK flag...as I mentioned in my response to Roderick, I did shut it off right now to test it out, the immediate impact => speedtest.net DIES!!! I get a burst of full speed for about 2-3 secs then the traffic completely stops...judging by this result alone I would be inclined to say that having SACK OFF is a mistake...yet hitting several of the other test servers shows no impact, so your results will vary

2) this is a bit of a follow-up to the idea above, but as applicable to the bigger internet picture...you will get different speeds from different servers, so just because I can do 10 Mbyte to my local test server (same city actually) it does not mean that a server somewhere in China or EU for that matter will show the same results...network latency adds up, etc, etc

3) now to be more specific, can you test what you are seeing using another machine on your LAN? For example, in my testing I was attempting to debug the OS/2 issue but my other boxes (Win7 and mobile devices) were showing decent results...is that the case for you as well? If yes, then indeed, the problem appears to lie with the OS/2 setup itself, if no, then it may very well exist outside of your LAN and on the WAN side

4) there are some more in-depth tools you could use, take a look at the port of Wireshark (https://os2ports.smedley.id.au/index.php?page=wireshark) that Paul Smedley did, it will allow you to visually inspect your tcpip stack traffic and may highlight where your OS/2 specific configuration issue lies, great tunning aid, a bit of a learning curve, you need to capture a tcpip trace on your OS/2 machine then pull this into the Wireshark app, not complex at all, but if you're never done it you just have to try it out a couple of times (look up the thread we had on this forum regarding this, great discussion), heck, that could be a great general discussion of how to tune the OS/2 tcpip stack and maybe deserves a separate thread?

1) various test servers will be impacted by your local tcpip stack settings, for example, take the SACK flag...as I mentioned in my response to Roderick, I did shut it off right now to test it out, the immediate impact => speedtest.net DIES!!! I get a burst of full speed for about 2-3 secs then the traffic completely stops...judging by this result alone I would be inclined to say that having SACK OFF is a mistake...yet hitting several of the other test servers shows no impact, so your results will vary

The advise is based on the first download server that Mensys ever put online for downloads for eCS. I managed 4 servers running OS/2 in a large datacenter with 100 megabit uplink. And with a lot of traffic you could get the TCP/IP stack to get exhaust the system its memory in about 30 minutes by switching SACK on. There is clearly a bug in the stack! Hence the comment on the inetcfg.ini of eCS to *never* turn it on.

1) various test servers will be impacted by your local tcpip stack settings, for example, take the SACK flag...as I mentioned in my response to Roderick, I did shut it off right now to test it out, the immediate impact => speedtest.net DIES!!! I get a burst of full speed for about 2-3 secs then the traffic completely stops...judging by this result alone I would be inclined to say that having SACK OFF is a mistake...yet hitting several of the other test servers shows no impact, so your results will vary

The advise is based on the first download server that Mensys ever put online for downloads for eCS. I managed 4 servers running OS/2 in a large datacenter with 100 megabit uplink. And with a lot of traffic you could get the TCP/IP stack to get exhaust the system its memory in about 30 minutes by switching SACK on. There is clearly a bug in the stack! Hence the comment on the inetcfg.ini of eCS to *never* turn it on.

Interestingly, with the default ArcaOS default settings and a NVidia MCP51 controller on a LTE network, I usually get about 12 Mb/s down. Tried in the morning when I guess the network wasn't so congested and got 25 Mb/s, which sounds better then your fibre connection. All the machines connected seem to get the same no matter what OS is running.

I will certainly be interested in any information discovered. My ISP, Sonic Telecom, just emailed that they will be providing fiber to my home in September and for the same amount they have been charging for DSL I will get 1Gb/s (symmetrical). Woohoo!

i've tried to download wireshark (had to use my w10 laptop since unable to download from eCS'firefox), but as usual install something under eCS is a lot frustratingi've all GCC/KLIBC DLLs updated, but it complains that it need a dll "rocken.dll"searching on 3 different search engines i've found anything (also dunno why eCS devs hate search engines that are not the shi$$y googl monopolist)

that dll is not mentioned neither in the docs of the software

guys, we live in the era of terabytes hard-disks, we don't have anymore to deal with 100MegaBytes disk partitions, dunno why eCS devs still don'tbundle all the needed DLLs in a subdir in the package :-(that's a lot frustrating

about wireshark...i've all GCC/KLIBC DLLs updated, but it complains that it need a dll "rocken.dll"...that dll is not mentioned neither in the docs of the software...

I took a closer look at this, this DLL does not appear to be Wireshark related, for one thing, it is not present on my machine and I am able to successfuly use Wireshark.

My guess is that something else on your system appears to need this.

Do you have the 'DLL Tree' utility? This allows you to test load an EXE (or DLLs) and will map out (visually) what other DLLs are needed. I would suggest that you run wireshark.exe through that app and see where rocken.dll is being requested.