Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: AndreasM on January 03, 2013, 09:46:31 AM
-
From today, the full version of the Roadshow TCP/IP stack is available to buy through the APC&TCP online store.
Roadshow is an Amiga TCP/IP stack, that allows you to connect to the Internet, to access your e-mail, web pages, chat, etc. It can also be used to access and exchange files within your local home network.
Roadshow is one of the fastest, if not THE fastest Amiga TCP/IP stacks.
Some features include:
- Amiga-ised configuration utilities rather than the terse and somewhat cryptic Unix legacy tools
- DHCP configuration for Ethernet devices
- "TCP:" device support, for use with, for example, ARexx scripts
- Enhanced & cleaned-up software development kit, that includes the complete source code to all the configuration tools and sample programs
and ... much more ...
http://roadshow.apc-tcp.de
http://www.apc-tcp.de
-
Very tempting... wish it worked on MorphOS!
-
wish it worked on MorphOS!
Have you tried if it works? I think it could work if tried. But then, is there actually anything you need over Netstack afterall?
-
the Roadshow TCP/IP stack is available to buy
Woot!
-
Roadshow is one of the fastest, if not THE fastest Amiga TCP/IP stacks.
http://roadshow.apc-tcp.de
http://www.apc-tcp.de
Hi. Good news. Do you have some statistics to back the claims of "Fastest TCP/ip stack"??
-
Have you tried if it works? I think it could work if tried. But then, is there actually anything you need over Netstack afterall?
yeah, been trying... it doesn't seem to work under MorphOS...regarding my needs, yeah.. a faster tcp/ip stack... netstack is outdated (it doesn't support tcp window scaling) and it's slow.. so slow that I use MiamiDLX on My Peg II and my PB G4 with MOS 3.1...
Cheers,
Dragster
-
Does Roadshow still come with out a GUI?
-
Made my purchase yesterday!!!
-
Hi. Good news. Do you have some statistics to back the claims of "Fastest TCP/ip stack"??
I made some speed tests during development (all 12 years of it), and also compared the results with Miami/Miami Deluxe/AmiTCP at the time:
Ariadne I, Roadshow 4.69, A3000T (040, 40 MHz)
891 KBytes/s
Ariadne II, Roadshow 4.69, A3000T (040, 40 MHz)
845 KBytes/s
A2065, Roadshow 4.69, A3000T (040, 40 MHz)
781 KBytes/s
Ariadne I, Roadshow 4.69, A3000UX (060, 50 MHz)
891 KBytes/s
Ariadne I, Miami 3.2b SANA-II, A3000UX (060, 50 MHz)
669 KBytes/s
Ariadne I, Miami 3.2b MNI, A3000UX (060, 50 MHz)
882 KBytes/s
Ariadne I, Miami Deluxe 1.0c SANA-II, A3000UX (060, 50 MHz)
633 KBytes/s
Ariadne I, Miami Deluxe 1.0c MNI, A3000UX (060, 50 MHz)
860 KBytes/s
Ariadne I, AmiTCP/IP Genesis 4.6, A3000UX (060, 50 MHz)
812 KBytes/s
Ariadne I, Roadshow 4.71, A3000UX (060, 50 MHz)
916 KBytes/s
Ariadne I, Roadshow 4.162, A3000UX (060, 50 MHz)
941 KBytes/s
Ariadne I, Roadshow 4.205, A3000T (040, 40 MHz)
977 KBytes/s
In my tests Roadshow would go about as fast as the 10 MBit/s Ethernet card would permit.
Roadshow also works with more modest system configurations:
PCMCIA NE2000 card with cnet.device 1.9, Roadshow 4.294, A1200HD (14 MHz 68EC020; 4 MBytes of fast memory)
480 KByte/s
PCMCIA NE2000 card with cnet.device 1.9, Roadshow 4.294, A600HD (7 MHz 68000; 2 MBytes of chip memory, no fast memory)
134 KByte/s
Given how slow these systems are to start with, it's probably not much of a recommendation, speed-wise, though.
-
yeah, been trying... it doesn't seem to work under MorphOS...regarding my needs, yeah.. a faster tcp/ip stack... netstack is outdated (it doesn't support tcp window scaling) and it's slow.. so slow that I use MiamiDLX on My Peg II and my PB G4 with MOS 3.1...
Does Roadshow support window scaling? But anyway it's weird that you get faster rates with Miami than Netstack. On my MorphOS machines Netstack is faster than MiamiDX or 68k AmiTCP...
-
@Olsen
How did you do the speed tests?
-
But anyway it's weird that you get faster rates with Miami than Netstack. On my MorphOS machines Netstack is faster than MiamiDX or 68k AmiTCP...
I never heard of Netstack before. Is that running native PPC code?
-
I never heard of Netstack before. Is that running native PPC code?
Yes, it's PPC native AmiTCP based stack of MorphOS.
-
Does Roadshow support window scaling? But anyway it's weird that you get faster rates with Miami than Netstack. On my MorphOS machines Netstack is faster than MiamiDX or 68k AmiTCP...
Roadshow supports window scaling, but you can turn it off if you need to. The RoadshowControl command (patterned after the Unix "sysctl" command) will do that for you.
-
@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 :)
-
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
-
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 ;)
-
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...
-
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.
-
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
-
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.
-
@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 :P i had a maximum of 14067 in use then.
-
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
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 :P 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.
-
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?
-
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.
-
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?
-
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...
-
edited away logs posted, as stuff started working
-
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 :)
-
more testing...
It seems transfer rates increases when you repeat file copying a few times, when i copied files from and to samba shared ram disk on powerbook (from win7), it went higher the second time, i recored again (http://www.youtube.com/watch?v=R7P9lIHLMNM) and you can see it starts around 20MB/s.....then 25-26MB/s....then 30-33MB/s....then after a few back and fourth transfers it stops....in a few seconds its like Roadshow is paused, it works to browse from OWB, but the filetransfer isnt going or isnt abortable, i need to reboot powerbook to get the transferwindow in win7 to go away.....it goes away when the tcp/ip stack is running again...
-
edited away logs posted, as stuff started working
The logs were useful. It was easy to see that the "nowait" keyword was the problem. I didn't realize this at first, and only later looked up at home which parameters are supported in the servers configuration file. Only "wait" is supported, and its absence has the same effect as the presence of the "nowait" keyword in the original inet.conf superserver configuration file.
-
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*
Write performance of smbfs is not very good (well, this might be a bit of an understatement). The problem here may be caused by the file system, and not necessarily be due to the TCP/IP stack itself.
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, are you writing to a volume which uses the FFS? Write performance of the FFS, unless MorphOS has tweaked this by now, is not particularly good either.
When I wrote the code, I opted to make write operations safer rather than sticking to the original FFS' much more relaxed, and faster write strategy. The problem with FFS write operations is that they are not robust at all, and should something go wrong, you'll have a damaged volume in need of repair.
The original FFS' relaxed and faster write strategy put the volume at greater risk, since more damage could be done if something went wrong before the entire write operation had concluded. The slower and safer default approach which I put into the FFS reimplementation tries to order the disk accesses in a particular way, and mops up after each individual access, so as to limit any possible damage which might occur, should something go wrong before the entire write operation has concluded.
anyway....its was a well spent 25 EURO for me :)
Cool :) I'm currently preparing an update for Roadshow, to the effect that the AddNetInterface command will no longer require taking the network device driver online separately if you want to use DHCP. I'll also add configuration files for the SunGEM and VIA-Rhine drivers.
-
Filesystem on Morphos are SFS on SSD drive, i think most of the copy operations was to ramdisk as samba share, i wrote harddisk but that might be wrong...
Any comment on the halting filetransfers ? if you saw the yt video i posted, the transfer rates increase upto 30-33MB/s and then it halts but the netstack is still up and running, would be
good to figure out whats causing this, either Roadshow is pushing stuff too fast for samba to keep up, or buffer/cache problems...as browsing with OWB is still working when it happends...
Copied stuff around several times today, and several times get a constant transferrate of 31-33MB/s and was thinking how much
does the fact that the stack is 68k code thats emulated on Morphos have to say on performance ? Would a native Roadshow PPC perform better ?
-
Filesystem on Morphos are SFS on SSD drive, i think most of the copy operations was to ramdisk as samba share, i wrote harddisk but that might be wrong...
Any comment on the halting filetransfers ? if you saw the yt video i posted, the transfer rates increase upto 30-33MB/s and then it halts but the netstack is still up and running, would be
good to figure out whats causing this, either Roadshow is pushing stuff too fast for samba to keep up, or buffer/cache problems...as browsing with OWB is still working when it happends...
Samba is very much a black box. The SMB protocol (as used by Samba and Windows file/printer sharing) sits on top of the existing TCP protocol, but SMB adds its own layer of functionality which is already perfectly covered by TCP. You can get side-effects due to two similar operations doing essentially the same job without being aware of each other.
Transmissions may stall if the receiver cannot keep up with the sender, in which case the receiver will delay acknowledging the reception of the incoming data. This in turn causes the sender to take a break. The process of recalibrating the transmission speed will repeat until the available bandwidth has been figured out. Transmission errors may have an effect on this process, too.
Copied stuff around several times today, and several times get a constant transferrate of 31-33MB/s and was thinking how much
does the fact that the stack is 68k code thats emulated on Morphos have to say on performance ? Would a native Roadshow PPC perform better ?
A PPC native Roadshow will likely do better, because the TCP/IP stack still spends a lot of time copying data from one memory buffer to another one. The copying code which Roadshow uses is the fastest 68k implementation I know of, and it doesn't seem to do too poorly in emulated form. Still, a PPC native copying routine would likely do a lot better.
Because of contractual obligations, however, I am unable to provide a PPC native variant of Roadshow for MorphOS...
-
A PPC native Roadshow will likely do better, because the TCP/IP stack still spends a lot of time copying data from one memory buffer to another one. The copying code which Roadshow uses is the fastest 68k implementation I know of, and it doesn't seem to do too poorly in emulated form. Still, a PPC native copying routine would likely do a lot better.
PPC chips are not actually very good at copying speed. So if you got any advantage from a PPC native implementation it would likely be due to other reasons.
Another way of saying it is: JITs work really really well at small loops that execute over and over again millions of times. They have a lot of trouble executing "random" code that does not run in a loop, or only executes a few times in each loop.
Because of contractual obligations, however, I am unable to provide a PPC native variant of Roadshow for MorphOS...
Google Translate version: Hyperion will sue my a$$ off! :D
-
PPC chips are not actually very good at copying speed. So if you got any advantage from a PPC native implementation it would likely be due to other reasons.
Another way of saying it is: JITs work really really well at small loops that execute over and over again millions of times. They have a lot of trouble executing "random" code that does not run in a loop, or only executes a few times in each loop.
I'd rather take my chances with a well-tuned copying routine written in either 'C' or assembly language, which does its best not cause pipeline stalls and plays to the strengths of the processor's cache. The copying code in Roadshow may do reasonably well in compiled form, but it cannot possibly compete with native code written for a specific purpose. No JIT is that good.
Google Translate version: Hyperion will sue my a$$ off!
Not necessarily yours, but possibly mine. And I'm quite attached to it.
-
Installed Roadshow/samba on my Macmini too, as expected it flies there aswell :)
this tcptest tool, is it available/downloadable somewhere ?
-
Does Roadshow still come with out a GUI?
While I believe it would benefit from a GUI, it would just bring up a selection of your installed network devices (NIC drivers.device), let you pick the one you want to use, and then deposit it in the DEVS:NetworkInterfaces directory and then reboot. The few changes in your S:User-Startup script starts the stack silently. The are new commands in your C: directory for information and control that can be run from the shell or IconX'd for use. It was so bloody seamless that I had to check that Miami was off and RoadShow was active. Heysus, it is slick and fast. No settings to memorize (it loves DHCP), "It's set it and forget it!" Well, there is no "set it," just hit install, copy one file and reboot. The download speed in cps matches OS 4.1's exactly -- funny, with less effort!?
Best 27 Euros I've spent on anything in a long while!!
-
Olsen Wrote:
>I hope it does remain stable.
Absolutely, so far, over a small 10 day'ish uptime period, I did not notice any
problems, and it seems rs handles 24/7 shoutcast streamimg much better than dx,
which means less sound interrupts or stalls by other system activities and so
far no situations where the music data stream gets all weird and choppy, what
may happen with dx during song and possibly bitrate changes. Also, I was able
to leave the launched network-using apps, do a netshutdown, and watch the rs
memory being released, in what to me looked like a very small footprint.
I wrote:
>>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.
Yesterday I tried get a more thorough overview of the issue, but with little
luck getting usefull data for a proper report. I will PM or email you more
details.
Is anyone here able to test with their ioblix for a quick functional test?
best regards,
omgas
Edit: PM sent!
-
Installed Roadshow/samba on my Macmini too, as expected it flies there aswell :)
this tcptest tool, is it available/downloadable somewhere ?
Hard to say. I picked it up (in source code form) at the time Miami Deluxe was in development. Could be that I actually received it from Holger Kruse. Anyway, if you need it (PM), I can send it to you, but you'd need to know how to build it for your system.
-
While I believe it would benefit from a GUI, it would just bring up a selection of your installed network devices (NIC drivers.device), let you pick the one you want to use, and then deposit it in the DEVS:NetworkInterfaces directory and then reboot. The few changes in your S:User-Startup script starts the stack silently. The are new commands in your C: directory for information and control that can be run from the shell or IconX'd for use. It was so bloody seamless that I had to check that Miami was off and RoadShow was active. Heysus, it is slick and fast. No settings to memorize (it loves DHCP), "It's set it and forget it!" Well, there is no "set it," just hit install, copy one file and reboot. The download speed in cps matches OS 4.1's exactly -- funny, with less effort!?
In theory, you could copy all the network interface configuration files from SYS:Storage/NetInterfaces into your DEVS:NetInterfaces drawer and just reboot.
I haven't tried this myself, mind you, but it ought to work if your Amiga network interface is connected to an Ethernet/Wi-Fi network which support DHCP address allocation.
While it would take a while for the network startup script to read each config file and invoke the C:AddNetInterface command, provided that at least one configuration works, the network should start automatically without requiring you to pick any particular configuration file.
-
Well on my A4000 I have an RTL8029 PCI card and a ASIX USB dongle on my Deneb. I switch between the two if I need to free up RAM; the USB stack eats up a lot of memory and CPU cycles.
-
@ olsen and/or Andreas
The documentation in the demo version says that Roadshow is available as a download or on CD-R. Is the CD version still planned? I'd prefer that to a download and am happy to wait a while longer for it, but if it's not happening I'll go ahead with the download version.
Thanks!
-
@ olsen and/or Andreas
The documentation in the demo version says that Roadshow is available as a download or on CD-R. Is the CD version still planned? I'd prefer that to a download and am happy to wait a while longer for it, but if it's not happening I'll go ahead with the download version.
Thanks!
No, the CD version are history.
we have planed, a long time ago, to save the Download-Archive of Roadshow on a blank CDR. The Idea was that users ,where cant go online, give a way to get Roadshow. But nobody tell us that he cant go online to download Roadshow and we stopped the idea.