Hello All, With all the RPI2 build failure reports surfacing lately, I decided to do a bit of dedicated testing to try an determine where / how / when the WSJT-X build breaks. The following results are from tests I ran this evening ( some 40+ builds in all ).
Long story short, none of the builds via SSH nor after desktop login failed when using (4) cores, but, it was very close to failure when logged into the desktop. If anything was running, FireFox, Desktop Plugins etc, (4) cores caused a build failure. I used a late model RPI2 Quad Core 900Mhz (stock clocks), 1GB RAM with a ScanDisk Class-10 16GB mSD. After some initial mSD card speed testing, I'd have to say, I don’t think a Swapfile nor Swap partition would be beneficial at all, and I did not use swap during the tests I ran. I also did not use ZRAM, though this may be beneficial during actual app testing. The SoC folks probably have this nailed down, but, I did not do an exhaustive search for recommendations. I installed the latest image from [1]. The only deviation was expanding the root partition to 12GB rather than the initial ~3-4GB the image sets up. Following the post install setup ( locals and user account ), I performed a standard update and upgrade, then added subversion and openssh-server. Much to my surprise, I was happy to see both Python3 and Python2 were installed by default. After SVN and SSH installed, I logged out of the desktop and installed the remaining build dependencies from [2] via SSH. I used ( watch -n .1 vmstat -sSM 1 ) for all memory observations. I used JTSDK-Nix v2.0.19 to allow for command line option testing on this platform. The installation went as expected, as did all the WSJT-X builds commands. After Base + Build Dependency installation, idle vmstat [3] observations were taken, results are as follows: VIA SSH ( in MB ) Total Memory (Tm) = 925 Used Memory (Um) = 141 Free Memory (Fm) = 784 After Desktop Login ( in MB ) Total Memory (Tm) = 925 Used Memory (Um) = 261 Free Memory (Fm) = 664 *BUILD NOTES* * Before each run, the build and install locations were deleted, only the SRC directory remained constant in each run. I also cleaned the memory by dropping the caches. * I ran 5 builds each at 1, 2, 3 and 4 cores via SSH and logged into the Desktop Environment. * Core changes were made to the jtsdk-wsjtx build script directly. * Hamlib3 was build first over SSH with (4) cores. No anomalies were noted. *BUILDS VIA SSH* (4) core builds are doable, but, you have to watch (Um) closely. If you have any background apps running, RDP, VNC, Samba, whatever, you run the risk of the build failing. With (4) cores, (Um) reached a high limit in ~850-875MB range during the CXX target section, but, I did not see anything over 900MB. To be safe, using (3) cores may be a better, (2) is you have any memory intensive apps running in the background. *BUILDS VIA DESKTOP ENVIRONMENT* I had nothing running in the background that was not configured at installation. Only a single Terminal + 1 tab was open to build and monitor memory usage, No browsers, nothing else. (4) cores was used initially. With (4) cores, three targets pushed (Um) over 900MB approaching (Tm): - echoplot = 920 - wsprnet = 912 - wsjtx_automoc = 920. When using (4) cores, if I started virtually any application, Firefox, etc, the build failed at various points in the CXX target build section ( >= ~75% or so ). The failures were not on the same targets each round. Some duplicates were noted but not to the point where one would say that target has a problem. As far as I can tell, watching the screen, WSJT-X builds the same with armv7l as it does with amd64/i386, the only exceptions being speed and the Cmake name messages. *CONCLUSIONS* - I believe you can run (4) core builds, but you must watch (Um) closely. - Even in an SSH shell, if your (Um) is over the 260MB range at the start, you should consider backing off at least one if not two cores to be safe. - After running all the various core combinations, I would think (2) core builds should be reasonable in a typical Desktop Environment. - While not tested, based on the mSD card read/write speeds I observed, I think enabling a Swapfile or Swap partition would slow things down considerably compared to today's SATA / SSD dive speed performance. - While these small SoC devices are very capable, don't expect workstation performance from them. I have an HDMI converter box on the way for my monitor, when that arrives, I'll do some on-air testing to see if things work as expected. 73's Greg, KI7MT LINKS: [1] https://ubuntu-mate.org/raspberry-pi/ [2] http://sourceforge.net/p/jtsdk/jtsdk/HEAD/tree/jtsdk-nix/trunk/README.pkg-lists [3] http://linuxcommand.org/man_pages/vmstat8.html ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
