sgjava

Members
  • Content Count

    226
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Everything posted by sgjava

  1. Ha, no, I don't work for Oracle. In fact, I use Zulu Open JDK https://www.azul.com/products/zulu-enterprise/jdk-comparison-matrix since it's easier to download and doesn't require an account like Oracle JDKs. I actually develop Java Periphery on a x86-64 platform and test on ARM 32/64. Zulu is a great OpenJDK implementation. I've used XenServer a lot, but OpenStack is very interesting. The main issue with RedHat is not to fall into the "Enterprise" trap which is their paid for software and services. RedHat is famous for wrapping Open Source in their GUIs and selling that to Enterprise customers. Also, since IBM took over I suspect they will continue that trend.
  2. So basically the topic drifted from Zabbix (omni monitoring tool) to Cockpit (admin tool) and you mentioning Node.js which is based on an event loop. My point was the thread vs. event loop argument was solved decades ago, but people keep reinventing event loops as more scalable. They probably didn't read the seminal research already out there. There are interesting structures like ring buffers that can scale massively and replace queues. https://lmax-exchange.github.io/disruptor. Any ways, I'm not falling into the JS/TS/Node.js trap. I'll stick with Java/Python/C/C++ as most of my work doesn't involve UI. Also, check out my https://github.com/sgjava/java-periphery library if you want to leverage userspace IO on Armbian. It uses code generation to wrap C code into a nifty Java API. Enough drifting off topic for now before Igor stops by
  3. It's funny you mention Node.js as the question of event loop vs. threads was answered back in the 70s. This paper explains it and even it is 17 years old. https://people.eecs.berkeley.edu/~brewer/papers/threads-hotos-2003.pdf Any ways, newer isn't always better.
  4. I'm really not looking at Zabbix as a development platform. It's a tool and that's what I use it for, so the underlying stack is not that interesting to me. Also, Zabbix can be served up with nginx or use PostgreSQL if that matters. Cockpit is more of an admin tool with limited monitoring (compared to Zabbix) from what I can tell and it's only for Linux. Zabbix has cross platform agents and can monitor diverse things like DBs, web endpoints, switches (or my refrigerator). Plus I'll let Zabbix fix issues for me automatically without any intervention. They are fundamentally different tools. https://www.zabbix.com/features https://www.redhat.com/sysadmin/intro-cockpit
  5. Actually Zabbix is monitoring software that collects telemetry and allows actions such as emailing, texting, restarting services or servers based on conditions and escalations. I've totally automated network admin type roles with it and things at home like monitoring the power state of my beer refrigerator in the garage. It's super flexible and easy to add stuff to the agent for client specific needs. It can also scale to millions of devices or just a handful at home. Also, the agent is now golang, not C. Cockpit looks more like Webmin on steroids. It's also Linux only from what I can tell. Zabbix is cross platform if you ever have to manage a mixed environment with Linux and Windows servers.
  6. I've used Zabbix professionally and at home to monitor servers, IoT, and IP devices. I've built scripts for the server and client to automate the install process including moving the MySQL database, so you can locate it to a NFS mount instead of serving the database from the slower SD card. The deb packages do not work for ARM, so you have to build it from source using my scripts. Install Zabbix
  7. @Igor I can verify M1 image now works, thanks!
  8. @Igor I hate when that happens. I've been stuck on something for days and weeks sometimes and it's something crazy like that. Happens to every dev.
  9. @Igor I know you probably tried this, but focal builds were work around mid-May. Can you see any deltas to your build scripts after that?
  10. I was able to get the M1 focal image to boot with local build as well. So are you still having issues with automated builds or just this one?
  11. I just created a VirtualBox VM and built NanoPi Duo and NanoPi M1 fine. Duo working fine, still need to test M1 image.
  12. @Igor I built Armbian_20.08.0-trunk_Nanopiduo_focal_current_5.4.43_minimal.img local and it boots fine. I will try Armbian_20.08.0-trunk_Nanopim1_focal_current_5.4.43_minimal.img later tonight. At least I have a work around. Sorry I cannot be more help for the automated issue.
  13. @Igor Armbian_20.05.1_Nanopiduo_focal_current_5.4.43.img same issue as M1 image.
  14. @Igor Does this happen if you build manually? If not, then I will try to build locally. I should learn how to do this any ways.
  15. Yes, I just tried Armbian_20.05.1_Nanopim1_bionic_current_5.4.43.img and it works. The Odroid C1, Odroid C2, Odroid XU4 and Nano Pi Neo Plus2 focal images work. I tested these against my Java Periphery library. but before I noticed the M1 image was hosed. When did this corruption start? Seems like around the 5/24 image time frame.
  16. @Igor I'm seeing same issue with Armbian_20.05.1_Nanopim1_focal_current_5.4.43.img. I tried a few different SD cards to make sure it wasn't that. Below is an image of the board I'm using:
  17. Thanks for getting M1 to booting! I have two of these I need to use for Zabbix Server and a web server. Yes, the C1 is picky about SD, I found a SD now that is 3x faster than the last one (thanks for all the great work): sudo hdparm -tT /dev/mmcblk0 /dev/mmcblk0: Timing cached reads: 972 MB in 2.00 seconds = 485.89 MB/sec HDIO_DRIVE_CMD(identify) failed: Invalid argument Timing buffered disk reads: 44 MB in 3.04 seconds = 14.45 MB/sec
  18. Thanks man, trying to get use out of these old boards! I also noticed Odroid C1 (same focal image) was segmentation faulting. Looks like that got cleaned up with Armbian_20.05.0-trunk.148_Odroidc1_focal_legacy_5.4.43.img. SD performance was really bad, so trying new SD with it, although that's nothing new with C1.
  19. Tested Armbian_20.05.0-rc.149_Nanopim1_focal_current_5.4.43.img and I even tried hooking up video to see what was going on and nothing. Image doesn't expand on SD. I know this isn't supported, but would be nice to have focal on my old M1s. Also, I've tried the 5/24 image and the same issue.
  20. Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around. Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report. Nano Pi Duo 13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2 15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second
  21. Looks like ARMV8 64 bit is good as well, so I can proceed to finishing up the GPIO wrapper methods.
  22. https://en.wikipedia.org/wiki/Bit_banging where you write you own protocols in software without the need for I2C, UART, SPI, etc. https://calcium3000.wordpress.com/2016/08/19/i2c-bit-banging-tutorial-part-i Thus with two GPIO pins I can simulate I2C. With the slower speeds, not so much. You can also do square wave 1 bit PCM sound too. I'm going to date myself, but I was doing this on a C64 in the 1980s. https://github.com/sgjava/garage/blob/master/commodore/c64/digisound/src/digisnd.asm Then you only need a simple piezoelectric speaker. There are probably a bunch of other uses, but this should give you an idea. Just the fact that I'm half the speed of Bulldog with many more platforms is a good thing. I was shooting for a generic high performance solution instead of coding directly to the GPIO chip like Bulldog.
  23. OK, so no answers Well as usual I pressed on. My first mistake was using JNA generation (but it was easy), so I researched JNI. Well JNI is very cumbersome to do by hand, so I looked for a JNI code generator and found one call HawtJNI. Of course it wouldn't work with Java 11 which is the Java LTS version, so I created a fork. Use the JDK11 branch if you want to play with it because I don't know if the PR will be accepted. I started wrapping c-periphery since it now supports the new /dev/gpiochip way of accessing the GPIO chips. I ran a performance test (I validated on a scope) and I'm getting ~235 KHz on a v1 Nano Pi Duo! That's over 500K writes per second compared to 2K using JNA and libgpiod. Even python-periphery yields ~37 KHz which is a pure Python version. Any ways exciting news for bit bangers of the world or anyone needing high performance GPIO. Once I have the GPIO code working I'll post on my Github site and announce. Since Bulldog only supports three boards this is good news for Armbian folks with a wider array of supported boards. I still need to test ARMv8 64 bit.
  24. After working with sysfs and libgpiod as cross platform solutions I was wondering if there was a faster way using /dev/mem or mmio? I know this gets more bare metal and SBC specific, but for some things you may want absolute speed. https://opensource.com/life/16/4/bulldog-gpio-library for instance claims 1 MHz GPIO writes in Java. However it only supports 3 SBCs as you can see from https://github.com/SilverThings/bulldog. Is there a more generic way to do this and not lose performance? Using my generated JNA wrappers for libgpiod I get about 2K writes per second. In Python I think it's about 70K using libgpiod Python bindings. I realize you may not always need 1 MHz GPIO writes, but it would be neat to offer this in a more generic way.