The FULL version of Roadshow is NOW available to buy

[olsen]

@Olsen

How did you do the speed tests?

The early tests were done using the ftp command, with a FreeBSD/NetBSD server (I forget which it was; only that it was a BSD Unix) at the other end providing for the data to be downloaded. The data was downloaded to RAM: so as not to make the download speed dependent on the hard disk speed.

The later tests were done using the tcpspeed program which I believe Holger Kruse wrote. That program can be compiled both on the Amiga and the Unix/Linux system of your choice. The tcpspeed program performs long sustained read/write operations, with the remote server (I used Linux) either producing or consuming the data without storing anything on disk.

For each figure I performed the speed test several times over (3-4 times) and picked the mean value of all test results. Not exactly scientific, I grant you, but the general picture should be close enough to the truth.

For the AmiTCP tests I used a network interface configuration similar to the one I used with Roadshow. Both being based on similar TCP/IP stacks, you get better performance if you crank up the number of queued I/O requests (up to a point, after which you get no increase). For Roadshow I also increased the kernel's receive buffer to 32768 bytes (using the RoadshowControl command).

What I found during the tests is that the memory performance had the greatest effect on overall transmission speed. The A3000T had a MacroSystem WarpEngine installed, which to the best of my knowledge has a faster memory interface than the phase 5 CyberStorm Mk III 68060. It certainly shows in the tests.

It was nice to see how the transmission speed of Roadshow increased with subsequent versions. All the hard work did pay off (well, it might one day actually pay something, I hope).

