sbc-bench VS sonar

I think that the TH1520 in the Beagle-V and Lichee Pi 4A only has support for 5.10 kernel at least for access to most of the features of the SoC. If you do not mind loosing access to most features of the SoC, then you can run any kernel.

ref: https://github.com/ThomasKaiser/sbc-bench/blob/master/Result...

Nope it was with a u2c. Also I'm pretty sure the btt pi is actually faster than a pi 3b by like 30% at least going off https://github.com/ThomasKaiser/sbc-bench

I also recommend running something more intensive aside from memtest when it comes to overclocking RAM. https://github.com/ThomasKaiser/sbc-bench/issues/55

Well aside from the usual Wirth's law answer, the key is high abstraction on all levels, which brings bloat with it.

Eventually that bloat will get optimized, as that chart interestingly shows iphone responsiveness climbing with increasing years. Same with Windows, where there was a sizable abstraction jump with Vista, which then got slowly optimized over 7, 8 and 10.

There's even abstraction in memory management now, with 64 bit virtual address mapping. I've recently stumbled upon these ARM benchmarks https://github.com/ThomasKaiser/sbc-bench/blob/master/Result... and was surprised that the Pi 4 runs 10-50% slower in 64 bit mode compared to 32 bit. I'd expect there was also a notable speed decrease when going from 8 to 16 and 32 bit systems.

Not exactly what you're after, but I've contributed some benchmarks to https://github.com/ThomasKaiser/sbc-bench which you can use to compare with other arm boards.

I added some sorted table variants: https://github.com/ThomasKaiser/sbc-bench/blob/master/result...

[server] host: 0.0.0.0 port: 7125 klippy_uds_address: /home/biqu/printer_data/comms/klippy.sock [authorization] trusted_clients: 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.168.0.0/16 FE80::/10 ::1/128 cors_domains: *.lan *.local *://localhost *://localhost:* *://my.mainsail.xyz *://app.fluidd.xyz [octoprint_compat] [history] [update_manager] channel: dev refresh_interval: 168 [update_manager mainsail-config] type: git_repo primary_branch: master path: ~/mainsail-config origin: https://github.com/mainsail-crew/mainsail-config.git managed_services: klipper [update_manager mainsail] type: web channel: stable repo: mainsail-crew/mainsail path: ~/mainsail [update_manager crowsnest] type: git_repo path: ~/crowsnest origin: https://github.com/mainsail-crew/crowsnest.git install_script: tools/install.sh # Sonar update_manager entry [update_manager sonar] type: git_repo path: ~/sonar origin: https://github.com/mainsail-crew/sonar.git primary_branch: main managed_services: sonar install_script: tools/install.sh [update_manager timelapse] type: git_repo primary_branch: main path: ~/moonraker-timelapse origin: https://github.com/mainsail-crew/moonraker-timelapse.git managed_services: klipper moonraker [update_manager KlipperScreen] type: git_repo path: ~/KlipperScreen origin: https://github.com/jordanruthe/KlipperScreen.git env: ~/.KlipperScreen-env/bin/python requirements: scripts/KlipperScreen-requirements.txt install_script: scripts/KlipperScreen-install.sh managed_services: KlipperScreen

Mainsail has a daemon tool to help fix the issue after which I used seemed to make thing much better… it’s called sonar https://github.com/mainsail-crew/sonar

I actually used sonar (https://github.com/mainsail-crew/sonar) and have not been disconnected for days... Kinda a hacky way to do it, but it works.

Set up Sonar, it will keep your wifi connection active so this doesn't happen.

Sonar

Unparsed config option 'origin: https://github.com/mainsail-crew/sonar.git' detected in section [update_manager sonar]. This may be an option no longer available or could be the result of a module that failed to load. In the future this will result in a startup error.

Otherwise, you can use a tool like Sonar to keep the wifi connection alive.