ROD's new TCP/IP stack.

Shonky cables are an issue to look into as well. It’s no good having a 5V output capable of several amps if what arrives to the board is a half volt less.

The primary factor in my case wasn’t crashes, it was disc corruption, as the processor was able to run on inadequate power, but the SD card was not.
Of course, this was a Pi 1. Later, faster, multicore beasts will obviously fare differently.

The ROD Projects page has been updated with v7.01 of the new TCP/IP stack. This aims to resolve as many issues reported in this thread as possible.

Primary fixes include much faster SLAAC address acquisition and the “aligment” error with IP-address-from-hostfile. There are ram usage reductions in DHCP and Resolver.

A new installation / uninstallation process is included which should be more robust on USB-connected main drives, and should prevent installation on incompatible interfaces.

IPv6/SLAAC support can now be enabled via a tickbox in the Interfaces window.

A full changelog is included in the zip.

We are now beginning a beta phase on the next significant revision of the stack which will add support for legacy platforms and interfaces via a compatibility layer.
For example, RPCemu will become a supported platform, as will closed source interfaces like the Elesar Wifi Hat.

I really don’t see any need to spend development effort on legacy platforms and emulators.

I need to see an improvement in performance (both throughput and latency) on current hardware such as the Pi 4B. Why not look in to running the stack on idle cores?

RISC OS has nowhere to hide when it runs on the same hardware as Linux and delivers a fraction of what is capable of.

RISC OS has nowhere to hide when it runs on the same hardware as Linux and delivers a fraction of what is capable of.

<sigh>

Linux Foundation Annual turnover – about $177M (USD).

Our entire ecosystem and all of the players probably exists on less than their coffee budget.

So, you were saying?

Why not look in to running the stack on idle cores?

Somewhere in the archives on this site is a post or two where I suggested that simply because that would put RO in the same general situation as a PC where the network transfers are improved by off loading the grunt work to a processor on the NIC.

Anything that requires significant CPU and little interaction with the user is probably a candidate for offloading to another core.

Why not look in to running the stack on idle cores?

Chicken and egg ..

Lets all wait until we get someway of getting RISCOS up and running and interacting with other cores and then develop the stack.

Though I don’t disagree with the approach to offloading parts to other cores it seems to me that we should concentrate on getting functionality first, including Wifi, and then concentrate on making things faster.

In an ideal world we would do both but we aren’t exactly falling over ourselves with developers and money so a considered plan is always the best option..

NB I make no observation on the ROD and ROOL bounty situation and it’s potential impact in the above.

I fully agree. Functionality trumps speed. Is rather have slow WiFi than no WiFi.

Plus, offloading to other cores is a really bad idea until we have a solid working implementation of multiple core use (including fallback for single core devices) as an integral part of the OS.

Or, to put it another way, it shouldn’t be the job of the stack to assign code to any specific core. The OS, and only the OS, should be in charge of spreading the workload around.

We could be waiting a long time for RISC OS to embrace SMP, in the mean time the other cores are doing nothing.

The real madness is spending money on legacy platforms, people that use old machines do so to use old software and require maximum compatibility, the vast majority of them will never upgrade the OS or any part of it. As for emulators, there is no need for a full native stack in that situation, just pass the sockets and resolver APIs through to the hosts stack.

We could be waiting a long time for RISC OS to embrace SMP, in the mean time the other cores are doing nothing.

Jeffery Lee has been doing work on some of the necessary changes to gain access and use the other cores and that work has been released I believe, but there is a lot more work to be done.. But David if think you can do better I am sure the rest of the community would appreciate your programming skills for free to speed the work up! Sorry if that counts as sarcasm.

So you think the Iyonix should be ignored it runs the ‘modern’ OS 5 you know for instance, and RISC PC’s can have RO 5 as well. More important is the much larger market I suspect of the ‘legacy’ platform users then RISC OS 5 users and there seems to a fair demand for the older lagacy machine if CJE Micros sales of them are anything to go by.

