Roadshow for 68K -Needs your support!

[olsen]

Regarding GUI, is there a technical limitation preventing the back-porting of OS4's Internet prefs? Or were you thinking along the lines of something more work-intensive, like a full Genesis/Miami-style GUI?

I have always found your documentation to be absolutely excellent.

I do not own the rights to the OS4 internet prefs or the dialer GUI. This is the essential obstacle. Porting it may be possible, but the first stumbling block are the rights issue.

What I tried to make happen is to have a feature complete management and dialer GUI written for OS 3.x. This turned out to be too much of a challenge. Designing interactions is hard, and writing a set of programs around an interaction design is even harder on the Amiga. It still is today, it was ten years ago.

[olsen]

It is somewhat complicated, but luckily there's a great guide about it:

http://www.acc.umu.se/~patrikax/amiga/guides/AmiTCP_Install/

Now that's typical :-(  I wish I had know about this more than 10 years ago. I actually figured this out by myself, through trial & error, and while I learned something along the way, it was not a happy experience.

[olsen]

@olaf:
i understand your pov about the distribution very well, but you, a coder, also have to take how users see it into account. having released your stack a few years ago not only you would prevent the severe misuse of miami licences and in the end sell more units but could also demand more money per licence i think. i dont understand what was stopping you to do so all the time?

It was the old story: boy meets girl, boy loses girl...

Wait, it was different old story, which went like this: bottom drops out of the Amiga market, harder than usual this time, companies you did consulting work for during the last 10 years go bust, an old friend and collaborator dies of a cardiac arrest, and you find out how hard it can be to overcome a burnout.

Sometimes you eat the bear, and sometimes, well, he eats you.

contacts again?

I'm more comfortable viewing it as a stroke of prolonged bad luck and burnout.

[olsen]

Right... what's an ADSL modem again? It's like complaining about how much it sucks at ISDN, really.



Yes, join forces, put aside old difference and nickpickings, set up a working group for implementing an open and modern TCP stack for all Amiga plattforms.

The need to have one of those doesn't seem to have woken up the people capable and willing to create it yet. Call me pessimistic, but from my experience a genuine need to have a solution for an urgent problem tends to attract the people who solve it. And if that hasn't happen yet, it's because the need isn't as great as you may feel it is.

Just to be blunt, how much would be enough for you to hand out Roadshow sources?

Well, if I were free to give it away, which I am not, I wouldn't sell it. I would give it away. Not everything is just for sale. Where would be the fun in that?

I'm not looking to get rich, it just bothers me that Roadshow never made it into the hands of the people who would have found it useful, and I never got the kind of feedback for it which I would have gotten if Roadshow had been properly released.

[olsen]

I don't think there is much of a need, since amiga people are blatantly ignorant about the entire networking thing. Till the day their oh so beloved supermodern browser, be it OWB or TimberWolf, stops working that is. I'm just saying that I don't see much point in Roadshow either at this point, what does it bring to the table that one cannot do already with old AmiTCP?

I personally thought it was less of a headache to set up, and it has a couple of features which other TCP/IP stacks, owing to their age, could not bring to the table. Roadshow was the kind of software I needed myself, as I was dissatisfied with the existing offerings. Building the thing also was an interesting experience. I was curious how an Amiga TCP/IP stack worked, and watching it get faster as the code improved was rewarding all by itself.

Is it really that much better? What features are there? Will you continue to develop it, like some people here seem to think? If so, what is the road.. heh.. map?

Nothing is ever certain. I'm not going to walk away from Roadshow, and how it evolves depends upon the user feedback. If you don't know what it takes to make a better product, it probably won't become one.

In my view Hyperion are fools to think they can continue to maintain an IP stack in-house, they also have plenty of other things to worry about, like USB stack and whatnot.

Gee, you seem to have the wrong idea how OS4 is developed. While Hyperion has in-house developers working on the product, at least half of the work being done on the whole package is contributed by third party developers.

Indeed, where is the fun in that - let me rephrase the question - how much would it cost to buy out Roadshow from whoever own it, Hyperion I presume?

