Roadshow for 68K -Needs your support!

[olsen]

About the missing GUI, I would happily use the stack without, provided basic documentation for the configuration files is present. (I am sure they will be).

The documentation for the OS4 Roadshow is in decent shape, but I think I should do better.

Regarding the distribution media, personally I would prefer a download. However, with this method I can foresee some users asking you for a re-download later on though.

That calls for a certain, more refined infrastructure, and registration. Without the registration, there would be no re-downloads, of course.

Provided that NAT functionality is possible, 50 euro would not make me think twice, but I agree with other post'ers, that a low price certainly may invite to buy.

Well... 50€ is likely far too much for what Roadshow offers right now. The NAT is part of the IP filter package. It works, but it requires a certain amount of preparation and understanding to get it going. Sample scripts are provided for setting up the filter and the NAT. I've successfully used my A3000UX as a firewall/gateway for the rest of my wired LAN.

For the support load on the author, I would like to point tothe, in my view, back then, very well working solution which the MiamiDx author used, the MiamiDx mailing list, where users helped users. Perhaps this, the idea of users helping users being the base support method, could possibly leave you in a more relaxed position.

You'd have to have a dedicated forum for that. Hm... I have little experience with setting something like that up. Any suggestions?

I still have a system running 24/7/365, with uptimes passing the 200 days mark, and would still very much like to try out Roadshow as the main router for my lan, for an interesting comparison to MiamiDx in the same setup.

That may indeed turn out to be very interesting. I do not recall running Roadshow for such prolonged periods of time. AmigaOS is a single user, desktop operating system after all, isn't it? I rarely left my Amiga turned on for more than 24 hours. The cooling fans and the SCSI disk drive are just too loud.

A side note; I feel you should have semi-included AmigaNOS in your list of tcp/ip implementations, however I know that it is mainly for radio amateur use and not for use by the masses. I used it with an AX25 modem on my A1000, and it was great fun improving functionality and make it compile on latest sas/c version.

I'm sorry, AmigaNOS did not come to my mind. I never used it, but I darkly remember that it had been around for a long time while the Amiga TCP/IP solutions were just taking baby steps.

Oh My God, Another Stack

And I thought it was full of stars ;-)

[olsen]

In case you are interested, here are some speed test figures, which can also be found in the http://eab.abime.net/showthread.php?t=54698 thread. I just finished the A1200HD and A600HD tests, so let's have a look:

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

As you can see, Roadshow goes about as fast as the 10 MBit/s Ethernet hardware will permit. None of the alternatives (Miami, AmiTCP) come as close to the hardware limit as Roadshow does.

Now for the downer:

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

As you can see, the A600HD is about as fast as molasses going up a hill in January, on crutches. But it shows that the stack works under low memory conditions on the lowest of the low end configurations. This is barely faster than sneakernet...

[olsen]

@Olaf

Very nice results. I see that an EAB topic is a bit more technical I wonder how many KB/s i can get using my 3com pcmcia lan card.

btw. How about making a new driver specification (SANA3) for all amigalike systems?.

The word is "difficult", not just "challenging".

Morphos and OS4 have already drivers for 1 gbit NICs so i it could be useful.

I do not know about MorphOS, but OS4 uses the SANA-II driver architecture, and it has no support for DMA-assisted network data transfer which severely hampers its performance with gigabit NICs. This is still an unsolved problem, due to the state of the SANA-II standardization.

[olsen]

Great results on pcmcia! I get those speeds (and often lower) on my A1200 w 060@80 via MiamiDX!

Do you get these speeds with a PCMCIA networking interface, or do you use something else?

[olsen]

Wow, that's at least 30% faster than my PCMCIA NIC with a 68040 / AmiTCP

Hm... I had no idea how far the performance range actually goes. So this is better than I could hope to expect.

It also suggests that the actual performance of the CPU is less of a factor here. I suspect that the PCMCIA interface may be what is limiting overall performance in this area.

[olsen]

Was the ariadne II you have fixed to run full duplex?

I have no idea. The test setup I ran back then (in 2003; these are older test figures) probably did not benefit from full duplex operations. The tests exercised data reception, in the LAN, over a prolonged period of time: the Amiga received data, the ftp server on the other end of the connection just pumped it to the Amiga. In this scenario the receiver just sends ACK responses for every few KBytes of data received correctly. There is not enough I/O overlap to make full duplex operations contribute significant performance improvements over a half duplex card, such as the Ariadne I. As you may see among the performance figures I posted, the Ariadne I did significantly better than the Ariadne II.