As for emulators (RPCEmu), that might be our only option if the chips become 64 bit only in the future.

in the mean time the other cores are doing nothing.

Yup. But doing stuff behind the back of the OS is no way forward.

We’re already saddled with a massive pile of legacy crap (horrible VDU/keyboard interface, all that FPA guff…), so let’s not bugger up multiple cores before we even have them!

The real madness is spending money on legacy platforms

I would agree, but I rather got the impression that the perception was “RODev’s stack will suck because it doesn’t support the older whatsits”.
So now they’re answering that (noting that the news article for ROOLs stack points out the widespread use of the emulator) and you’re complaining?

As for emulators, there is no need for a full native stack in that situation

Unfortunately the current emulators are all clones of RiscPC era hardware.

I would completely agree that we need a minimalist emulator that basically acts as an ARM emulation and passes most things on to the host, rather than “pretending to be a VIDC” or “pretending to be an IIC device”.
Sadly, we have no such thing as yet.

but there is a lot more work to be done..

Indeed. One of the massive problems, as I see it, is that multiple cores are fundamentally incompatible with how the Wimp operates, so spreading work around the available cores will be difficult if existing mechanisms are to remain intact.
Take, for example, the recent discussion regarding broadcast messages. What happens if a task on a core is “busy” and not polling?
I mean, hell, there’s a whole pile of things that are not reentrant and should not/cannot/[nuclear explosion emoji] in mere service calls. Plus the OS only has one VDU state. Think about how printing works. So the leap to multiple cores is perfectly fine for specially written code, but for the OS to treat a core as a resource to use? That’s…. going to surely rank somewhere between “just no” and “aw hell no”.

So you think the Iyonix should be ignored

The fun thing about drawing lines is that everybody has their own opinion of where it should lie.
My personal feeling is that, yes, the Iyonix and earlier need to be considered obsolete (they don’t even have VFP!).

However, if one is creating an important system resource, such as a new stack, then there had better be a damn good reason why it doesn’t run on the same hardware as the OS itself.

Clearly, there is no single correct answer to that question. It depends upon context.

As for emulators (RPCEmu), that might be our only option if the chips become 64 bit only in the future.

Emulation, yes.

Emulating a RiscPC? Massive leap backwards.

Emulation, yes

Might not be the only way.

May be entirely talking out of my proverbial bxxxxxx but if we had a new 64 bit RISCOS, based on something that is already available and made to look like RISCOS, running on something that is modern and can make use of the cores then virtualise the old applications that will not run on it then isn’t that one way of moving forward.

No need to worry about doing something to make RISCOS work on other cores , we only need to worry about how we get said 64 bit… oh wait a minute theres the flaw in said plan :-) back to square one and development resource.

So you think the Iyonix should be ignored

Yes, its is 10x-20x slower compared to Raspberry Pi 2B and iMx6 based machines, and 40x-120x slower than a Pi 4B. The only reason I held on to mine so long was the fast HD interface and the removable HD backup system. It was tempting to ditch when the Pi 3B and 3B+ came out, but once Pi 4B ran RISC OS it blew those away, and its performance with a USB SATA is sufficient. Bulk data and backups are now handled over the network, which is why a new network stack with far lower write speed over NFS and SMB is less than welcome. But the real killer is the abysmal performance with VNC, which I use for remote access to the RISC OS machines most of the time.

ROD’s stack is BSD based, but FreeBSD seems runs on the Pi 4B with decent networking speed, and as far as I know none of the Raspberry Pi foundation’s money has funded that.

I would completely agree that we need a minimalist emulator that basically acts as an ARM emulation and passes most things on to the host, rather than “pretending to be a VIDC” or “pretending to be an IIC device”.
Sadly, we have no such thing as yet.

Don’t we? What about the RISC OS Linux port? Doesn’t that qualify?