I own it alright. It's just that I am contractually restricted from doing with it whatever might strike my fancy. There are limits to what I can do.

What, OS4 users don't offer good enough feedback? Shocking! :roflmao:

More people can run 68k software than can run OS4. Even if each member of each groups (or sets; one being a superset of the other) were to come up with one bug report and one enhancement request each, the amount of feedback to come from OS4 users would still be very small by comparison.

[olsen]

Speaking of Amiga market wouldnt it be better create bounty to release RoadShow/68k binaries for free? No need to worry about piracy, shipping costs, CD duplication or wondering if there will be enough buyers.

Once it's free, who is going to take care of it? For free? This won't be as much fun as having some sort of carrot providing an incentive to keep pulling the cart.

[olsen]

Does this mean you didn't get the expected feedback from OS4 Roadshow version ?

I probably got just the amount of feedback to be expected. Since the number of OS4 users is smaller than the total number of users who can and would run a 68k TCP/IP stack, I did not receive as much feedback as I could have gotten.

[olsen]

Re: 68060, if the stack spends a relatively high amount of time computing checksums, a pipeline optimized checksum would be great. That same routine should run on other CPUs without issues, albeit linearly, yes?

The IP checksum calculation and verification function already is highly optimized and written in 68k assembly language (I borrowed it from NetBSD). But due to how the algorithm works, it's hard to avoid pipeline stalls altogether. It comes down to fetching one word at a time, adding it to the accumulator and checking for carry.

While the checksumming code certainly contributes to the performance, speed comes from how fast you can move data to/from the network I/O requests into/out of the TCP/IP stack's internal data structures. I'm lucky to have found one of the fastest copying routines to do this job.

[olsen]

@Olsen

I remember an article written during or near the end of Roadshow 68K development years ago. It was well written and spoke of how development process started with looking at the only available examples (AmiTCP sources?)

Do you remember the article?  Perhaps you wrote it.

It's likely that I did. I also wrote the article about the FastFileSystem reimplementation I was was responsible for.

It was a good read, I should have saved it. I remember emailing the author at the time about purchasing Roadshow 68K.  I think it was released as part of a monthly Amiga.com update or something available for club members to read.  Do you still have it?

I'd have to dig. While I never throw stuff away, it's sometimes an issue to figure out where it ended up. Currently, all my old data sits on a NAS system at home. But once you've gone beyond 28 GBytes of Amiga-related data that have accumulated over some 25 years, it becomes difficult to locate anything...

[olsen]

First of all I would like to congratulate you to your work and thank you for your decision to continue support for the 68K AMIGA line!


This sounds very interesting.
If you say the copy loop is important for the network performance.
Would you mind in the future to include a 68050 version of this routine which might be tuned to use a parallel load? We could handwrite this code for you if you are willing to include it.

Thank you for the offer, but it is likely not worth the stretch.

The tests I ran strongly suggest that memory performance trumps CPU capabilities, and that even a 40 MHz 68040 can outperform a 50 MHz 68060 if its memory interface gives it a bit more of an edge.

In 2003 Roadshow 4.205 managed to squeeze about as much out of an "Ariadne I" card as possible, and that's with a 40 MHz 68040 CPU in an A3000T. Once you get this far, the limiting factors are more with the expansion hardware than with how much faster a hand-optimized copying routine for a specific CPU may run.

[olsen]

Polish translation:
http://www.ppa.pl/os4/artykuly-cam9.php

Translation from translation:
http://translate.google.pl/translate?u=http%3A%2F%2Fwww.ppa.pl%2Fos4%2Fartykuly-cam9.php&sl=pl&tl=en&hl=&ie=UTF-8

Yes, that's the one, and it actually has my name on it. Funny how it reads back in the english translation...

And I just found the original HTML text, which I sent to Amiga, Inc. on November 23rd, 2003.

[olsen]

Olsen

I guess all things have their time. And now maybe its finally Roadshows time for the Classic Amiga crowd. The one thing I have learned being in the Amiga scene since 1988 is that the market never seems to die. It somehow stays alive. I think properly presented 68k Roadshow will be received well. Good luck. A gui is really important, i'd like to mention again

