Roadshow Update for MorphOS

[takemehomegrandma]

So what do one need the slightly improved speed for?

In many cases there is a lot more than "slightly improved" speed.

I wish there was more focus on bringing the tcp-stacks up to date, almost all of them are 20 years old in terms of features.

It so happens that "I spent some time in December to update the MorphOS NetStack (using a newer FreeBSD code base)".

This would be "the new netstack" Piru is talking about here, with an average speed of 40-45MB/s, peeking at ~50MB/s.

I hope "a newer FreeBSD code base" also means "bringing the tcp-stack up to date". We'll see in MorphOS 3.2!

[olsen]

the addnetinterface fix for bringing the device driver online still doesnt work

Ram Disk:> AddNetInterface DEVS:NetInterfaces/~(#?.info)
Interface "SunGEM" added.
Interface "SunGEM" configured, address = 192.168.0.55, network mask = 255.255.255.0.
Ram Disk:> ping google.com
ping: unknown host google.com
Ram Disk:> online sungem_eth.device unit 0
Ram Disk:> ping google.com
PING google.com (173.194.32.37): 56 data bytes
64 bytes from 173.194.32.37: icmp_seq=0 ttl=54 time=17.487 ms
64 bytes from 173.194.32.37: icmp_seq=1 ttl=54 time=17.047 ms
64 bytes from 173.194.32.37: icmp_seq=2 ttl=54 time=17.291 ms
64 bytes from 173.194.32.37: icmp_seq=3 ttl=54 time=17.105 ms
64 bytes from 173.194.32.37: icmp_seq=4 ttl=54 time=17.078 ms
64 bytes from 173.194.32.37: icmp_seq=5 ttl=54 time=16.872 ms
64 bytes from 173.194.32.37: icmp_seq=6 ttl=54 time=16.965 ms

--- google.com ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 16.872/17.120/17.487 ms
Ram Disk:> version c:AddNetInterface
AddNetInterface 4.52
Ram Disk:>

Something's wrong. I'm currently looking into it, but by the looks of it there won't be a better solution until this weekend. This is somewhat embarrassing

AddNetInterface 4.52 will bring the underlying network device driver online if DHCP is used to set up the interface's IPv4 address, routing, etc.

However, if your network interface uses a static IPv4/netmask configuration (and no DHCP), then you must add the line "state=online" to the configuration file. Otherwise, the device will not be switched into online mode and cannot send or receive data.

I'm wondering: how does your network interface configuration file look like?

[olsen]

@cato

I dont use local net for make tests, my problem is download at ridiculous speed.

How do you access the internet from your machine? Specifically, is there a gateway router (talks Ethernet to your local network, talks ATM or Carrier Ethernet with your ISP) or cable modem involved?

Some of these devices are rather simplistic. They can pass traffic between the internet and your local network, but they are not necessarily willing or able to rewrite or reshape the data traffic. This can be problematic if the TCP/IP stack used in your local network does not have certain features which were introduced in the early 1990'ies. AmiTCP and Roadshow are among these, but Roadshow has one or two features which AmiTCP lacks.

If such features are lacking, and your gateway router/cable modem is smart enough to rewrite or reshape the data traffic that passes through it, then you might still get decent data throughput, since this device can (up to a point) make up for the deficiencies of the TCP/IP stack.

But if both your TCP/IP stack and your gateway router/cable modem are unable to compensate for each other's weaknesses, then the results may be disappointing.

[olsen]

Did you guys know that "Roadshow" was supposed to be the original tcp stack for Morphos? I wont go into why it didnt happen but thats why we ended up with nutsack , er, i mean "netstack"

You are correct. This is not an urban legend.

[catohagen]

I'm wondering: how does your network interface configuration file look like?

on my macmini where I installed the update :

# $VER: SunGEM 1.1 (10.1.2013)
#
# Configuration for the MorphOS "sungem_eth.device", on Apple hardware

# The device name is mandatory
device=sungem_eth.device

# If not provided, unit number 0 will be used. You may
# have to change this if there are multiple cards of the
# same type installed in your machine, or if your network
# hardware supports several independent connections
#unit=0

# You must either pick a fixed (static) IPv4 address and
# a corresponding subnet mask, or request DHCP (dynamic)
# network address configuration.
# You can combine address/netmask/dhcp, which has the effect
# of asking the DHCP server to assign the requested IPv4
# address and subnet mask to this interface, if possible.
address=192.168.0.55
netmask=255.255.255.0
#configure=dhcp

# If no DHCP server is present in your network, you can
# use automatic interface IPv4 address assignment through
# the ZeroConf protocol. Note that this will not set up
# default route and DNS servers for you, only the interface
# address is configured.
#configure=auto

# This variant of automatic IPv4 address assignment should
# be used in a wireless network instead of 'configure=auto'
#configure=fastauto

# You can enable diagnostic messages which can be helpful in
# tracking down configuration errors.
debug=yes

# You can choose how much memory will be used when handling
# incoming and outgoing network traffic for this device.
# The default is to reserve 32 buffers of 1500 byte each, both
# inbound and outbound traffic. Larger values may provide
# better performance.
#iprequests=32
#writerequests=32

# For diagnostic and monitoring purposes it can be helpful to
# capture network traffic that flows through this interface.
# To enable this option, select one of filter=local,
# filter=ipandarp or filter=everything
#filter=local
#filter=ipandarp
#filter=everything

# This option disables a workaround required for the Ariadne
# network hardware, which, if enabled, would otherwise cause
# the interface setup procedure to take longer than really
# necessary.
requiresinitdelay=no

[olsen]

on my macmini where I installed the update :

Thank you. You are indeed using a static IPv4 address and a corresponding network mask. This will completely bypass the online switch logic which I put into the AddNetInterface 4.52 command. The online switch only kicks in if DHCP is enabled (which in your case is disabled). This should explain why you still need to use the "online" shell command.

Could you please add "state=online" (without the double-quotes, of course) to this configuration file, then enter "netshutdown" and "addnetinterface SunGEM"? The "state=online" addition should make AddNetInterface switch the "sungem_eth.device" online, as if you had used the "online" shell command before.

The change would look something like this:

-- 8< --
# Bring "sungem_eth.device" online; never omit this line, as
# "sungem_eth.device" may otherwise refuse to receive or send
# any network traffic at all.
state=online
-- 8< --

If this should do the trick, I will update the documentation, fix the sample SunGEM and VIA-Rhine configuration files, and get new archives online.

[catohagen]

adding "state=online" to Devs:NetworkInterfaces/SunGEM worked.

[kickstart]

@kickstart

downloaded a ubuntu iso in win7/chrome and got 5MB/s

on morphos macmini/owb it was 1.6MB/s
morphos wget 1.9.1 got 1.3MB/s
morphos curl 7.19.5 got 1.5MB/s

however when downloading 3 instances of the same iso, all 3 files was downloading at 1.4MB/s each

I can download the same file on the very same router

windows 7 firefox 10mb/s
morphos 20, 30, 50kb/s

[kickstart]

How do you access the internet from your machine? Specifically, is there a gateway router (talks Ethernet to your local network, talks ATM or Carrier Ethernet with your ISP) or cable modem involved?

Some of these devices are rather simplistic. They can pass traffic between the internet and your local network, but they are not necessarily willing or able to rewrite or reshape the data traffic. This can be problematic if the TCP/IP stack used in your local network does not have certain features which were introduced in the early 1990'ies. AmiTCP and Roadshow are among these, but Roadshow has one or two features which AmiTCP lacks.

If such features are lacking, and your gateway router/cable modem is smart enough to rewrite or reshape the data traffic that passes through it, then you might still get decent data throughput, since this device can (up to a point) make up for the deficiencies of the TCP/IP stack.

But if both your TCP/IP stack and your gateway router/cable modem are unable to compensate for each other's weaknesses, then the results may be disappointing.

My tests are made with the same router without any switch and speed between my pc and the morphos machine is abismal, there some more people with same problem/bug, theres a thread on morphzone with this topic and no solution at all.

[catohagen]

I can download the same file on the very same router

windows 7 firefox 10mb/s
morphos 20, 30, 50kb/s

the 20-50kb/s on Morphos would most certainly be fixed with roadshow, i have downloaded with 50kb/s myself from aminet...try the demo and download again, install doesnt touch your morphos system or settings so you can enable/disable either roadshow or internal netstack as you please.

[kickstart]

@cato

Ill try it, now im trying to make a dual boot with debian+morphos (osx is not very usefull for me)... thanks.

[J-Golden]

I know this thread is pointed at Roadshow on MorphOS, but I was wondering how well it works compared to MiamiDX?  It's what I have right now it works well enough, but if Roadshow has better handling and an easier (read understandable) setup, I'd be interested in buy and supporting the software.

I did read the description on the website BTW, but I have a mediator with a 100base-T card, not the older 10base-T.

Thanks in advance!

[olsen]

adding "state=online" to Devs:NetworkInterfaces/SunGEM worked.

Thank you. This sounds like it will be easy to fix the update archives and the rest

[catohagen]

just a quick question, i've noticed if i edit and save config files, and do a typo then log window pops up reporting an error so the stack monitors any change on the fly.

So yesterday tried with roadshowcontrol to change tcp.recv/sendspace and windowscaling on/of while downloading an ubuntu iso, to see if there was any difference, but the difference didnt happen before i've aborted the download and redownloaded.
So i made this quick little arexx script that monitors keys and put a tcp.sendspace and tcp.recvspace increase/decrease with c:RoadshowControl to better find the sweetspot,
and seemed to work, but was wondering if such a live autotuning existed already in the  stack ?

[Nicho]

I hope "a newer FreeBSD code base" also means "bringing the tcp-stack up to date". We'll see in MorphOS 3.2!

We are working on NetStack and the 3.2 release will bring some improvement compared to current MorphOS. However, do not expect miracles as it will take some time catch up after all these years...

/Nicholai

[olsen]

just a quick question, i've noticed if i edit and save config files, and do a typo then log window pops up reporting an error so the stack monitors any change on the fly.

That is correct. Except for the network interface configuration files and the text database files (services, networks, etc.) every other configuration file is tracked and reread whenever its contents change.

So yesterday tried with roadshowcontrol to change tcp.recv/sendspace and windowscaling on/of while downloading an ubuntu iso, to see if there was any difference, but the difference didnt happen before i've aborted the download and redownloaded.
So i made this quick little arexx script that monitors keys and put a tcp.sendspace and tcp.recvspace increase/decrease with c:RoadshowControl to better find the sweetspot,
and seemed to work, but was wondering if such a live autotuning existed already in the  stack ?

It exists, but I do not know the details. The TCP protocol is largely auto-calibrating, optimizing throughput according to how fast the receiver can process incoming data, how many segments have to be retransmitted, how much memory is available for assembling segments which were received out of order, etc.