Jump to content

sheffield_nick

Members
  • Posts

    12
  • Joined

  • Last visited

Reputation Activity

  1. Like
    sheffield_nick got a reaction from iresearch3 in Orange Pi Plus2E changing CPU speed?   
    Firstly many thanks to all the hard work from the Armbian developers - it installed onto the eMMC of my new Orange Pi Plus2E first time with no problems
     
    I'm trying to benchmark the board (with a fan/heatsink) and without. The standard Armbian runs it at a maximum of 1.296GHz but I'd like to run it faster. I'm new to using fex, but this appears to push it up to 1.536GHz with a Vdd of 1.5V:
    cd bin2fex /boot/bin/orangepiplus2e.bin orangepiplus2e.heatsink.fex sed -i "s/1296000/1536000/g; s/1320/1500/" orangepiplus2e.heatsink.fex cp /etc/default/cpufrequtils /etc/default/cpufrequtils~ sed -i "s/1296000/1536000/" /etc/default/cpufrequtils fex2bin orangepiplus2e.heatsink.fex /boot/bin/orangepiplus2e.heatsink.bin mv /boot/script.bin /boot/script.bin~ ln -s /boot/bin/orangepiplus2e.heatsink.bin /boot/script.bin reboot have I missed anything? Is it possible to run it at the 1.6GHz that the board is advertised at?
     
    Many thanks
  2. Like
    sheffield_nick reacted to tkaiser in 5 Node Cluster of Orange Pi Plus 2Es   
    Thanks for the insights. A few things to mention:
    GPIO pins 2/4 (5V) and 6 (GND) are directly routed to DC-IN and GND from the barrel jack so you can both power the board through these GPIO pins (no drawbacks unlike RPi where you have less protection when you power through GPIO pins instead of crappy Micro USB) and also connect consumers there without caring too much The 1296 MHz maximum we use are sane defaults. Same applies to our throttling settings. In case you want more performance, don't mind using active cooling (even with a slow/silent large fan) and know what you're doing you can exceed this. To be able to use higher clockspeeds you have to test them for reliability (steps outlined here) and if you found working dvfs OPPs then you can think about adjusting throttling settings (our defaults start to throttle at 75°C but in a controlled cluster setup if you know your workloads you might want to increase the trip points) The approach to use 1536 MHz at 1.5V is as brain-dead as it was in the beginning when 3rd parties started to use these settings on Orange Pi's -- key to success is testing individually every H3 board for its limits and use these. But you have to keep in mind that the available cpufreq steps above 1296 MHz are both limited and hardcoded in kernel sources and in case you want to use eg. 1392 MHz you would have to patch the kernel -- check /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state for the cpufreqs available) Information regarding network/USB on RPi is somewhat wrong. The RPi SoC has just one single USB 2.0 connection to the outside. All available USB ports as well as the Fast Ethernet adapter are behind and internal USB hub and have to share bandwidth. So it's neither "4 USB ports" (well, the same as 1 USB port with a 5 port hub connected) nor true Fast Ethernet since this is just an USB-Ethernet adapter hanging off the single USB 2.0 connection (behind the hub!). So for anything that needs bandwidth every RPi regardless of the ARM cores they put into the SoC always horribly sucks. On a related note: interesting insights regarding your NanoPC-T3/Nexell cluster (especially the thermal stuff). Can you please provide how long the 'classic' (and potentially inappropriate) sysbench run with the following settings takes on the octa-core NanoPC? Please provide the info in this thread: http://forum.armbian.com/index.php/topic/1285-nanopi-m3-cheap-8-core-35/?view=getlastpost
    sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8
  3. Like
    sheffield_nick reacted to tkaiser in 5 Node Cluster of Orange Pi Plus 2Es   
    IMO it would be good to correct the USB/network information too. One of the strengths of the cheap H3 SoC is 3 real USB host ports + 1 USB OTG port (that can be used as host port -- Armbian default!) + dedicated networking. In case of OPi Plus 2E that's Gbit Ethernet using a dedicated RGMII connection. And H3 is powerful enough to saturate all 4 USB 2.0 ports and the GbE connection in parallel (depends on kernel version) while any RPi is always limited to one single USB 2.0 connection.
     
    There are other SBC designs that show similar behaviour (eg. the horrible Banana Pi M3 where the 'engineers' forgot to use one of the 2 USB host ports and connect both USB type A receptacles and the slow USB-to-SATA bridge to one internal USB hub that only uses one USB host port of the SoC -- but at least there GBit Ethernet is also using a dedicated RGMII connection) but RPi's design is most probably the worst possible if it's about bandwidth (regardless whether we're talking about IO or networking)
  4. Like
    sheffield_nick reacted to Ford Prefect in 5 Node Cluster of Orange Pi Plus 2Es   
    Nice work.
    Although I wonder if having all the PI's in the same box is really advantageous.
  5. Like
    sheffield_nick got a reaction from markbirss in 5 Node Cluster of Orange Pi Plus 2Es   
    I've just written an article about my latest cluster build - a 5-node cluster using the Orange Pi Plus2E single board computers - each with 4-core ARM A7 running at 1.3GHz
     
    http://climbers.net/sbc/orange-pi-plus-2e-cluster/
     
    Please share the link on Facebook/Twitter/etc if you find it interesting. Thanks
  6. Like
    sheffield_nick got a reaction from Igor in 5 Node Cluster of Orange Pi Plus 2Es   
    I've just written an article about my latest cluster build - a 5-node cluster using the Orange Pi Plus2E single board computers - each with 4-core ARM A7 running at 1.3GHz
     
    http://climbers.net/sbc/orange-pi-plus-2e-cluster/
     
    Please share the link on Facebook/Twitter/etc if you find it interesting. Thanks
  7. Like
    sheffield_nick reacted to Ford Prefect in Orange Pi Plus2E changing CPU speed?   
    The frequency must be a multiple of 24 so don't try 1600 MHz
    I found a scrip called : fix-thermal -problems.sh
    It is a good starting point.
    It was designed to help with other distributions but works here too.
    I believe that big variations of board temperature are bad for reliability so
    I limited my ambitions until I find a useful application that really needs it
    My board never exceeded 60 degrees with a big CPU radiator.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines