ROD's new TCP/IP stack.

Some discussion has already taken place, wrongly, in the ROOL bounty topic.

Bug reports should go in ROD’s ticket site.

Misc info could go here, as follows.

Just a little caveat. Take care when upgrading a ROD TPC/IP upgraded !Boot with ROOL’s daily beta.

ROD’s !InetSet 0.60a can be overwritten by ROOL’s 0.60. This will be followed by a startup error, Network configuration appears on a plain grey desktop requiring Cancel to be pressed to complete the boot. A fix is simply to reapply the TCP/IP upgrade.

It would be prudent to uninstall the ROD TCP/IP before updating !Boot.

I have just raised a bug report for the ‘Bad alignment request’ error that a couple of users have reported here or csa.networking.

I wondered at first about those reports of ‘Bad alignment request’ error might be to do with the option within the ARMX6 to enable or disable Alignment Exceptions. Not convinced, I tried it both ways and did not get an issue.

I don’t know if anyone else noticed but within the ZIP file with the new TCP/IP stack is a Debug folder with a debugger to help track down issues, simple instructions are with it and advice to supply the output file with your ticket to help identify the likely issues.

So it might be useful for those users having issues to run this per the instructions prior to raising a ticket to help track the issues.

I copied over the full !Omni app from the current nightly HardDisc4 build. The module versions were no different, though the file dates were more recent. The file dates appear to represent the build date.

I copied the !debugger file to the specified location and installed the new stack again. Same ‘Bad alignment request’ error. There is no excdump file, or anything like it, in the root of the hard drive. This might not be surprising, because what I see is an error but not a crash.

More info: it fails for me in my normal configuration of IP address from hostname – but it works OK when set to use DHCP. And it’s just collected my email and news with the new stack running.

I’ve updated the ticket accordingly.

Woohoo! I can ping6 my Linux box and get a response. The SmartHub has given the RPi an IPv6 address.

FWIW I have posted ‘get out of trouble’ instructions within the ticket system, and on the previous csa thread.

Has anyone done any benchmarks on the new stack, such as ShareFS/Sunfish/Moonfish/LanmanFS/Lanman98 file transfers, HTTP downloads with browsers or wget?

I quickly tried repeated on the release version what I did an early beta, and I’m seeing the same thing; read performance slight down, and write significantly down. But I’m not convinced the tools I’m using are giving me a true picture, and I’d like to see some real tests with a good old stopwatch.

Has anyone done any benchmarks on the new stack, such as ShareFS/Sunfish/Moonfish/LanmanFS/Lanman98 file transfers, HTTP downloads with browsers or wget?

I quickly tried repeated on the release version what I did an early beta, and I’m seeing the same thing; read performance slight down, and write significantly down.

I had noticed some apparent slowdowns.

With the new stack on the Titanium the 100Mb/s network throttle can be removed and LanMan98 2.08 is generally, but not always, faster with shares on Raspberry Pi OS. On the RPi4 and RPi400 which were OK with a gigabit LAN LanMan 2.80 is slower than before. NFS, Sunfish, to a server on a Mac also showed a slow down.

I’m not convinced the tools I’m using are giving me a true picture, and I’d like to see some real tests with a good old stopwatch.

I had got as far as thinking that a reproducible test case would be required for any formal bug report. Big files and a stopwatch, iPhone, would do that, rather than relying on my home made tests that no one else has.

The large majority of RISC OS networking here is with ShareFS and that runs at the same rates as with the ROOL stack, but does look to be more stable.

It is early days, I have just left to new stack to get on with it, simply to confirm that it is stable, and it is.

Would any slowdown be a bug or just a byproduct of doing thing ‘more properly’?

Update LanManFS 2.68 shows a similar speed drop to LanMan98, 20% to 30% -ish. LanManFS is slightly slower than LanMan98, 10% -ish.

With ref to VRPC DL – can the new Resolver / Membuf rmmodules be used?

With ref to VRPC DL ? can the new Resolver / Membuf rmmodules be used?

I very much doubt it Colin, as VRPC uses the Windows networking not RISC OS which simply passes it all over to the Windows side to sort.

Also officially their is no driver for VRPC with the new stack and don’t expect there ever will be. It’s also only intended for RO 5.24+ and currently only on the specifed ‘supported’ boards/computers.

Thanks for the reply – been running RO 5 – for what seems years with VRPC DL.

After 32bitting the Internet & Resolver – found the RO 5 Resolver seems to work just as well!

Thought it might be interesting to see if the new Resolver & MBuff modules would work :-)

The VRPC Stack/Internet module is a different case.

Rick said:

what I especially like about this new network stack is the general compatibility

