ag123

Members
  • Content Count

    92
  • Joined

  • Last visited

About ag123

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ag123

    testers wanted Next major upgrade v5.60

    nope, i'm referring to the non-responding sshd, rpi-monitor freezes etc. that seemed to be alleviated selecting a vm.swappiness that is moderate say 50 etc
  2. ag123

    testers wanted Next major upgrade v5.60

    after some searches i've only found a related but different issue https://github.com/armbian/build/issues/219 that relates mainly to kswapd taking 100% cpu - found quite a few instances in google searches not related to armbian. that particular issue seemed to be alleviated by vm.swappiness=0 but given the rather large lapse of time that issue is raised in 2016, and that it is for a different kernel 3.4.x it may not be directly relevant i think for the time being selecting a vm.swappiness in a mid range between 0 to 100 seem to alleviate related issues surfaced currently
  3. ag123

    testers wanted Next major upgrade v5.60

    i won't be able to prove this easily, but if setting vm-swapiness to values less than 100 alleviates the issue, could it point to some possible issues related to or with zram? some google searches draw a blank as various similar issues are found but not identical to this, i.e. that zram isn't specifically mentioned. the other thing would be that it may be necessary to have the oom killer log the processes killed into /var/log/messages (i.e. by syslog or journald) for post mortem analysis of what actually happened, e.g. is sshd literally killed? i think oom killer currently only logs to dmesg, which means that the traces are lost once the board/soc is reset / restarted. i'm not too sure where such logs could be configured to be captured (kswapd?) such that if a paged out / swapped memory could not be restored the event be logged in syslog etc
  4. ag123

    testers wanted Next major upgrade v5.60

    i think the issue about the vm.swapiness is that some of the processes, e.g. sshd after it is swapped out i.e. not resident in memory, may not respond or respond too slowly to connects over the network. i.e. that for some reason, external connects did not initiate a swapped out process image to be reinstated in memory in a normal manner if that's the case any attempts to connect over ssh fails reducing vm.swapiness in this case makes it more likely that sshd remains resident in memory rather than being swapped out, hence it alleviates the problem, but this likely won't resolve it entirely
  5. ag123

    testers wanted Next major upgrade v5.60

    i think the somewhat elevated temperatures of say 70-75 deg C on H3 socs can be tolerated. the main trouble is that many of these boards ships without a heatsink the main thing about running at these temperatures is that the board needs to run in a well ventilated environment e.g. that it should not be enclosed in a box that limits simple convection heat transfer (i.e. 70-75 deg should be an upper load limit and temperatures must stabilise at this range during high loads and must not increase) I've an orange pi one that i found rather commonly runs at those temperatures without a heatsink, i'd imagine it may even be possible for it to goto boiling point 100 deg C and that the soc still runs but that to prevent damage, it would be necessary to throttle the frequency (e.g. reduce to 400mhz) and lower the voltages (reduce to as low as is possible e.g. below 1.1v if possible) at those temperatures. but a shutdown should be unnecessary but that 70-75 deg C should be considered 'normal' operating temperatures for H3 socs running at 1.2ghz when under high loads the situation can be improved quite a bit even with a rather small heat sink especially at the higher temperatures https://forum.armbian.com/topic/8203-orangepione-h3-an-experiment-with-small-heatsink/ in particular at the higher temperatures 70-75 deg could be rather easily reached in hot summer temperatures as heat transfer is a function of temperature differences vs ambient temperatures. a heat sink needs to be combined with good ventilation to remove all that heat and as in my experiment, heat sink + *good ventilation* prevents the soc from reaching the higher temperatures and that at steady state it lets the soc run at a marginally lower temperature than without a heat sink the problem i've with the orange pi h3 socs is that *after* the os is shutdown, the h3 soc and the board can overheat to such extreme that temperatures is well above 100 deg C, i almost have a board going up in fire. the only safe / precautionary way for now is to disconnect power once the status led indicates that the os has shutdown and do not issue a shutdown remotely if you can't unplug power from the board
  6. ag123

    Pi-factor cases

    unfortunately no thanks to the big brand companies who brought the r-pi and tinkerboard (shudder) to the masses, for some reason, some brand companies seem to think micro-usb for powering a 10 watts or more board should be adequate, i'd guess that's why the board is designed that way in the first place on another note i went for an orange pi choosing between that and tinkerboard as partly due to price and that for those orange pi boards i bought, they come with their own dc barrel jack connectors, it is simply better for a bit more board real estate
  7. ag123

    Orange Pi PC old OS image

    oh well, i didn't realise this rather nice tool exists, i guess i've been pretty old school as before i get to know armbian, many things used to be you are on your own, and dd is one of the tools that's just there https://etcher.io/
  8. ag123

    Orange Pi PC old OS image

    just like to share my 2 cents as i'm using 5.59 Debian stretch image on Orange Pi PC if you have been using the 'old' images e.g. 3.x series, that is quite different from stretch (i've not tried bionic) which uses 4.x kernels. the 4.x kernels are mainline linux kernels. the old 3.4 kernels uses some of the binary blobs like FEX etc distributed by Allwinner et.al. 4.x kernels are mainline linux kernels and FEX is not there as FEX Is propriety and the binary blobs is close sourced. 4.x mainline kernels has some of the old 3.x functionality reverse engineered open sourced and the features are pretty functional but not all of it. i've used the 5.59 ubuntu stretch (mainline kernel 4.14.65 image for orange pi pc and do note that it is a cli (command line based) image HDMI works for me in 5.59 Ubuntu Stretch mainline image, connect a usb keyboard and mouse to work on it like a PC i'm not too sure if the Orange Pi PC you have bought a year back is after all the same as that i bought just recently, but based on the specs i think it should be pretty much the same. I'm not too sure if things may have changed between the year. If things are the same, install the image on a new (or different) SD card (i work in linux and simply did dd if=Armbian_5.59_Orangepipc_Debian_stretch_next_4.14.65.img of=/dev/<the sdcard device> bs=1m to write the image to the sd card. and boot that on the Orange Pi PC, it should boot and should leave you on the command prompt in HDMI asking you to logon. be a little careful with the initial password changes as you would need the new changed passwords after the initial logon and user creation. i made some mistakes and got locked out initially. ssh needs to be setup anew as the os is reinstalled. i think if you are used to access the sbc as orangepipc.local. you may find that ping etc didn't turn up orangepipc.local. i found out that that is mainly because avahi-daemon (i.e. mdns) is not installed on the orange pi pc. what i did is to do apt-cache search avahi on the sbc and install the avahi-daemon (e.g. apt-get install avahi-daemon) and subsequently i'm able to ping my board as orangepipc.local connected on the ethernet. i'm not using any wireless dongle. after that ping and ssh to the hostname orangepipc.local works. if you want to install the desktop, you need to run the commands: - apt-get upgrade armbian-config followed by - armbian-config as root and there is an option to install the desktop Note that a new image Armbian 5.60 may be released soon, if you want that earlier, you could run apt-get upgrade armbian-config followed by armbian-config and switch to the nightly build if things are still not working for you, you may want to fall back to the Xenial 3.4 image instead, as you have mentioned it seem to work well for you i won't be able to help much with the wifi dongle but in armbian-config i think there is something like install/upgrade firmware package. i found that the 'firmware package' distribute quite a number of blobs and some of it seem to be related to wifi chips. you could try that to see if it helps. and this is for the stretch image and i'm using the nightly builds
  9. i'd like to suggest to get a new micro sd card and start afresh, i.e. new install from image, then apt-get upgrade armbian-config followed by things like running armbian-config (for 'switch to nightly' and other upgrades etc). sometimes such 'hardware issues' could be due to power issues, or rather the lack thereof. some 'mobile phone chargers' couldn't really deliver the 2 amps which i think orange pi pc easily consumes. if you consider that usb supplies 5v on the rails and it is 2 amps that the sbc / soc draws, that is a whopping 10 watts of power. it means one would need to get a 'phone charger' that can supply well in excess of 10 watts to keep the sbc and the sd card happy and running. those high amp chargers are available these days and try to go for those better ones with reliable specs. in addition, the usb cable connecting between the power supply (phone charger) to the sbc matters as well, get a good 'thick' copper wired cable so that it'd supply the power and not fail
  10. ag123

    zram vs swap

    don't worry @tkaiser zram *is fast*, very fast in fact, the experience running x-desktop on orange pi pc 1gb ram and even orange pi one 512k ram is quite a bit smoother with zram however, it isn't about zram's speed that's the only consideration, e.g. for the orange pi one 512k ram, running on only ram and zram may land one with a freeze up / stall when memory really runs out especially when running on x11 desktop with various apps. hence some swap on flash is *inevitable* to overcome the simply *lack of ram*. then there are other issues on the fringes, such as ssh failed to connect after some time https://forum.armbian.com/topic/6751-next-major-upgrade-v560/?do=findComment&comment=62409 https://forum.armbian.com/topic/6751-next-major-upgrade-v560/?do=findComment&comment=62484 that seemed to be alleviated by setting a vm.swapiness, less than 100 leaving some room for some idle processes to simply 'stay in memory'
  11. but of course the high end desktops these days runs delivers much higher staggering gflops compared to simple arm chips https://www.pugetsystems.com/labs/hpc/Skylake-X-7800X-vs-Coffee-Lake-8700K-for-compute-AVX512-vs-AVX2-Linpack-benchmark-1068/ nevertheless arm chips these days on SBC could easily rival those of early p3, p4 and amd64 single core cpus
  12. hi all, as documented here, i did some minor experiments with small heatsinks on an orange pi one sbc (allwinner H3) among the things i used a small matrix multiplication program which multiplies a 1000x1000 matrix single precision floating point matrix main.cpp the command to build is c++ -O2 -std=gnu++11 -pthread -o mat main.cpp then run ./mat the last documented results on an orange pi one H3 running at 1.2ghz is 2389.49Mflops ~ 2.39Gflops the sources attached is 'optimised', the means of optimization is unrolling of the innermost loop to take advantage of platforms that could do quad sp fp simultaneous execute i think those neon enabled platforms would be able to do that. the other optimization is that it spawn off 4 threads so that it could utilise 4 simultaneous threads for the matrix multiplication could try to run this and let us know what is the 'mflops' you get on your sbc? what is the sbc , the soc and the frequency it is running at? note that this is not necessarily the most optimised for your sbc / soc the parameters you could try to tune includes the THREADS_NUMBER for the number of concurrent threads in the source code in addition those who have more powerful soc could try to unroll the loops further, e.g. try to compile with additional options like -funroll-loops or even -funroll-all-loops you could also manually update the codes e.g. to double the set of manually unrolled codes in the loop so that it become 8 sets of computations instead of 4, but you would need to review the codes such as using MATRIX_SIZE/8; i+= 8 in in the loop if you unroll the loop into 8 sets of variables, you'd need to update the summation after the loop as well result.elements[row][col] = r1+r2+r3+r4; to add the other r variables that you unrolled into the original 'unoptimised' codes can be found in references in the original post. strictly speaking this is not really a good test of computational prowess unlike those of linpack etc. linpack actually solves a matrix, and this is purely a square matrix multiply. in addition, this does not explicitly use neon etc and those usage depends on the compiler optimization (i think gcc / g++ has a build in vectorizer, hence you may like to experiment with the options) but nevertheless seeing mflops, gflops is fun, mflops, gflops is also normally a function of the frequency the core executes at, hence you could try to overclock your soc to get more gflops
  13. ag123

    Cheap HDMI monitor -1

    wow it is so extremely hot https://www.aliexpress.com/item/7inch-TFT-LCD-Screen-for-Orange-Pi-H3-chip-Boards/32831758014.html i used one of those hdmi switch instead https://www.ebay.com/sch/i.html?_nkw=hdmi+switch&amp;_sacat=0 and as it goes the one i used doesn't work very well, often switching between the displays ended with blank screens in the end i did something simplier. connect to the SBC via ssh over ethernet, x-desktop & the apps are installed and i simply send them over to the 'main' pc via ssh -X sbc sending individual app windows over is much preferred over VNC etc as it is low bandwidth and it feels like working on a same pc
  14. if you are running a recent nightly builds there is some suggestions that changing the vm swapiness may help among the things check /sbin/sysctl -a |grep vm.swappiness vm.swappiness = 100 check in /etc/sysctl.conf if it is defined there you may like to reduce that value to 50 (or even for tests 0) to see if it made a difference
  15. my apologies to have detoured from the topic, but yup no hurry to 'rush' into 4.19, it isn't 'born' yet , for now i think there is still the job of moving to 5.60 and actually fix issues found in 5.60 back on topic. one of those things is a 'modularised' build and deploy. if we could imagine we have build environments : stable, next and dev a 'development environment change flow' may be pictured as simply the reverse dev, next, stable (production) the trouble with projects grown this large is there are x number of socs, y number of boards, and z sets of kernels with specific patches that is not in mainline (and to add to that applications issues e.g. firefox, chromium and their giant suit of plugins, video acceleration, open gl es etc) at any one time a fix done for x soc, y board on z kernel, that may well be tested ok, but the rest of x socs, y boards, z kernels may well be still WIP and things are continuously happening ideally we'd be able to deploy the fix for x soc, y board on a particular 'module' say into 'next' for more testing before committing the same fix to stable. it isn't easy at all to manage that let alone even with git. git branches etc tend to take things 'wholesale', hence during a merge those WIP things say from other socs / boards get applied during the merge as well. one of those thoughts is say even with development branches that perhaps it may be possible to split the branches into the distinct groups. e.g.by socs/boards/kernels (i'd think at least soc & kernel) and even an 'application' branch. i'm not too sure if doing something like this could help to ease efforts when it comes to merging the fixes. of course the other way is to think of the main armbian build repository as 'master', and the development and next in separate repositories so that changes to armbian build 'master' comes as pull requests. and in the development repository there could be several branches say for groups of soc / kernels so that they are rather distinct to ease merging efforts well just thinking aloud, i'm not sure if this solve anything at all and may instead simply add complexity