I agree with the notion that ancient stuff like the Iyonix and anything beforehand should be dropped immediately. The existing builds of RISC OS 5 work on those, so leave it there. Newer versions of RISC OS 5 do not need to do so. Anyone wanting to use old hardware is doing so for the retro experience, and that includes the OS.

Posting this as “Andrew” rather than ROD as it isn’t intended as an official statement…

The work to support RiscPCs turned out to be much less than expected – mostly just a recompile and polish. We didn’t do it originally for exactly the reason Druck mentioned – it wasn’t a priority and we didn’t want to get bogged down with it for the initial release.

The larger piece of work was/is supporting unmodified, closed-source network drivers. This was necessary to support the Elesar Wifi Hat amongst others. Combined, the two developments unlock a broad range of hardware.

RPCemu uses a full OS stack, unlike VirtualRPC. There are pros/cons to this approach, but it is helpful from a development perspective as a full stack is present. We know that a number of developers make significant use of RPCemu, and thus making the new stack (with its new capabilities) available to those systems is important from a development and uptake perspective.

Any new/improved stack will offer new/improved functionality. As the past has proven, it is always a challenge to encourage developers to use new functionality (I’m personally guilty of this). If devs have to produce different versions for different platforms, they will stick to the lowest common denominator. As such, this work is important to give developers confidence to utilise the functionality offered by the new stack.

ROD’s stack is BSD based, but FreeBSD seems runs on the Pi 4B with decent networking speed, and as far as I know none of the Raspberry Pi foundation’s money has funded that.

Yeah, I am curious as to why the ROD developer switched to an OpenBSD stack when the FreeBSD is the fastest one out there.

Don’t we? What about the RISC OS Linux port? Doesn’t that qualify?

I think Rick has a version of QEMU (or similar) in mind, which is something I think Paolo was looking at.

why the ROD developer switched to an OpenBSD stack

A quick Google suggests that OpenBSD has better support for esoteric WiFi hardware.
Also… FreeBSD does, indeed, put emphasis on maximising performance.
OpenBSD, on the other hand, aims for good security.

It’s like the situation with the x86 speculative execution and the cache tricks to leak data.
You can have fast or you can have secure. Pick one.

Oops, forgot to revert from ROD’s Inet v7.01 !Boot to ROOL’s !Boot before upgrading !Boot with the daily beta. The effect is that the Internet configuration tool unexpectedly appears during the boot. It’s easy to put right, delete ROOL’s newly planted !Boot.Resources.Configure.!InetSetup v0.60 and replace it with ROD’s !Install.Boot.Resources.Configure.!InetSetup 0.60a (14-Mar-22) and reboot.

Otherwise Inet v7.01 is good here, in IPv4. The only note is that some some LAN traffic is slightly slower but it seems that might be expected with the change of method, so I’ve ignored that, mostly.

> why the ROD developer switched to an OpenBSD stack

My speculation is that it was a simpler proposition. At the start of covid I looked at the rool bounty piggybank and wondered about tackling this if I found my self with nothing else to do for a fair while. That didn’t eventuate but I did pull down the FreeBSD source and I built the kernel 32 bit on a raspi and tried pulling bits out to riscos to see just how hard that was going to be.

I get that FreeBSD is often regarded as the gold standard I used it single mindedly after Netware and before spending a decade on CentOS, but having spent a few days puddling about in its IP Sack source looking at its implementation of virtual routers & trying to work out how to sift out the minimum necessary for RISC OS I came to the conclusion that OpenBSD or NetBSD may actually be a saner place to start.

The only thing that surprised me to see that ROD had done exactly this is that the bounty stipulates FreeBSD as the donor.

The only thing that surprised me to see that ROD had done exactly this is that the bounty stipulates FreeBSD as the donor.

Well, maybe that’s why ROD’s stack is up and running already? ;)

Oh, and I noticed this in the bounty:

Note that, once completed, the new network stack will continue to use wired media and be IPv4 based.