i recall back in the day contacting villagetronic about this on mine.Seems there were bugs with some thatcould use a hardware fix?

I also remember that the hardware had issues with the full duplex operations, and that this was not something that could be corrected just in software.

[olsen]

Olsen
Thanks for the speed comparisons very interesting and good illustration of Roadshow speed. Can i ask you again why it is that you decide to release this NOW instead of back in 2003 when everyone was trying to get you to? Before the last of the amigans jumped ship?

The short answer is: because I burnt out. I was originally trying to get Roadshow released with the publisher providing a GUI, and me contributing the TCP/IP stack, the drivers, tools, SDK, etc. The first attempt collapsed as the Amiga market collapsed. The second attempt stalled until it became really painful to continue. The third attempt collapsed because I was, as I now see it in retrospect, burn out already.

I blame myself for trying too hard to do too much for a long time. It wasn't just that I was trying to get Roadshow off the ground, I also juggled university, my own company, the OS4 development work and a handful of other things that needed attention. This will go down well (for some definitions of "well") as long as your energy and constitution permit, but you're actually living on borrowed time, so to speak.

So, all of this had to come to a stop at some point. And I've just crawled out of from whatever stone I was hiding under to see if there was still enough fun left in me and the Amiga community for another round of doing what I believe I do best...

[olsen]

Hello,

@olsen

for your question about ideas for setting up support, for me personally
having a user2user mailinglist would be just fine. Perhaps the web
Google Groups service could be used. Maybe someone here knows
if it is possible to use this in a moderated mode, and if
this suits the intended use at all.

A searchable archive of notes would be nice to have, and probably a Wiki, too. I'm still looking at the options, and the cost involved. If this turns out to be affordable, it won't affect the price of the stack, I hope. Now that everybody seems to suggest that going beyond 25€ would not be a good idea, this is probably what the upper end of the scale must look like.

Thankyou for the speed tests on base hardware. Networking easily wins
over sneakernet for moving larger files, and convenience often wins
over any speed limitations there might be.

I was asked, over at eab.abime.net, how today's most commonly used configurations would fare, and I promised to look into providing the figures by this weekend. This turned out to be an interesting exercise all by itself, before I even managed to run the tests. Looking for the NIC, the power supply, the mouse, the video cable, etc. I discovered stuff I thought I had lost years ago, and I also found and fixed two bugs in Roadshow and the PPP drivers as well.

Also I cant wait to try your stack on my A1000/68010 A590/acard/CF/2MB
RX500/1MB Zorro/A2065 setup. Here a GUI-less stack with a relatively
low memory footprint would be very useful.

Roadshow works surprisingly well on a configuration like that. The hardest part of testing on the A600 was in sitting down, cross-legged, in front of the TV and typing on that tiny keyboard. My back still aches, just thinking back to it.

Btw, for those having a network interface on many systems, and wanting
to run more than one system at the same time, perhaps you could share
your thoughts on this? I feel that complicated license terms tends to
put people off, personally however, I would not mind having some kind
of site license option.

The original plan was to let you install and use your copy of Roadshow on up to two machines without your conscience bothering you. If you wanted to use it on more than this number of machines, then, scout's honour, you should have chipped in for another copy of the package.

[olsen]

Just want to toss in some numbers from a slightly different world, using wget to download a 88,616,960 bytes file from a webserver on same LAN, over IPv6 (for what it's worth), to /dev/null - all machines running Linux 2.6.30:

A1200, Blizzard 1230IV 50MHz 68030, Micronik-ZII, A2065: 169 s, ~512 KB/s
A1200, Blizzard 1260, 50MHz 68060, N2000 PCMCIA: 95s, ~910 KB/s
Macintosh Quadra 610, 25MHz 68040: 94s, ~920 KB/sec

I recently moved 3 TBytes in thirty seconds when I replaced the two drives in my NAS ;-)

But seriously, you see what kind of hardware the A2065 is. This is the oldest kind of networking gear for the Amiga you might find that still works. Curiously, the Ariadne I uses an AMD clone of the same chip that's in the A2065 (the A2065 uses the original CMOS LANCE chip, if I remember correctly), but it runs so much faster. The original Amiga a2065.device is also known not to be the fastest design, although your test didn't use it.

The NE2000 PCMCIA NIC test suggests that the CPU and memory performance does have a significant impact on the NIC performance after all. I was skeptical about that, but the somewhat disappointing performance of an NE2000 PCMCIA card in the plain vanilla 68EC020 A1200 (480 KByte/s) speaks for itself, if you can get almost 910 KByte/s out of the same type of hardware.

[olsen]

Olsen

