I have DSL2000 and with Update4 there is no full DSL-Downloadspeed again! I have DSL2000 and i got max. DSL1000 (checked on http://www.wieistmeineip.de )
I'm online via Router, and my wife's Laptop shows up full 2000-Speed, the AmigaOne under Linux the same. Only OS4 fails here.
Any hints?

Tomcat

_________________
Find the Bird in the Pic!

@Tomcat

Great avatar!

Rude!

_________________

@Tomcat

Have you tried with UPD4? It boost net speed a lot compared to UPD3!

Last edited by ikir on 08-Feb-2006 at 06:01 PM.

_________________
ikir

@ikir

From what i understood, he says that it was the update4 that caused the slowdown for him.

@Tomcat

It's possible you may not. I haven't put the A1 into Linux in a while now, but while overall network speed is improved a good amount (over past os4 pre-releases), it's still slower than my other systems (Linux/*nix).

Not helping matters, it seems there's some sort of issue with IBrowseNetwork..which may be adding to it.

Network speeds have increased for me, but it would seem there may be room for additional improvement there. It may be the network stack itself or the ethernet driver...unsure who owns which of those..either way, network throughput has improved with ud4, which is certainly welcome.

_________________
Are we not done with the same silly arguments and flames yet??!

@Tomcat

And I *finally* got full speed here so I thought that this was solved once and for all.

Have you tried without the router?

OK, i have checked with OS4, both update and new installation.
And tested with IBrowse and latest AWeb for OS4.
And no DSL2000-speed....
Tomcat

_________________
Find the Bird in the Pic!

@hotrod

No. But Linux on AmigaOne and the Laptop HAVE full DSL2000-speed with Router!

Tomcat

Last edited by Tomcat on 08-Feb-2006 at 06:16 PM.

_________________
Find the Bird in the Pic!

@Tomcat

exactly the same here it actually has become slower(!). i did the same test like i did in the older thread here:
Slow TCP/IP transfers...

here is the result with upd#4:

amigaone native ftp
-------------------

ftp> get aquaplaydemo.lha
local: aquaplaydemo.lha remote: aquaplaydemo.lha
200 PORT command successful.
150 Opening BINARY mode data connection for aquaplaydemo.lha (20003591 bytes).
226 Transfer complete.
20003591 bytes received in 224 seconds (89142 bytes/s)


as you can see in the other thread with update3 i got 177 seconds (113144 bytes/s)...
(i also re-tested with our windows machine with almost the same result as before)

i thought olsen had corrected most speed issues? any comments?

thanks and
byebye...

_________________
Michael Merkel
(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt

@Tomcat

I thought that you could give it a try since it doesn't work exactly the same without router as with router, but hey you do whatever you want

@MichaelMerkel

Quote:

MichaelMerkel wrote: @Tomcat exactly the same here it actually has become slower(!). i did the same test like i did in the older thread here: Slow TCP/IP transfers... here is the result with upd#4: amigaone native ftp ------------------- ftp> get aquaplaydemo.lha local: aquaplaydemo.lha remote: aquaplaydemo.lha 200 PORT command successful. 150 Opening BINARY mode data connection for aquaplaydemo.lha (20003591 bytes). 226 Transfer complete. 20003591 bytes received in 224 seconds (89142 bytes/s) as you can see in the other thread with update3 i got 177 seconds (113144 bytes/s)... (i also re-tested with our windows machine with almost the same result as before) i thought olsen had corrected most speed issues? any comments? thanks and byebye...

I worked on the speed issues. The testers reported that WAN performance had improved, especially in conjunction with the new "eth3com.device".

There's a new shell command in the distribution (which I hope didn't get omitted from Update #4 by accident). Testers reported that with the following settings things took a turn for the better:

roadshowcontrol save set tcp.do_timestamps 0
roadshowcontrol save set tcp.do_win_scale 0
roadshowcontrol save set tcp.mssdflt 1460
roadshowcontrol save set tcp.recvspace 65536
roadshowcontrol save set tcp.use_mssdflt_for_remote 0

You'll need to enter this once, and the settings will be saved in ENV:Roadshow and ENVARC:Roadshow. Restart the TCP/IP stack for the settings to take effect, but you can also reboot the system, of course.

These settings change the internal tuning variables for the TCP/IP stack. Exactly what they do and what to expect can be googled (search for "sysctl", the variable names and "BSD").

@MichaelMerkel

Quote:

i thought olsen had corrected most speed issues? any comments?

Repeat the test after using
RoadShowControl SET tcp.sendspace 65536
RoadShowControl SET tcp.mssdflt 1452
If it's faster that way use RoadShowControl SAVE SET ... to save the settings.

@olsen

It works! Thanks a lot!
Now it looks better: 1.818 kbit/s (DSL 2000)

Tomcat

_________________
Find the Bird in the Pic!

@Tomcat

Quote:

Tomcat wrote: @olsen It works! Thanks a lot! Now it looks better: 1.818 kbit/s (DSL 2000) Tomcat

Good. Here's some more info on what's going on with these settings, and why these are not the defaults Roadshow ships with.

"roadshowcontrol set tcp.do_timestamps 0" omits time stamp information which is otherwise transmitted with packets, and requested from the other side of the connection. Time stamps can be useful for timing transmissions and figuring out latency/delays, but if you don't need that it's just dead weight.

"roadshowcontrol set tcp.do_win_scale 0" disables a feature called "window scaling", which is used by the TCP/IP stack to adjust the sizes of the intervals in which the both sides of the connection acknowledge to each other that the data transmitted so far was OK. This is useful for larger transmission buffer sizes (> 65535 bytes) and really fast data transmission rates. On a plain old DSL link that doesn't go much faster than 10 MBit/s it's probably no help at all.

"roadshowcontrol set tcp.mssdflt 1460" has probably the largest impact on transmission speed. 1460 bytes are how much an Ethernet frame will hold (plus the header added for transmission), and the TCP/IP stack will try to build packets that make the most of this if this setting is in effect. If it's not in effect, then the packets built will not hold more than some 500 bytes, which increases the transmission overhead. The reason why the default setting is at 500 bytes is because when the TCP/IP kernel used by Roadshow was still new, not many routers in the Internet could be expected to transport packets larger than that. That was (ouch) some 10-12 years ago. Today's routers can handle more, which is why the setting helps. It would help more if Roadshow could figure out for itself how large a packet size the network can handle, but the code is a little too old for that. Sorry...

The "roadshowcontrol set tcp.use_mssdflt_for_remote 0" setting works along with the "roadshowcontrol set tcp.mssdflt 1460", and activates the larger packet size.

"roadshowcontrol set tcp.recvspace 65536" changes the size of the receive buffer for incoming packets. The default size is 8K, or 32K unless I forgot to upload the most recent bsdsocket.library in time... The larger buffer size helps because if that buffer fills up, reception may have to wait until the application receiving the data has picked up what's waiting.

And that's it in a nutshell.

@olsen

Wow... now it's faster here than in Linux or Windows (using shose settings)!

I downloaded openoffice from ftp.sunet.se using IBrowse and without any change of settings I got 1.3MB/s wich is what I get in Linux and Windows as well (50Mbit connection being slowed down by the router).

But with these settings I got 2.7MB/s still going through the router!

Without the router I get about 3.7MB/s in Linux and Windows...

It's *really* nice to see this! Thanks a lot!

Last edited by hotrod on 08-Feb-2006 at 07:45 PM.

@olsen

Quote:

I worked on the speed issues. The testers reported that WAN performance had improved, especially in conjunction with the new "eth3com.device". There's a new shell command in the distribution (which I hope didn't get omitted from Update #4 by accident). Testers reported that with the following settings things took a turn for the better:

well, here is the result with these settings:

ftp> get aquaplaydemo.lha
local: aquaplaydemo.lha remote: aquaplaydemo.lha
200 PORT command successful.
150 Opening BINARY mode data connection for aquaplaydemo.lha (20003591 bytes).
226 Transfer complete.
20003591 bytes received in 43.4 seconds (461217 bytes/s)

thanks! just perfect!

but please note this somewhere or make it a default for router/dsl/whatever users.

byebye...

_________________
Michael Merkel
(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt

People, with all your settings i now have 470kb/sec when DL from my friends FTP. Before the settings i had about 180kb/sec. This is more then double :)
My ADSL is 10/1mbit.

@MichaelMerkel

Quote:

MichaelMerkel wrote: @olsen Quote: I worked on the speed issues. The testers reported that WAN performance had improved, especially in conjunction with the new "eth3com.device". There's a new shell command in the distribution (which I hope didn't get omitted from Update #4 by accident). Testers reported that with the following settings things took a turn for the better: well, here is the result with these settings: ftp> get aquaplaydemo.lha local: aquaplaydemo.lha remote: aquaplaydemo.lha 200 PORT command successful. 150 Opening BINARY mode data connection for aquaplaydemo.lha (20003591 bytes). 226 Transfer complete. 20003591 bytes received in 43.4 seconds (461217 bytes/s) thanks! just perfect! but please note this somewhere or make it a default for router/dsl/whatever users. byebye...

Sorry, but that's dangerous. The code Roadshow is built upon does not support "path MTU detection", which would have the effect of adjusting the maximum TCP segment size (the tcp.mssdflt value) to the capabilities of the routing path. Today it's reasonably safe to assume that increasing this value beyond the default (about 500 bytes) will probably do no harm. But there may be cases in which this doesn't work and packet routing just drops dead or is seriously impaired by packet fragmentation/reassembly messages.

With the current solution you're at least left with a working connection, albeit one that isn't optimized with regard to minimize transmission overhead. Put another way: the default configuration allows you to visit amigaworld.net and ask questions in/search the forums for performance tuning hints; the "faster" configuration is not guaranteed to allow for that.

As for the other options: the only ones that really count deal with the default receive/send buffer sizes, and these default to 32K anyway.

@olsen

WOW! Now it flies with these settings!

_________________
ikir

@olsen

Quote:

It would help more if Roadshow could figure out for itself how large a packet size the network can handle, but the code is a little too old for that. Sorry...

Any idea when that bit of code will be replaced, OS4 final, 4.1, ... Or will there be a new networkstack in some future release?