caps=D @ ARM vserver ?

[Tunoac]

i2p is running at an ARM vserver, but only gets caps = PRD D == Congested is probably hard coded, because 1st arm here in the past were light headed raspberry pi's ? But now we have multi cpu ARM vserver - is the "D" still required ? How can we detect it ?

lscpu

Architecture:             aarch64                                                                                           
  CPU op-mode(s):         32-bit, 64-bit                                                                                    
  Byte Order:             Little Endian                                                                                     
CPU(s):                   6                                                                                                 
  On-line CPU(s) list:    0-5                                                                                               
Vendor ID:                ARM                                                                                               
  Model name:             Neoverse-N1                                                                                       
    Model:                1                                                                                                 
    Thread(s) per core:   1                                                                                                 
    Core(s) per cluster:  6         

I2P Version and Running Environment

I2P version:    2.5.1-0
API version:    0.9.62
Java version:   Debian 17.0.11 (OpenJDK Runtime Environment 17.0.11+9-Debian-1deb12u1)
Wrapper version:    3.5.44
Server version: 9.3.30.v20211001
Servlet version:    Jasper JSP 2.3 Engine (3.1)
JSTL version:   standard-taglib 1.2.0
Platform:   Linux aarch64 6.1.0-20-arm64
Processor:  (armv8)
JBigI status:   Locally optimized library libjbigi-linux-armv8_64.so loaded from file
GMP version:    6.2.0
JBigI version:  4
Encoding:   UTF-8
Charset:    UTF-8
Service:    false
Built:  2024-05-06 19:41:38 UTC
Built By:   idk

Thanks

[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...

[zzzi2p]

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

In 4033191c1cbbf15647a9bed8d6b9fea4f3bca6f6 to be 2.5.2-7

@eyedeekay please close this issue as resolved.