I know - the GUI issue, however, repeatedly managed to stall development work. Unless something like a miracle happens, I'd rather not rely upon having a GUI ready to ship with the product.

NOTE
*******
Nordic Global aka Holger Kruse
Miami
MiamiDX
********

  Having met Holger Kruse at many US Amiga shows over the years. I purchased Miami DX through his registration system. I NEVER received my keyfile. Holger and Nordic Global were completely non responsive to emails. I learned from other amigans at conventions that there were many people out there this happened to and Holger dissapeared.  well...

At one Amiga show in St Louis, Holger somehow appeared or something. I remember cornering him at a party and asking him why people didtn receive keyfiles or an explanation.. Well his explantion for the poor business practice was " I had all the registration software and names on my Amiga 1200hd and it died along with the drive and all the data. No backup"  I kid you not. I think thats the last Amiga show he was seen at as well.  Wild..

If the story is true to the facts, then I can perfectly understand why Holger chose to bow out. Talk about major embarrassment. How can you recover from this degree of desaster and still keep the trust of the customers who invested their money? I guess there may be more than one way to approach such a situation, but not all of them may be apparent or open at the time desaster strikes.

[olsen]

I see.
Of course for the NATAMI the 68K CPU has now access to 100MB and Gigabit Networkcards.

Then you are most likely to hit the limitations of the SANA-II architecture before the question comes up how to make the copying operations faster.

Gigabit traffic is practically unmanageable if the data has to be copied around using the CPU, for example. But this is the only option SANA-II currently offers. Also, the design of the TCP/IP stack Roadshow is built around knows not how to deal with DMA operations. Modern TCP/IP stacks cleverly mesh DMA operations with their own idea of how packets and TCP segments should be represented in their internal data structures.

Available CPU and network performance does not necessarily translate into actual TCP/IP stack performance. On OS4 Roadshow is hampered by the performance limitations imposed by its 1994 architecture, in spite of the fact that the networking hardware will do DMA just fine and the PPC CPU can push data around very quickly.

[olsen]

About the GUI and price. I think that the availability of the GUI would affect the price significantly. I mean the €10-15 for digital distribution sounds fair to me for GUIess version while the package with GUI incl. could be €25-35? (Would be more few years back...)

For now I won't bet that any GUI will be ready by the time the necessary work on preparing Roadshow 68k for release has completed. Time permitting, I'd like to see it getting out of the door as soon as possible. Who knows, maybe a GUI could follow later as an update for the project, but right now that's speculation on my part.

I'd rather see Roadshow 68k released with a decent documentation while there is still sufficient enthusiasm for the product. If you ship a product, you can update it. But if you never ship it...

[olsen]

Does RoadShow need daily caring? I mean, I is mature project which is presumably out of beta stages since many years. If you were going to develop completely new features it could be another bounty project again.

When you assume responsibility for software of your creation, you are supposed to be able to answer questions regarding its performance, its limitations and give hints on working around them. That's not counting in collecting the information required for fixing bugs or adding new features.

The first part of "caring" is in helping the product to reach its audience, and make the audience care about the product. I can understand that a bounty would neatly fit the first part of such a process. Get the thing out the door and into the hands of the users. That would cover the first act.

The second part of "caring" is the tedious bit. Now that you've slain the dragon, so to speak, the villagers will start to complain about the damage the animal did to their property and expect you, the guy who slew the dragon, to be sympathetic to their pleads. After all, you did the big thing, everybody was happy, and now you're going to get dragged back into the daily business, which is not very exciting. I can't see a bounty taking care of the bug fixes and the enhancements. It may sound neat when you think about it, but once reality settles back in, you'll find that chasing after bugs and preparing for the next iteration of the product is not as exciting and motivating as things were when you prepped for the first act of the effort. There may be a reward in the distant future, but as experience shows, that distant reward can be poisonous for software development.

I dont expect Amiga software is going to sell more than 50-100 copies in total these days... most of sales happen when product is released and then stagnate to very low numbers. In few months you have saturated entire Amiga market and it is not growing.

