The FULL version of Roadshow is NOW available to buy

[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

[catohagen]

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

[olsen]

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.

[olsen]

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.

[catohagen]

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 ?

[olsen]

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

[ChaosLord]

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!

[olsen]

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.

[catohagen]

Installed Roadshow/samba on my Macmini too, as expected it flies there aswell

this tcptest tool, is it available/downloadable somewhere ?

[danbeaver]

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

[omgas]

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!

[olsen]

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.

[olsen]

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.

[danbeaver]

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.

[Matt_H]

@ 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!

[AndreasM]

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