caps=D @ ARM vserver ? about i2p.i2p

[zzzi2p]

Thanks again for the report and helping us work through the alternatives.

In 4033191 to be 2.5.2-7

@eyedeekay please close this issue as resolved.

[zzzi2p]

You're right, ARM is hardcoded as "slow" which forced "D". I don't know a good metric to separate Pi's from servers, any ideas?

[Tunoac]

Hm, that leads to the question, why it was categorized as slow in the past. What is exactly the limiting factor ?
speed/MHz, CPU flags, number of cpu cores ? or RAM ?

I have currently hands on an older Pi 3, and a rented ARM vserver. Please let me know what techn. details could help us here.
A quick compare:

Raspberry Pi 3 Model B Plus Rev 1.3

Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 4
Model name: Cortex-A53
BogoMIPS: 38.40
Flags: fp asimd evtstrm crc32 cpuid

ARM vserver:

Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 6
Model name: Neoverse-N1
BogoMIPS: 50,00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

--> Candidate could be the aes flag ?

[zzzi2p]

The current isSlow() is roughly (see net.i2p.util.SystemVersion for source)

isSlow() = _isAndroid || _isApache || (_isArm && !_isMac) || _isGNU || _isZero || getMaxMemory() < 9610241024L || !haveJbigi

back in the day, all of those were indicators of the setup being a real dog, and the RPi 2 was the classic example, not just a slow processor but a dog JVM and dog slow I/O to the SSD card, especially writes.

Your bogomips above don't look correct to me, or may be spoofed by your VM? My RPi 2 which I still have running is reporting 698 bogomips and my other boxes range from 4000-7000 bogomips per core. On VMs you can't trust much of anything, either CPUID or /proc/cpuinfo.

Other problems are of course that there's no CPUID for ARM, and no /proc/cpuinfo for Windows.

You can see in net.i2p.util.NativeBigInteger starting at line 441 where we try to pull out of /proc/cpuinfo what type of processor we have and use that to pick the right jbigi.so to load. Perhaps we could also use that information to try to draw a line between what's slow and what's not. Or maybe combined with number of cores.

On windows all we know is isARM() and the number of cores. That's it.

[zzzi2p]

May we simply assume all Windows-on-ARM are not-slow, like we do for Mac? Seems like the Windows 10/11 requirements would be pretty high?

[Tunoac]

If we find no easy and quick way, to detect old slow arm versus new ones, e.g. Raspberry Pi 4, ARM vserver, or the new ones coming with win11:
Let the user decide, and give them an option, do override the "slow mode" on their accountability.

[zzzi2p]

OK

First of all sorry for the Windows diversion, I realized that we don't have a jbigi for ARM Windows so it will be slow anyway.

You're proposing to draw the line between (slow) Rasp. Pi 3 and (fast) Rasp. Pi 4 but that's going to be tough for the reasons above. The best I can do is assume 5 or more cores is fast, which leaves out all the Rasp. Pis but gives you what you want for your server and probably most other server-class boxes. Also marking all 32-bit ARM as slow. All Macs will stay fast even if 4 cores.

The new logic would be:

_isSlow = _isAndroid || _isApache || (_isArm && (!_is64 || _isWin || (!_isMac && getCores() < 5))) || _isGNU || _isZero || getMaxMemory() < 96*1024*1024L || !havejbigi;

How does that look?

[Tunoac]

Looks good, one remark:
Since Windows is excluded by !havejbigi at the moment already, I propose to remove _isWin condition - to be prepared if ARM@Win gets a success and we get next year a jbigi :-)

Using getCores looks future proof for me, e.g. if the next Pi generation gets more than 4 cpu, e.g. 2 performance + 4 efficient core...