thanks for your response. I understand what you mean by burnt out. After my time with Genesi I couldnt even turn on my peg...  glad you are back.

Thank you. I always thought that it would never happen to me that way, but you get burned more easily than you might think.

It's never a good idea to read up on ailments (because, as even Mark Twain noted, all the symptoms you read about always match your symptoms, regardless of what you're reading, even it's about the bubonic plague), but I was surprised that the description of burnout symptoms I eventually stumbled upon matched what I was going through. Understanding what kind of monkey's sitting on your back tends to be helpful for recovery.

Enjoy the amiga community its still alive!

The community was always the best thing about the Amiga...

[olsen]

How did you manage that ? Faster than any HD's i've ever heard of.

Easy: turn off NAS device, take two old drives out of the NAS device, remove old drives from their clips, put two new drives into the clips, put new drives into the NAS device. Easiest hardware upgrade I ever did. Note tongue in cheek in diagram A above ;-)

Seriously, if you want to move a lot of data quickly, pushing it down an Internet connection is not necessarily the way to go unless you have major bandwidth to spare. It can be much more cost efficient to just put it on a disk of sufficient size and move it physically yourself, or by hiring a courier service.

This is how, for example, some of the post production work was done in the "Lord of the Rings" films, in London. They put the data on an iPod and somebody carried it to where it was needed.

[olsen]

Any news on Roadshow?  I'm about to get my A1200 networked so a decent TCP/IP stack would be very useful right now

Thank you for asking

I am still in the process of squashing one of the known bugs, namely the DHCP client code not working correctly with certain cable modems and whatnot. One thing led to another, and while the DHCP support now works where it previously did not, this uncovered related problems that did not show up because the DHCP client code previously did not work as intended. It's bug fixes and more bug fixes... Which I believe is a good thing. A number of necessary changes, and code reviews did not happen in the past couple of years. I am just catching up

My current plan is to look over the documentation during the weekend of September 18/19 and figure out what needs to be updated or added to. To be followed by putting a distribution disk together, and writing/testing an installer script.

The software is (basically) ready, has been for years, it's just that I never went the extra mile to mold it into something you could install

[olsen]

Olsen

Ok. Good news. Flawless DHCP is very important.

But surprisingly hard to implement. My original DHCP client code was written according to the relevant RFCs current in 2001/2002, and I tested it with the ISC reference implementation. Further tweaks were made as I upgraded my home network over the years, and following reports from the OS4 beta testers. This was not enough, though

Today's DHCP servers, as found in embedded systems, or as part of dedicated server hardware, are an odd bunch. Some expect you to carry information in the DHCP requests which according to the documentation is not even mandatory, and duplicates the information already provided in the basic BOOTP packet. Some refuse to respond to your DHCP requests unless these requests are at least 300 bytes in size. Some respond with more data than your client code stated it can handle.

These discoveries prompted a slew of changes...

 Also a good installer. And last but not least as I said before take the time and do a gui for the stack. In amigaworld this is important. Just look up countless gui threads..

I hear you. The GUI issue is still unresolved. I am not going to put any work into writing one, as I have been there and it contributed to the excessive delay in getting the product published.

I did get an interesting offer in the last two weeks which may help to resolve the GUI issue. But in the mean time, I'd rather get Roadshow "finished" as far as is this may be possible, and prepare it for a GUI-less release. I really cannot tell how long it would take to make a proper GUI for Roadshow, if that would come to pass in the first place. So it's (for now) a decision of shipping Roadshow, or not to ship it at all.

the last thing anyone wants to do after spending $30=$40 on a tcp stack is manual configs

Some assembly will always be required. And the absensence of a GUI would have to affect the price. I don't expect Roadshow to sell in the $30+ range without a GUI.

[olsen]

What wouldn't be more natural than a GUI made with gtlayout?

I would have to spend time debugging gtlayout.library first As nice as gtlayout.library was for its time, building a Roadshow GUI from it would probably delay the creation of the GUI even further.

Whatever happens next, it probably won't be using gtlayout.library for development.

[olsen]

This illustrates a small problem with the notion of "be liberal in what you accept, and conservative in what you send."  I have seen many network services which completely ignore the second part and absolutely demand the first, irrespective of the consequences.

I suspect that the design of the DHCP protocol contributed to the odd client and server behaviour. The purpose of DHCP is to allow a client to learn about the network it is part of, and to share network resources without interfering with other clients. To this end DHCP makes sure that the exchange of information between clients and servers is well-defined and produces results: either the client gets what it wants, or it can be certain that no requested information will be forthcoming.