ROD’s stack is still wired only for now, however it already supports IPv6 so things are moving in that direction too.

The bounty actually seemed a little odd to me, specifying IPv4. Are they entirely different code paths or something? Because it seemed to me (and I’m absolutely not an expert in this stuff) that updating the stack ought to bring with it IPv6 support sort of automatically by virtue of that code being present in the updated stack.

Oh, and ROOL bounty != ¹ ROD. Isn’t their stuff the result of “commercial something-or-other”?

Whatever, it exists and it works. Haven’t tried IPv6 yet (not had the time) but the stack has been running on my Pi for long enough that I’ve forgotten since when. I installed it (basically it’s a boot thing that bashes the old ROM modules and loads the new ones) and… that was it. Nothing needed tweaking, nothing needed adjusting. Everything kept on running as it had with the ancient stack.

¹ That’s <> to you BASIC guys. ;)

That’s <> to you BASIC guys. ;)

I may not be a C programmer in any useful sense, but I’m not completely unaware of the basics of C … I suspect that may be true of many, possibly most, BASIC programmers…

The bounty actually seemed a little odd to me, specifying IPv4.

I always read this as “IPv6 is not a requirement”. Everyone sane would of course not rip out IPv6 functionality from the stack, but it sure adds a lot of complexity when testing things, updating “standard” utilities etc. – so for a first step, I think it is sensible to ignore IPv6 for the moment. The bounties always specify the deliverables, and adding IPv6 capabilities would complicate things for the first stack update considerably.

It should be a moot point now, because the ROD updated stack comes with IPv6. The only problem is really that the stack update bounty was still kept open (for obscure reasons), and is now taken, ensuring duplicating work in a very manpower-restricted world. Pure madness.

Pure madness.

Madness, perhaps. But pure madness? Look around, things much crazier are happening daily. I’d give an example, but people will get miffed if I wiggle my finger at Westminster too often. ;)

and adding IPv6 capabilities would complicate things

On the other hand, I wonder if it wouldn’t ultimately cause more eventual problems kicking the can down the road?

On the other hand, I wonder if it wouldn’t ultimately cause more eventual problems kicking the can down the road?

It depends for how long it is kicked further. A few years? No problem. IPv6 domination is not exactly imminent, and I can’t see it becoming a hard requirement for the forseeable future because of so many legacy devices still in use.

And what is more, once you have a solid “updated stack” base, it is much easier to continue work in parallel on the other topics. Like Wifi. A better resolver. Porting libs. Extending ShareFS to support TCP. Update LanManFS. These things will then “just work with IPv6” once it is completed.

Like Wifi.

I think that’s coming. Sort of. (aren’t there like a dozen chips all slightly different in behaviour?)

A better resolver.

Done. It could be even better and have support for things like mDNS and SRV lookups and all the stuff that simply didn’t exist when the original spec was drawn up, but in terms of a replacement Resolver, it’s there.

Porting libs.

How many libs are likely to expect a POSIX model and thus require “work” before they’ll function under RISC OS?

Extending ShareFS to support TCP.

Not really a part of the stack. Personally, I’d open source the thing. Then maybe we could have some clients for other systems as well, not to mention making it more robust and reliable.

Update LanManFS.

Separate bounty – https://www.riscosopen.org/bounty/polls/33

These things will then “just work with IPv6” once it is completed.

If it were that easy, we’d have most of the world running on IPv6 by now…

If you have software that parses URLs, how well will it cope with something like http://[2001:db8::2:1]:80/ ? Hmm, the URL module parses, I bet it can’t cope with this. Oh, and notice Beast hasn’t tried to make it a link. It doesn’t recognise the format either.

How about making sense of an IP address (that is four times larger) like
2001:0db8:0000:0000:0000:0000:0002:0001 ?
Which could also be written as 2001:db8:0:0:0:0:2:1 or fully shortened down to just 2001:db8::2:1…

And that’s just the nomenclature of the addressing.