any tips on settings stack settings for optimal performance?

What does it mean optimal performance?

My AmigaOne X1000 + AmigaOS has 320 Mbps and Powermac G5 Quad + MorphOS 350 Mbps.
It can be more of course, but if you need some crucial network application like web browser or smb file sharing, most of CPU power consumes the app, not network.
So to increase max NIC speed not helps much.
And my ARM BananaPro 1.2GHz dual-core has cca 300 Mbps.

Maybe we can try to modify some buffers for IP/arp/write requests in Network preferences.
If you want to test it, see System settings / Network interfaces, and TCPSpeed ( aminet ) like measuring tool.

But ideal solution will be to utilize NIC hardware acceleration and encryption engines in X1000 and X5000 CPUs ( maybe Sam460 too, SEC engine there was optional ) or in some NIC cards.
And Sam440/460, X1000 and X5000 has FPGA, it can be SEC engine too.
But all this is too complex and difficult.
Also profitable way is to utilize all cores.

I know...

sure, i'll just whip out my extra cores right now.....
well, maybe if i still had my dual core g5.
all i got is this powerbook 1.7ghz single core
what i found out is the wireless is quite crappy but maybe cause my router is 80 foot on the other side of the house
so i switched to wired and its nice but could be better
i have 1gb of ram but could double that.
does morph support 2gb? cant remember
i am using wayfarer 5.1
but have oddesey browser also

Yes, powerbook has wifi 802.11b/g - it is only 54 Mbps theoretical, but practical speed is around 20 Mbps.
The wired connection it has 1 Gbps NIC, so speed can be upto 300 Mbps, these powerbooks are powerfull ( relatively ).

MorphOS supports 2GB RAM ( minus some MBytes for OS ), so it is good idea had maximum.
I am using also both browsers: Wayfarer is perfect compatible ( thanks jacadcaps! ), but for not-so modern webpages is OWB/Odyssey faster.

I am afraid you cannot do much more.

> […] smb file sharing, most of CPU power consumes the app, not network.

This I didn't expect with file sharing. What's there beside the networking that consumes so much CPU?

> ideal solution will be to utilize NIC hardware acceleration and encryption engines
> in X1000 and X5000 CPUs ( maybe Sam460 too, SEC engine there was optional )

Are the encryption methods offered by those 10 to 15 years old hardware engines still relevant in today's networking anyway?
Another way to better network performance would be a network stack with modern features and with a new "SANA-III" interface to the driver level.

> X1000 and X5000 has FPGA, it can be SEC engine too.

Almost. X1000 and X5000 have a CPLD, which I don't think would suffice for such purpose.

> MorphOS supports 2GB RAM ( minus some MBytes for OS )

The 'minus' is not for the OS but for the address space of I/O devices. The memory consumed by the OS comes on top.

> This I didn't expect with file sharing. What's there beside the networking that consumes so
> much CPU?

Unfortunatelly CIFS or NFS protocol - they are complex CPU-hungry monsters, they are tight throat even on current X86-64 machines.
You can make lightweight sharing with local FTP or NetFS without encryption, but it not solved file sharing generally.


> Are the encryption methods offered by those 10 to 15 years old hardware engines still relevant
> in today's networking anyway?

Yes, of course. Most of inner algorithms are not changed much, main changes are in key exchange and default key length. And in the worst case TLS/SSL or IPSec devices has negotiations and fallback to most recent common protocol version.

Look on X1000 CPU PA6T-1682M features:

The first one is an encryption engine. It can do 3DES, AES, ARC4 and Kasumi
(f8) for bulk encryption, MD5, SHA-1, SHA-256 and Kasumi (f9) for signatures.
Toss in packet level encryption like IPSEC and SSL, and you have a fairly
complete crypto setup. The PA6T-1682M is not only good at slinging data
around, but it slings it around privately. It can sustain 10Gbps of bulk encryption
and potentially do 3,000 public-key handshakes a second with support from the
PA6Ts, the PPC VMX extensions help out here in no small way.

The next engine is a checksum accelerator. It can go generic CRC type
checksums or more sophisticated ones like those found in TCP/IP. With a similar
accelerator, it can do XOR calculations for RAID in hardware. Between the two
engines, they can speed up TCP/IP and RAID processing. If you use them both,
you are most of the way to iSCSI acceleration, and PA Semi gets you all the way
there. These engines together mean you can do TCP/IP at wire speeds or iSCSI
with low processor utilization.

There are two separate Ethernet controllers one for 10GbE and one for GbE.
The 10GbE controller supports two separate links which talk to the world
through a XAUI interface. The GbE controller has four links and talks to the
world through a SGMII interface. If you configure the PA6T-1682M for full
network bandwidth, you can get 24Gbps out of it either over IPv4 or IPv6.
Couple this with the offload engines, and you have a potential monster network
box on your hand.