It is your choice of course but in my opinion with limited market bounty generates more pleasure to both users and developer.

You're talking about the software equivalent of a one-night-stand. Wham, bang, thank you ma'am. I'm not that kind of guy. If it's software, your responsibilities will last, and last longer than you may have expected when you made worst case predictions. And the best thing to make them last is to stretch out the rewards aspect of development. So, to put it into words, I do not believe in bounties to provide for a lasting development process.

[olsen]

Would you mind sharing exactly what those are?

For example multicast, does Roadshow do multicast at all?

Roadshow supports ZeroConf network interface configuration, if there's no DHCP server around, for example. The API is much richer than the original AmiTCP design, allowing you to control the operation and configuration of the TCP/IP stack through AmigaOS-like functions, with hooks and tagitem lists. Also, you have access to the inner workings of the packet and connection dispatch and can plug in filters of your own choice to implement something like ZoneAlarm for Windows. I also wrote my own PPP and PPPoE drivers from scratch, which are faster than what Miami and AmiTCP Genesis had to offer.

The SDK is quite nice. It even has sample code and a tcpdump port which uses Roadshow's built-in Berkeley socket filter.

As for multicast, Roadshow does what can be done within the limitations of the SANA-II driver framework. The number of multicast addresses to listen to is limited by the design of the S2_ADDMULTICASTADDRESS command.

I'm probably the only person in the entire Amiga community who gives a rats ass about IPv6, but I'll repeat it - IPv6 is coming, whether people like it or not, and IPv4 will in short time (in amiga terms anyways) be obsoleted. Tough luck for those who want to use any of the NG systems as some sort of main system, and those who think a clever router will solve all your problems, then please elaborate how that is supposed to happen.

 
To support IPv6 properly, a new TCP/IP stack has to be ported. There's a compatibility layer developed for the 4.4BSD stack at the University of Lausanne, which Miami would use, but I suspect its functionality is hardly adequate any more.

For the time being I reckon there's a time window of at least 2-3 years left during which too many existing IPv4 devices have to be supported to make it easy to switch to IPv6, at least as far as the common end user is concerned (business operations will be a different matter; if you're running your own BGP router in the basement you'll have to switch sooner than later). Your typical ISP will likely switch your cable modem or ADSL service concentrator to IPv4 operations and internally reroute the traffic through a 4to6 proxy.

I agree that this issue has to be addressed, eventually, I just don't see it coming around the corner just yet.

I consider any development done by anyone who signs NDA with Hyperion as in-house, it's as close to in-house they can get anyhow - I do not have any illusion of Hyperion actually having a house... heh... :laughing:

Aren't we being negative today?

 So in reality, you dont own it, and appearantly you're not pleased with that fact.

Could be worse. If I were completely free to make the software open, I could just dump the thing and leave it to its own devices. My suspicion is that it would stay largely untouched and unloved. The whole premise that once a package is open sourced great things are inevitably going to happen to it is too optimistic.

Sure, but a TCP stack? Considering that a vast majority of those running 68k software are doing so in UAE where bsdsocket.device is offered by emulator, I doubt that there really are that many.

Could be, but some funny things are possible with a 68k TCP/IP stack that runs inside the emulation rather than interfaces to the host's TCP/IP stack by means of a proxy. For example, take IPv6 support. The code that's hard-wired to WinUAE will stay AmiTCP V3 compatible until the bitter end.

No doubt, but I really don't see one single person being able to maintain an entire IP stack over time, it just isn't realistic.

Come on, this code was so mature in 1994 that it, essentially, has not changed in more than a decade since. The integration of IPv6 in FreeBSD, NetBSD and OpenBSD happened alongside the existing IPv4 support, and any major changes that went into the IPv4 code were concerned with security enhancements, bug fixes and very few functional additions, such as for T/TCP.

The last bug fix I applied to the mainline TCP/IP code came from "archeological research" in code that was at the time more than 20 years old. That was in 2007.

It's not as if you have to keep up with a boatload of code changes to keep this TCP/IP stack implementation reasonably robust and sound. One man can do it.