It worked out of the box for me; the increased speed is excellent, thank you.

Running on a Pi4, DHCP and no overclock. !Omni, !Sargasso and !Mplayer from Packman all benefit from the speed increase. Also, an unexpected benefit was the Pi didn’t freeze up when my Ethernet PowerPlug was offline.

Has anyone done any benchmarks on the new stack

Yes, I have, for block transfers using LanMan, LanMan98 & NFS, on a Titanium and RPi3B. The speeds depend on the file sizes used.

The results have been fed back to Andrew & John. I am currently adding sequential reads/writes to the program, and will make it available when I have for others to try.

As per Martin’s post I did speed tests with his program on:

Pi1
Pi2
Pi3
Pi4
Pi400
Beagleboard
Panda board
IMx6

The results were feedback and one nasty bug which crashed the Genet stack on an overclocked Pi4 when using LanManFS 2.68 was promptly fixed.

As stated the current stack is focussed on stability and performance improvements will no doubt follow.

LanMan98 is generally quicker than LanManFS and it seems the that with block transfers the new stack performance can vary.

Hopefully the more feedback the easier it will be to identify and rectify the bottlenecks.

One final thing let’s focus on the positive in that after 25 plus years we have a new updated stack that is upgradable and surely that should be rejoiced and the minor quibles put in to context.

A quick update on the “Bad alignment request” error. This has now been reproduced, and appears to be due to the use of the keyword “default” in the netmask box in !InetSetup.

Beta versions of the stack specifically advised against this, as it was an unsupported keyword in the new stack. We did address this keyword during development, so we are investigating why that isn’t working as expected.

In the meantime, we suggest users set netmask in !InetSetup to “255.255.255.0” or “255.0.0.0” as needed (the former for 192.168. addresses and the latter for 10. address respectively). Other numerical netmask values are also OK, but you would know if you need them.

255.255.255.0” or “255.0.0.0” as needed (the former for 192.168. addresses and the latter for 10. address respectively).

CIDR addressing doesn’t absolutely require that 10.0.0.0/8 be used. It is an old style (Class A, vs. class B or class C) mask.

For home setups I would suggest that /24 (255.255.255.0) is easier.

Good news: following the instructions from the posting by RISC OS Developments above, the new stack works for me.

Bad news: I’ve had a lot of occurrences where I see an hourglass, the mouse cursor moves, NumLock toggles the LED, but nothing else works – and there is no response to Alt-Break. The only way out is a power cycle or Ctrl-Break (I hate to do the latter, but I did it once just now as an experiment for diagnosis purposes).

RasPi 3B+, RO5.29 (30-Apr-22).

If anyone else sees the same, please report here so we can exchange ideas and see if there is a repeatable way to demonstrate it.

I had it just now when I opened a TaskWindow (I use Zap), set an IPv6 address, pinged some other IPv6 stuff on my LAN here, closed the TaskWindow, and then tried to open a directory on the local SSD.

I don’t see much point in reporting something on the bug tracker unless and until we can collect together enough information to make the report useful to the developers. At that point I or we can make a concise and meaningful report.

Does it behave ok when only IPv4 is used? I suspect IPv6 has had less testing so far.

I just set an IPv6 address, opened a TaskWindow (Zap), and pinged bbc.co.uk using IPv4. Same problem when I closed the TaskWindow: hourglass, no response to Alt-Break.

It looks like I may have found a reliable way for me, but does anyone else see the same issue?

Also, it doesn’t seem to happen if I use Edit for the TaskWindows. It happens with Zap TaskWindows, but not with Edit, and it never happened to me before, so it looks like some interaction between Zap and the new stack.

If I had any idea how to ‘just set an IPv6 address’ I could have a go.
As my ISP does not support IPv6 yet, I have never bothered to try and understand it!

SLAAC didn’t work for me until just now, when I discovered that it has to be turned on in my router (BT SmartHub). It doesn’t occur quite with that name. But now SLAAC assigns an IPv6 address to the RasPi. I can then “ping6 bbc.co.uk” and it works as one might expect.

If your ISP doesn’t support IPv6, I assume it’s not BT, because they have done for quite a while now. However, maybe you can get IPv6 communication on your LAN; that is likely to depend on your router.

And it does look more and more like closing a Zap TaskWindow causes the machine to hang.

And it does look more and more like closing a Zap TaskWindow causes the machine to hang.

I tried to get a similar hang on a Titanium with RISC OS 5.24, but I couldn’t reproduce this.

My steps were as follows:

• Get an IPv6 address (SLAAC_Start, ifconfig …)
• ping IPv4 address
• ping IPv6 address
• closed TaskWindow

So it could be a combination of OS 5.29 + RPi3b + new stack…