X5000 P5020 SEC engine:
3.9.4.4 Security Engine (SEC 4.2)
The SEC 4.2 is QorIQ’s fourth generation crypto-acceleration engine. In addition to off-loading
cryptographic algorithms, the SEC 4.2 offers header and trailer processing for several established security
protocols. The SEC 4.2 includes several Descriptor Controllers (DECOs), which are updated versions of
the previous SEC crypto-channels. DECOs are responsible for header and trailer processing, and managing
context and data flow into the CHAs assigned to it for the length of an operation.
The DECOs can perform header and trailer processing, as well as single pass encryption/integrity checking
for the following security protocols:
• IPsec
• SSL/TLS
• SRTP
• IEEE Std 802.1AE™MACSec
• IEEE 802.16e WiMax MAC layer
• 3GPP RLC encryption/decryption
In prior versions of the SEC, the individual algorithm accelerators were referred to as Execution Units
(EUs). In the SEC 4.2, these are referred to as Crypto Hardware Accelerators (CHAs) to distinguish them
from prior implementations. Specific CHAs available to the DECOs are listed below.
• Advanced encryption standard unit (AESA)
• ARC four execution unit (AFHA)
• Cyclic redundancy check accelerator (CRCA)
• Data encryption standard execution unit (DESA)
• Kasumi execution unit (KFHA)
• SNOW 3 G hardware accelerator (STHA)
• Message digest execution unit (MDHA)
• Public key execution unit (PKHA)
• Random number generator (RNGB)
Depending on the security protocol and specific algorithms, the SEC 4.2’s aggregate symmetric
encryption/integrity performance is 5 Gbps, while asymmetric encryption (RSA public key) performance
is ~5,000 1024b RSA operations per second.

>> Are the encryption methods offered by those 10 to 15 years old
>> hardware engines still relevant in today's networking anyway?

> Yes, of course. [...]
> Look on X1000 CPU PA6T-1682M features: [...]
> X5000 P5020 SEC engine: [...]

Thanks. If there are open-source Linux drivers for these acceleration and encryption engines, using them as a template for MorphOS/OS4 drivers should be possible ...skills, interest and time/priorities permitting.

Quote:

Well. Having studied TCP/IP stack recently for some experiment, it is not just a matter of writing a 'driver'. It also requires to heavily modify TPC/IP stack internals to make use of those hardware accelerators.

As an example, when computing TCP or UDP packet checksum, the work can be halved between the CPU and the hardware, a part of the checksum has to be computed by the CPU (usually, the header part of the packet, a handfull of bytes) while you instruct the hardware to complete that checksum over the packet payload offloading this expensive operation from the CPU.

As you can see with this example, the TCP/IP stack has to be made aware of the capabilities of the driver for hardware accelerators features.

For a start, SANA2 network device protocol is *simply lacking* whatever is needed for that...

In my experiment, I did some CPU benchmarking to see where most of the time were spent: guess? Right in the checksum function used for TCP or UDP packet...

Computing packet checksum is in fact the first heavy CPU load of any TCP/IP stack. You compute this checksum when sending (because the remote host will do it, and if not correctly computed, will simply discard the packet)... but also when receiving data (checking that payload is ok).

TL;DR;

Modernizing our TCP/IP stack isn't just tweaking the driver.


[ Edited by Tcheko 12.05.2023 - 12:55 ]

>> If there are open-source Linux drivers for these acceleration and
>> encryption engines, using them as a template for MorphOS/OS4 drivers
>> should be possible ...skills, interest and time/priorities permitting.

> it is not just a matter of writing a 'driver'. It also requires to heavily
> modify TPC/IP stack internals to make use of those hardware accelerators.
> [...] the TCP/IP stack has to be made aware of the capabilities of the driver
> for hardware accelerators features. [...] SANA2 network device protocol is
> *simply lacking* whatever is needed for that... [...] Modernizing our TCP/IP
> stack isn't just tweaking the driver.

Thanks for the insight. You are right, of course. See also my statement regarding "network stack with modern features and with a new "SANA-III" interface" in comment #5. Seeing as NetStack is based on FreeBSD code anyway, maybe it would be best to deprecate SANA-II altogether and adopt whatever Linux/BSD world uses as interface between TCP/IP stack and hardware driver. This way, existing open-source code of TCP/IP stack and drivers could be reused more easily. But then I'm sure it's way more complicated than I as a layman can imagine :-)

just a tip:
i speed up my browser through maxing out disk caching and smart file system caching under prefs.
I even installed an nvme in my powerbook 5,7
but I didnt get the browser speed up till I maxed out caching.
the nvme sped up everything else

upgrading powerbook 5,7 to an nvme:



here is the ide adapter i used:
https://www.ebay.com/itm/374081600221

here is the nvme i bought:
https://www.newegg.com/kingspec-1tb-m-2-sata3-2280-ssd/p/0D9-000D-00136?Description=KingSpec%20M.2%202280%201TB%20SSD%20NGFF%20M.2%20SATA&cm_re=KingSpec_M.2%202280%201TB%20SSD%20NGFF%20M.2%20SATA-_-9SIB1V8FND9878-_-Product


here is the youtube video with instructions:
https://www.youtube.com/watch?v=SKQXegnzxCs&list=PLsrZeH-UfpXBLChJD2u4FodrkmF_MQJFz&index=4&t=339s

> upgrading powerbook 5,7 to an nvme:
> here is the ide adapter i used: […]
> here is the nvme i bought: […]

As far as I can see, that's SATA, not NVMe.

Quote:

See the https://wayfarer.icu/faq (How can I use a VPN for geo-blocked websites?) page on tips how to speed Wayfarer's networking up with a SSH proxy.

it operates in sata mode.
or it wouldnt work.

>>> upgrading powerbook 5,7 to an nvme:
>>> here is the ide adapter i used: […]
>>> here is the nvme i bought: […]

>> As far as I can see, that's SATA, not NVMe.

> it operates in sata mode. or it wouldnt work.

It operates in SATA mode because it can only do SATA, not NVMe. There is nothing NVMe about the adapter or the SSD.

From the adapter's description: "This product can only use M.2 ngff of sata protocol, not M.2 ngff of nvme protocol."
From the SSD's product page: "Interface M.2 SATA"

Calling any of these anything "NVMe" makes no sense.