That's the plan, but there is no mechanism in DHCP to specifically help uncovering implementation errors. You have packet exchanges which say something along the lines of "here is the choice I can offer you", "this is what I want", "here is what I can give you".

But there is no packet exchange which says "I did not understand what you asked for". In place of that missing packet there is only silence. And that silence is interpreted as the complete absence of a server, which may be wrong since the server may have chosen to reject the (subjectively) malformed packet.

I remember that during OS4 testing, there were reports from cable modem users who said that they were losing their DHCP-assigned IP addresses. It turned out that the IP address leases assigned by DHCP were relatively short, and the Roadshow DHCP client correctly sent out lease extension requests, and eventually address renewal requests. Only that the DHCP server paid no attention to either, which eventually led Roadshow to stop using its assigned IP address altogether (all according to spec).

It would have been helpful to know why the DHCP server chose not to respond to the DHCP client messages. I now believe that the DHCP server found something in the packets it did not like. But as the DHCP protocol has no mechanism for notifying the client of such glitches, there was no way to figure out what was going on.

SHIP SHIP!  As for the GUI, I think leaving it without one gives the option of providing our own.  Have an officially-supported one, but not make it mandatory, that way some of us MUI-Rexx hacks or C/C++ jockeys (or E, or whatever your flavor) can make simple ones for ourselves, or even complex ones.  I am a "function over form" kind of person for the most part, so having a fast and workable TCP/IP stack is far more important to me than a pretty interface.

How the configuration files work, where they are stored, etc. is documented. Source code for all the shell tools is included, right down to the tcpdump/libpcap ports I cooked up. Anybody curious enough to start tinkering can do so with my blessings.

If you want to make a GUI, using the provided SDK material should allow you to do so.

What about a volume discount?  Seriously, I, for one, like the price notion.

Whoa! I haven't thought that far yet. Really, the imperative now is to get the thing ready to ship, and then ask the really difficult questions.

[olsen]

I'll buy just as soon as it's available!

I assume the command line would be similar to ifconfig under linux?

Um, no. I hope that they are better than that

Since the TCP/IP stack I built upon comes out of the BSD Unix heritage, the usual set of network setup/control/information commands to ship with it would include "ifconfig", "route", "arp", "netstat", "traceroute" and "ping". Of these I chose only to keep "arp", "traceroute" and "ping" and wrote Amiga-fied versions of the rest.

For example, to set up and configure interfaces and routing you would use the "AddNetInterface" and/or "ConfigureNetInterface" commands (they combine what "ifconfig" and "route" can do). To change the routing, you would use the "AddNetRoute" and "DeleteNetRoute" commands (these do what "route" could do). To obtain information about the state of the network you would use the "ShowNetStatus" and/or "GetNetStatus" commands (these do what "netstat" could do, and a bit more than that).

The point of making new commands was that, well, the originals were very terse and cryptic, and if they had been deliberately designed to make them harder to use, the designers couldn't have done a better job. I repeatedly ran afoul of the BSD "ifconfig" and "route" syntax, at which point I really had it, and I started to write Amiga-specific APIs for doing what these configuration tools would do (the "ifconfig" and "route" code itself is incredibly convoluted and crufty, too). Then I wrote new Amiga-specific commands to use these APIs.

I hope that these replacements provide better control, better error reporting and better platform-specific functionality than the original Unix commands would do. For example, you can use "GetNetStatus" (especially in script files) to test if specific aspects of the network are configured and operational; to the best of my knowledge there is no single Unix command which would provide you with this set of information.

I realize that ditching the "ifconfig", "route" and "netstat" commands may make it a bit more difficult to learn how Roadshow is set up and configured, assuming that you have prior knowledge of these Unix commands. But: to the best of my knowledge no two Unix/POSIX systems use the same syntax and switches, regarding these three commands. For example, the OpenBSD versions of "ifconfig" and "route" do not work like the Linux versions, or the Mac OS X versions, etc.

Bonus: the "traceroute" command has bugs fixed which have been around since 1987 and are still present in today's *BSD implementations of the command

Lack of GUI doesn't bother me but I can appreciate others would prefer this.

Will basic network commands (ping, traceroute etc) come with this?

Yes. "arp", "ping" and "traceroute" are included, as well as "tcpdump" and the BSD "ftp" client, and the tools that are part of Darren Reed's ip filter package. Source code for tcpdump/libpcap and the Amiga-fied shell commands is included (but not for the "ftp" client, etc. mentioned above; I didn't quite see the point since these tools are so simple).

I also ported "wget", which should become part of the shell command collection, but I'm not sure where I put the source code