i am not able to set the cpu frequency to 2GHZ:
root@bananapi:~# echo 2016000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
root@bananapi:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
And here is the output from /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:
Nope, idling at 2.016 GHz is one thing, working reliably under full load another (1080mV might be not enough for this clockspeed, due to overheating I haven’t been able to test this out when I unlocked the 2 GHz back in Dec 2015 so my simple conclusion was: allow 1.8 GHz max and accept that this clockspeed can’t be reached anyway since DC-IN/temperatures prevent that).
Ich habe einen 5v Lüfter montiert und steuere den über ein bash Script.
Er geht bei einer Temperatur von über 55grad Celsius an und läuft bis die Temperatur bei 45 liegt.
Mit 2ghz läuft der m3 stabil. Zumindest für meine Anforderungen.
Habe ihn einen Stresstest unterzogen:
root@bananapi:~# sysbench --test=cpu --cpu-max-prime=100000 run --num-threads=8
Bei diesem steigt die Temperatur auf 73 ( allerdings schaltet er dann bei 61grad auf 1,8ghz) und bleibt dort stabil bis zum Ende.
Ich denke also, dass es ok ist und stabil läuft.
Ich bin mir bewusst, dass es nicht das beste Board ist, aber habe es leider erst zu spät bemerkt.
Bei mir läuft FHEM mit tabletUi, ein Cups printserver und der Rygel Mediastreamer.
Hätte gerne noch eine Digital-Out über HDMI, aber da muss ich wohl noch lange warten.
Deine Infos wären bisher übrigens immer recht hilfreich.
Ps: habe meine SATA Festplatte angeschlossen und bin auch mit der Geschwindigkeit zufrieden.
Es reicht allemal wenn man keine riesigen Datenmengen transferieren muss.
This is not a heavy workload enough and the results are worthless anyway since throttling already occurs. In other words: You did not test whether A83T with just 1080mV will work reliable at above 2.0GHz
If you love bit flips, data corruption and the like then this is an option. If you want to stay save better refrain from using potentially unreliable and untested settings. It’s possible to test such stuff but I doubt with BPi M3 since overheating is too much of an issue:
Which means you just ran the check script but not cpuburn-a7 in parallel (which is a requirement since the whole idea of reliability testing is to heat up the SoC as much as possible and then start to check for bit flips). You will have problems doing this right even with 1.8GHz and 2.0 might need liquid cooling.
And while I don’t care that much about overclocking fans who are happy to fool themselves it should be noted to anyone else who stumbles accross this thread: Don’t try to use 2.0GHz with A83T especially with potentially undervolted VDD_CPUX settings. Test it before. And you won’t be able to test since A83T overheats too much.
It’s as with the H3 SoC. In the beginning everyone (even the vendor of H3 boards) said we’re talking about a Soc ‘capable of running up to 1.6 GHz’. Now everyone accepted that it’s 1.2/1.3 GHz in reality.
this has nothing to do with reliability testing (since you have to run cpuburn-a7 together with the test tool to detect undervoltage. Or Linpack since this alone is heavy enough). So all you did was demonstrating how badly A83T is overheating even with fan since your graphs show that clockspeed even decreased 500MHz
And this shows how absurd the attempt to overclock BPi M3 is. Since you might be able to run the SoC at 2.0GHz when it’s doing nothing. But as soon as something’s to do the clockspeed decreases dramatically due to throttling
Combine both and you get the idea that unlocking the 2.0GHz has no real benefit (except of wasting a little more energy and heating the SoC up for no reason when you use performance governor) but instead might affect reliability and increases the chance of stability issues and/or data corruption (since with your settings you clearly undervolt the SoC at 2.0 GHz). Combine this with all the real existing stability issues BPi M3 already has (Micro USB for DC-IN) and it just looks like a bad idea (limiting max cpufreq to something lower would be the better idea)
Well, if the only reason to unlock 2 GHz is to gain some street credibility (“my board clocks higher than yours!”) then this is totally ok
But in case you want to benefit in any real world situations from the 2GHz the only situations would be short load peaks where you gain not even 5 percent. If this would be accompanied by save/tested VDD_CPUX voltage settings, everything would be ok. But it’s not (and I write this mainly for others who have the same idea to just increase some values here and there and then think they would be fine – they’re NOT without testing)