What I found surprising was the huge difference in speed between Miami/Miami Deluxe using either SANA-II or MNI drivers. The Miami/Miami Deluxe SANA-II performance was surprisingly small. Knowing what it took to wring more performance out of AmiTCP/Roadshow (it's not that hard), I can only speculate that Holger must have made compromises in making SANA-II I/O operations work in Miami/Miami Deluxe. That Roadshow was faster than Miami/Miami Deluxe with MNI drivers was a nice surprise

[omgas]

Thankyou for the release of Roadshow. I made my purchase yesterday, and now doing a initial test run for comparing with my MiamiDX installation.  I dont see top speed as 1st priority, more important would be stability and memory consumption/losses over long uptimes. Also I will look closely at the network byte counter, to see if it might overflow at about 123gb, like the dx counter does  My ioblix zorro card, with its ethernet module, didnt pass a quick test with the first demo archive. A connection stalls within the first few packets. Not surprised, since the ioblix ethernet driver has been pretty buggy in the latest/last release(s), but it does work with MiamiDX. I will investigate, and try provide some useful info, if the problem persists.  Thanks again and best regards,  omgas

[smf]

I did some speedtests with mediator on my A4000 with rtl8139 incase nobody has benchmarked a "modern" nic with roadshow yet.

with tcpspeed i get 2004kB/s read and 930kB/s send.
Genesis is a little slower at reading and gets 1866 but sending is 1462kB/s
Miamidx 1213kB/s read and 640kB/s send.

I'll have to think about it for a while and test the demo some more but i think it's time for a purchase

[olsen]

Thankyou for the release of Roadshow. I made my purchase yesterday, and now doing a initial test run for comparing with my MiamiDX installation.  I dont see top speed as 1st priority, more important would be stability and memory consumption/losses over long uptimes.

I hope it does remain stable. Because it uses the 4.4BSD-Lite2 kernel code, the TCP/IP stack makes certain assumptions about how memory management works, and which side-effects it can use.

The TCP/IP stack assumes that it receives memory in page-aligned chunks (aligned to multiples of 2048 bytes). There is glue code in Roadshow which makes this happen, by allocating memory via pools and chopping it up into suitably aligned segments.

The TCP/IP stack recycles the memory it allocates, and usage figures do not drift greatly over time (you can check this with "ShowNetStatus memory"). However, the TCP/IP stack rarely returns memory to the pool once it is no longer useful. In this case the pool does not drain, and Amiga system memory usage does not decrease. My glue code tries hard to purge unused allocations, but due to fragmentation there is only so much it can do.

As far as I know this is how AmiTCP and Miami/Miami Deluxe make the TCP/IP stack memory management work, too. Except perhaps Roadshow is the only one which uses memory pools.

Funny fact: when I first tested the memory management glue code back in 1999 it worked out of the box. Performance was decent and until I attended the Amiga meeting at Karlsruhe early the following year I didn't even know that there was a serious bug in my code. At Karlsruhe I used my A3000UX and an A2024 monitor (because it was easier to lug around). The A2024 connected to the A3000UX built-in video output (rarely used these days), and the display would use chip memory, of course. A really old-school configuration

Turned out that this configuration was helpful with debugging the Roadshow memory management system. Once I had set it up, I noticed that while Roadshow was running "ants" were crawling over the screen. There was a bug in my memory management code which had the effect of trashing chip memory. I would have never found this quickly since the system setup I had at home used a Picasso IV, and chip memory was rarely used.

I fixed the bug still at Karlsruhe, and because the TCP/IP stack now used fast memory (as intended), overall performance made a great leap ahead

Also I will look closely at the network byte counter, to see if it might overflow at about 123gb, like the dx counter does

Weird... The internal read/write counters maintained by Roadshow are unsigned 64 bit integers which are not related to the SANA-II driver's built-in counter values (which are u nsigned 32 bit counters which quickly will roll over). You can display them with "ShowNetStatus interface ".

My ioblix zorro card, with its ethernet module, didnt pass a quick test with the first demo archive. A connection stalls within the first few packets. Not surprised, since the ioblix ethernet driver has been pretty buggy in the latest/last release(s), but it does work with MiamiDX. I will investigate, and try provide some useful info, if the problem persists.

I hope this isn't a persistant driver issue. I have already received a number of reports regarding one particular network driver which suggests that it is trouble...

[olsen]

I did some speedtests with mediator on my A4000 with rtl8139 incase nobody has benchmarked a "modern" nic with roadshow yet.

with tcpspeed i get 2004kB/s read and 930kB/s send.

Hm... strange send figure. It's possible that this would benefit from a little tweaking.

You could try to change the send buffer size used by the TCP/IP stack, e.g. "RoadshowControl set tcp.sendspace 32768".

Or you could check if the transmission saturates the available buffers. For example, "ShowNetStatus interface " will show the maximum numbers of read/write requests which were in use at a time. If any of these numbers is identical to the respective iprequests/writerequests settings in the interface's configuration file (in SYS:Storage/NetInterfaces or DEVS:NetInterfaces), you might want to edit the configuration file, shut down the network and start it again with the new settings. Try again until the number of requests in use is no longer identical to the respective maximum value.

In my own tests I found that the default value of 32 requests for each type gave decent performance, but since your NIC is much faster than my trusty old Ariadne, increasing the numbers might make a difference.

[catohagen]

Seems it does work on Morphos after some tweaking , quote from Morphzone.org

"OK...figured it out now ... got it working with my Pegasos II ethernet (via_rhine) *and* on my Powerbook!

Here's the catch:

The sungem_eth.device on the PB and the via_rhine_pci,device on the PB cannot be "initialized" by roadshow for some reason... so what I had to do on the powerbook to get it working was this:

open a cli and type:

online sungem_eth.device unit 0

and then double click your roadshow configi/init file in devs:netinterfaces... and voila!

I did the same thing on the Pegasos II with the via_rhinepci.device...

So, roadshow *68K DOES* work (and it's very fast) under MorphOS 3.1!! YAY!

Cheers,

Dragster
"

Thread is here :
http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=8962&forum=9

[olsen]

Seems it does work on Morphos after some tweaking , quote from Morphzone.org

"OK...figured it out now ... got it working with my Pegasos II ethernet (via_rhine) *and* on my Powerbook!

Here's the catch:

The sungem_eth.device on the PB and the via_rhine_pci,device on the PB cannot be "initialized" by roadshow for some reason... so what I had to do on the powerbook to get it working was this:

open a cli and type:

online sungem_eth.device unit 0

and then double click your roadshow configi/init file in devs:netinterfaces... and voila!

I did the same thing on the Pegasos II with the via_rhinepci.device...

So, roadshow *68K DOES* work (and it's very fast) under MorphOS 3.1!! YAY!

Cheers,

Dragster
"

Thread is here :
http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=8962&forum=9

Thank you. This is surprising behaviour for an Ethernet driver. When you open a network driver which is responsible for a specific type of hardware, the driver is supposed to take control of it immediately, or fail with an error code instead.

For example, if you opened "serial.device", you would expect that immediately after opening it, the driver would respond to I/O operations and not require an additional SDCMD_SETPARAMS command to be sent in order to coax it out of xOff mode first.

It's the same thing with Amiga network drivers, except that the situation is somewhat murky. The SANA-II documentation for network drivers does not specifically mention that a driver immediately has to take control of the hardware when it is opened. Absence of this requirement in the SANA-II documentation should not be construed as an indication that network drivers should open in "offline" mode.

All the Amiga Ethernet drivers which I know of will start in "online" mode when you succeed in opening them. Also, client software such as Envoy, which talks to the SANA-II drivers directly, expects the respective network device to be in "online" mode after opening it. This is common, established practice.

According to the SANA-II specifications, the online/offline mode has a specific use. Offline mode means that the device is taken out of service. The driver takes its hands off the wheel (so to speak), and the hardware may be used for other purposes until it is placed back into service again (which resets the operating mode of the driver, including its statistics counters). To illustrate: the original A2065 came with a set of tools which included a hardware diagnostic test. In order to run the diagnostic test, you had to take the a2065.device out of service (and unplug the Ethernet link, too), or otherwise strange things would happen.

The SANA-II developer material shipped with command-line tools for switching devices to online or offline mode. This implies that device online/offline mode is primarily subject to manual user intervention. Since network device drivers are supposed to start in online mode, this means that it's the user's responsibility alone to take it offline. A network device driver is not supposed to go offline on its own accord. At least, that's what the original standard implies. Since there is no specific method for the driver to indicate that it is no longer able to transmit or receive data (because its network link was unplugged), some drivers respond to a "carrier lost" event by behaving as if the user had manually switched them into offline mode. This gets the job done, but it's only a workaround for an unresolved SANA-II design problem

This is where things get murky, because the (ancient) slip.device/cslip.device drivers would respond to the online/offline mode change by opening/closing the respective underlying serial.device driver. In a way, the behaviour was similar to what an Ethernet device driver would have done under these circumstances . But because there was no distinction between going online/offline and a link going up/down, this "hack" was used in its place. I tried to resolve this with the SANA-IIR4 specs, which have dedicated commands for establishing a link connection or tearing it down. But this distinction did not exist in 1991, when SANA-II was designed primarily with IEEE 802.3 type devices in mind (Ethernet, ArcNet). Back then you connected these NICs via transceivers to a shared transmission medium, this being a coaxial cable. Whether or not a NIC was connected to or disconnected from this medium was indistiguishable. Hence, the Ethernet drivers were unaware of being offline or online. This changed when the modern cabling, using UTP cables with RJ45 style plugs was introduced. By the time this technology was generally available for the Amiga, nobody was around to update the SANA-II standard to take advantage of the new features the modern cabling offered.

Unless there are specific reasons why sungem_eth.device and via_rhinepci.device do not open in "online" mode, I would hope that these drivers will be updated to conform to the standard practice.

In the mean time, I will update the AddNetInterface command to support a new configuration file parameter "GOONLINE=YES" ("go online", not "goon line") which will have the effect of bringing the interface online before starting the DHCP negotiation, etc.

[smf]

@Olsen

Thank you for your suggestions. This is getting strange . let me try to explain and see if i did it right.

tcp.sendspace is set to 32768 now (don't know what it used to be) and that didnt improve the speed.

increasing the writerequests setting did help! but i have to set it to insane high numbers before the number of requests is'nt identical to the max value.
I set it to 15000 and tested tcpspeed and now i can get 1706 kB/s i had a maximum of 14067 in use then.

[catohagen]

Anyone have a devs:internet/servers config with correct samba entries to share ?

i've tried this:

netbios-ns   dgram   wait   path samba:bin/ pri=0 maxhits=3000 stack=1000 nmbd
netbios-ssn   stream   nowait   path samba:bin/ pri=0 maxhits=3000 stack=1000 smbd
swat      stream   nowait   path samba:bin/ pri=0 maxhits=3000 stack=1000 swat

i can see in snoopdos that something in my samba install runs, windows7 says it cant find remote device, its like its blocked..

samba is 68k 2.2.5, it works fine on morphos with internal netstack, i can browse the shares from a win7 machine.

are my entries above correct for roadshow ?

[olsen]

@Olsen

Thank you for your suggestions. This is getting strange . let me try to explain and see if i did it right.

tcp.sendspace is set to 32768 now (don't know what it used to be) and that didnt improve the speed.

increasing the writerequests setting did help! but i have to set it to insane high numbers before the number of requests is'nt identical to the max value.
I set it to 15000 and tested tcpspeed and now i can get 1706 kB/s i had a maximum of 14067 in use then.

Wow, 15000 requests are a bit excessive, if I may say so

This figure suggests that your system can generate data faster than it can send it. Since your NIC is attached to a Zorro III bridge, I would expect that the memory performance and the network interface itself are not the "bottleneck".

Back in the days of the Zorro II network cards, the interface between the card's built-in transmit buffer and the computer was the major speed impediment, followed by the network interface itself.

Did you check how much CPU load the exercise would generate? It's possible that the interaction between the tcpspeed program, the TCP/IP stack and the network interface saturated your CPU.

[olsen]

Anyone have a devs:internet/servers config with correct samba entries to share ?

i've tried this:

netbios-ns   dgram   wait   path samba:bin/ pri=0 maxhits=3000 stack=1000 nmbd
netbios-ssn   stream   nowait   path samba:bin/ pri=0 maxhits=3000 stack=1000 smbd
swat      stream   nowait   path samba:bin/ pri=0 maxhits=3000 stack=1000 swat

i can see in snoopdos that something in my samba install runs, windows7 says it cant find remote device, its like its blocked..

samba is 68k 2.2.5, it works fine on morphos with internal netstack, i can browse the shares from a win7 machine.

are my entries above correct for roadshow ?

You do not need to use the "path" option. It can be removed, and you may instead prefix the command names instead, e.g. samba:bin/nmbd instead of nmbd.

Did you verify with SnoopDOS (or a program like it) that the server commands are in fact loaded and launched?

Finally, did you check the log files in samba:log for information?

[catohagen]

I tried without path first and without the pri/maxhits/stack options but it was the same error from win7 (no access, its like the host doesnt exist), in snoopdos i could see samba:bin/smbd was accessed but alot of fails too, mchar fails and a few others(pchar?), i can get and post the errors when i get home from work as i cant remember...if only i got a username/password request atleast..

Also in smb.conf i use SERVER as security and my NAS ip as server, worked fine with Morphos netstack, usernames/passwords from nas works, but i'll try with USER as security..

Is there a firewall started ? i saw in sys:s there is a start-firewall and stop-firewall script but i have no idea if they are started/stopped.

I copied a 726mb ubuntu iso (http://www.youtube.com/watch?v=4FlsmCctSrg) 3-4 times to/from the morphos3.1 powerbook and my Dlink NAS(mounted with smbfs) and transfer rate was at a constant over 14MB/s to ramdisk and 7-8MB/s from ramdisk, so its very impressive(to me atleast) for a 68k emulated stack to transfer stuff faster than a 100mbit network, to get samba to work would be awesome.

[olsen]

I tried without path first and without the pri/maxhits/stack options but it was the same error from win7 (no access, its like the host doesnt exist), in snoopdos i could see samba:bin/smbd was accessed but alot of fails too, mchar fails and a few others(pchar?), i can get and post the errors when i get home from work as i cant remember...if only i got a username/password request atleast..

The mchar/pchar bit is probably due to environment variables being checked and should have no impact on the operations of the Samba server software. You might want to narrow down the operations which SnoopDOS will log. Which programs are being launched and which files are being accessed would be helpful here. The rest can wait...

If the smbd/nmbd servers are launched and nothing happens, then at least the log files should get written and (just maybe) reveal something about the issue at hand.

Also in smb.conf i use SERVER as security and my NAS ip as server, worked fine with Morphos netstack, usernames/passwords from nas works, but i'll try with USER as security..

Please don't go overboard with this. If the old configuration worked before, it should keep working with little changes. If you need to modify anything, please start with the "netbios name" parameter (and don't forget to make a backup copy of the smb.conf file first).

Is there a firewall started ? i saw in sys:s there is a start-firewall and stop-firewall script but i have no idea if they are started/stopped.

The firewall needs to be started manually. And probably has to be configured first, since the default configuration files provided are designed for a specific application, namely for turning your computer into a gateway router using PPPoE.

So, unless you started the firewall script, the firewall should not be active.

I copied a 726mb ubuntu iso (http://www.youtube.com/watch?v=4FlsmCctSrg) 3-4 times to/from the morphos3.1 powerbook and my Dlink NAS(mounted with smbfs) and transfer rate was at a constant over 14MB/s to ramdisk and 7-8MB/s from ramdisk, so its very impressive(to me atleast) for a 68k emulated stack to transfer stuff faster than a 100mbit network, to get samba to work would be awesome.

Yes, these figures don't look bad at all

How do they compare to the native TCP/IP stack?

[catohagen]

The mchar/pchar bit is probably due to environment variables being checked and should have no impact on the operations of the Samba server software. You might want to narrow down the operations which SnoopDOS will log. Which programs are being launched and which files are being accessed would be helpful here. The rest can wait...

If the smbd/nmbd servers are launched and nothing happens, then at least the log files should get written and (just maybe) reveal something about the issue at hand.



Please don't go overboard with this. If the old configuration worked before, it should keep working with little changes. If you need to modify anything, please start with the "netbios name" parameter (and don't forget to make a backup copy of the smb.conf file first).



The firewall needs to be started manually. And probably has to be configured first, since the default configuration files provided are designed for a specific application, namely for turning your computer into a gateway router using PPPoE.

So, unless you started the firewall script, the firewall should not be active.



Yes, these figures don't look bad at all

How do they compare to the native TCP/IP stack?

I'll try later and see if I can get some snoopdos clues about the servers and starting up..

The Morphos native tcp stack isnt as fast as Roadshow(in my experience), if i remember correctly i get half decent transfer rate from shell(using buffer), but in the 7-8 MB/s <-> 10-12MB/s but with alot of up and downs, you see spikes(in the graph as in the yt video) down to almost zero, up to 8MB/s down to 200KB/s up to 10MB/s and so on, this might be due to lack of tcp window scaling, the Morphos developer doing the tcp/ip stack for Morphos have updated to a newer FreeBSD tcp/ip stack in his port and should have window scaling and perform better(comes with MorphOS 3.2), but as of now Roadshow chews through bytes almost twice as fast as the native one and browsing is significantly more responsive and loads pages way quicker...

[catohagen]

edited away logs posted, as stuff started working

[catohagen]

oh, wait.....it works...i removed nowait from sys:devs/internet/servers...on smbs and swat line


and it works well, I copied the same 700mb ubuntu iso, from a samba share on the Powerbook, and transfer speed to the win7 pc was around constant 23MB/s....after picking up my jaw, i tried one more time and whipped out
my phone again, http://www.youtube.com/watch?v=vsUZh4TD2io (copying the same file back to Morphos share was around 4-5MB/s )

But i wonder,

When copy from a smbfs mounted NAS drive ----> the Morphos powerbook, the transfer speed where around 14MB/s (Morphos is writing to ramdisk)   *GOOD*
When copy from Morphos ramdisk -------> the smbfs mounted NAS drive, transfer speed where  7-8MB/s (Morphos is reading from ramdisk)               *NOT SO GOOD*

install samba server on morphos, and..

Copy from a Morphos share -----> PC desktop folder , the transfer speed where around 23MB/s (Morphos is reading from harddisk)     *GOOD*
Copy from PC desktop folder -----> Morphos share, the transfer speed where around 4-5MB/s (Morphos is writing to harddisk)          *NOT SO GOOD*

so to keep a good transfer rate at file copy operations you need to mix the best scenario of smbfs and samba..(unless settings can be tweaked to better performance)

anyway....its was a well spent 25 EURO for me