tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
1 hour ago, datsuns said:
Is Le Potato at the forefront power-wise around the $35 price point or is there something comparable?
http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=206 (read the reviews there, especially from Willy Tarreau who explains how to get all 8 cores running at 1.6 GHz. He's also the one who discovered Amlogic cheating on us wrt fake clockspeeds 2 years ago)
With Amlogic there's nothing comparable at the moment (the S912 is an 1.2 GHz SoC) and also as usual they cheat on us wrt clockspeeds (it's not related to throttling or thermal protection, it's just a firmware blob loaded on the embedded M3 core controlling cpufreq/DVFS and doing 'magic things' not under our control using whatever clockspeeds it wants and reporting bogus values back to the kernel)
-
@Da Xue friendly reminder: can you please answer my questions? Hash to identify which bl30.bin blob is used where and FULL sysbench output to get an idea why your numbers are better.
I mean it's pretty obvious that there's something seriously wrong and not related to throttling/protection or how do you explain result variation with @TonyMac32's tests and your own low OpenSSL scores?
-
16 hours ago, NicoD said:
I can't find a lot of info about these
http://linux-sunxi.org/Banana_Pi_M3 and here in the forum you need to search for 'NanoPi M3' (that's the cheaper variant with same SoC and just 1 GB DRAM now replaced by NanoPi Fire3 which should be the fastest el cheapo SBC around with 8 x A53 clockable at up to 1.6 GHz according to Willy Tarreau -- click on 'reviews' here: http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=206)
Fascinating aspect is that all the more powerful SBC except the ODROIDs are prone to underpowering by design by using the most crappy connector possible. And also an awfu lot of them show thermal problems since the 'engineers' forgot to allow to mount an appropriate heatsink/fansink. No idea what those 'engineers' thought...
-
10 hours ago, Da Xue said:
Unlocked DVFS for overclockers is never going to happen so don't bother thinking about it.
Nobody is talking about this. It's only about stopping this proprietary closed source blob game (a blob that controls cpufreq behaviour in reality and all we can do is to compare which versions of blobs are in the wild). This whole discussion is also not 'moot' but useful to avoid certain products if issues can't be fixed and a project dedicated to open source gets into a position where 'searching for the right blob' is all it could do (hooray, closed source RPi level reached)
This and other threads and even your own measurements over at https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ confirm that there's a massive problem with this bl30.bin thing (or how do you explain your poor OpenSSL numbers that indicate not even 1350 MHz? How do you explain standard deviation with lightweight stuff like sysbench ruining performance)?
Can you please provide full output from 3 sysbench runs and MD5 or SHA1 hash of your bl30.bin?
-
On 10.4.2018 at 8:56 AM, LeeAdama said:
my version of htop for the Raspberry Pi to work on the AML-S905X-CC (Le Potato) that shows cpu temp and current frequency
The latter is impossible since the kernel has no control over cpurfreq: https://forum.armbian.com/topic/7042-amlogic-still-cheating-with-clockspeeds/
You can not rely on sysfs cpufreq values with Amlogic just like with Raspberries since cpufreq/DVFS is under control of a proprietary firmware running on an own Cortex-M (on the Raspberries this runs on the VC4 instead). You would need an algorithm that actually measures cpufreq, see Willy Tarreau's mhz utility that works correctly: http://forum.khadas.com/t/cpu-frequency-up-to-2ghz/2010/5?u=tkaiser
-
10 hours ago, chwe said:
Maybe someone repeats the benchmarking which was done by LibreComputer with armbian?
I just looked through those numbers on https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ again just to realize that there's also something seriously wrong. The OpenSSL tests are also a great benchmark to check for real CPU clockspeeds since not affected by memory bandwidth at all (the AES scores with ARMv8 Crypto Extensions available scale linearly with clockspeed when comparing different A53).
When comparing Le Potato (S905X claiming to run at 1.5 GHz) with Renegade (RK3328 at 1.3 GHz) then it's pretty obvious that the S905X was running with 1320 MHz maximum. Which is a bit too low even if we already take into account that S905X can't reach the 1.5 GHz anyway due to bl30.bin situation.
There's something seriously wrong with CPU clockspeeds on Amlogic platforms. And maybe there's also a relationship with broken/weird scheduling though I really don't understand how this can happen (there should be no difference on a quad-core CPU whether the kernel decides to run on cpu 0-3 or the user 'forces' exactly the same using 'taskset -c 0-3' -- but reality draws a different picture)
-
7 hours ago, chwe said:
The question is, how we deal with this data?
Once the new website is up and running or even now, create a single line under 'known issues', name it 'bogus clockspeed behaviour not under our control' and link to this thread where the first post can contain a summarized TL;DR version so people get the idea what's going on and in case they feel that's of interest can read on.
In the meantime I tried to summarize the situation with S912 and Khadas' 4.9 kernel as follows: http://forum.khadas.com/t/s912-limited-to-1200-mhz-with-multithreaded-loads/2311/54?u=tkaiser
Situation with S905X is somehow related since even if S905X has not this 'big.LITTLE' emulation issue according to @TonyMac32's tests it makes a difference in performance behaviour if he lets the kernel implement the scheduling the kernel wants (using cpu 0-3) or setting a 'fixed CPU affinity' with taskset still only making use of cpu 0-3 (there is no more CPU cores) but showing better performance. Especially this weird part needs some explanations and a fix!
-
2 hours ago, chwe said:
And SBCs based on those SoCs should be marked under 'additional infos' something like: max cpu freq. ~1.2GHz when all 8 cores are used.
Why is nobody looking into the DATA provided?!
@TonyMac32 provided the results from 3 sysbench runs. The execution time differed always. But sysbench while being not a good hardware benchmark provides great info to understand why numbers suck: Minimum execution time for generating a prime number in all 3 cases was the same: 2.58ms. What differed were the average values and as can be clearly seen DVFS and cpufreq scaling on Amlogic platforms is totally screwed. The M3 running with a proprietary firmware does funny things not under control of the kernel:
execution time (avg/stddev): 8.8774/0.00 avg: 3.55ms approx. 95 percentile: 6.63ms execution time (avg/stddev): 6.9912/0.00 avg: 2.80ms approx. 95 percentile: 2.67ms execution time (avg/stddev): 6.5903/0.00 avg: 2.64ms approx. 95 percentile: 2.63msSituation is even more crappy as on the Raspberry Pis where ThreadX only either does frequency capping (disabling Turbo mode when undervolted) or throttling. What the proprietary firmware on S905X and S912 is doing is beyond my imagination. That's just weird.
An interesting question is now whether Amlogic provides board makers with special bl30.bin blobs to allow them to generate nice benchmark numbers and why real world performance especially with S912 is so shitty. Has to be answered by people who are part of Amlogic's closed source / proprietary world (most probably not able to tell anything since having signed NDAs).
For me Amlogic is from now on a no go. As bad as Raspberry Pi wrt 'openness'.
-
14 minutes ago, TonyMac32 said:
execution time (avg/stddev): 6.5903/0.00
That's 1400 MHz. So for whatever reasons we are not able to have any reproducible influence on how cpufreq scaling and DVFS works on Amlogic platforms. It's some proprietary / closed source crap contained in BLOBs.
I wonder how @Da Xue deals with this since the benchmarks he published here need some explanations... (when we all have to use a shitty and limited bl30.bin while benchmarkers can use better ones)
-
18 minutes ago, TonyMac32 said:
execution time (avg/stddev): 8.8774/0.00
That's running with 1040 MHz.
18 minutes ago, TonyMac32 said:execution time (avg/stddev): 6.9912/0.00
That's 1320 MHz. Numbers taken from this interesting thread where @Da Xue tested with special BLOBs he got from Amlogic but is not free to distribute...
@TonyMac32: Another try would be to prefix the sysbench call with 'taskset -c 0-3 '. Shouldn't make any difference but at least on Vim2 with 4.9 kernel S912 magically started to work with reasonable cpufreq behaviour.
@chwe: can you please move the last 3 posts from this thread into the 'Amlogic still cheating with clockspeeds' thread please?
-
On 11.2.2018 at 7:56 PM, lanefu said:
I was shocked with how pleased i was with my le potato
Is you or @TonyMac32 running Le Potato with Xenial? If so may I ask for the full output from
echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4Takes less than 10 seconds...
-
20 hours ago, NicoD said:
@tkaiser I'm one of those "absolutely clueless people" who bought it
Nope, I was talking about 'clueless people' just to outline which challenges those TV box manufacturers face. Unlike premium STB device makers like BroadCom or HiSilicon where the SoCs can be reasonably designed to do the job since no end customer has to 'choose' them based on specs they don't understand (those boxes are given away 'for free' by their broadband provider) those 'el cheapo TV box' SoC makers have to design their devices in a way they look appealing to... clueless people (many CPU cores, high CPU clockspeeds). On the other hand those TV boxes can't be designed well since... clueless customers prefering devices with poor heat dissipation.
In the 'TV box world' those Amlogic things work pretty well since CPU performance is irrelevant anyway (only exception: exotic codecs the video engine -- VPU -- can not handle). But on SBCs it's something different since there the users expect from a SoC advertised as 'octa-core at 2 GHz' a bit more than the laughable 'octa-core at an average 1.2 GHz' performance they get with S912 in reality.
-
18 hours ago, Igor said:
Boot log: http://ix.io/18DU
USB3/XHCI is not active according to the boot log. Seems PHY_SUN50I_USB3 is not set?
-
4 hours ago, chwe said:
I might use your post as first one, so that you could decide how the thread is named
Please do so. Getting tired of reading too much and repeating the same BS over and over again.
Look how cheating works. You do not need to write numbers on your web page, you simply ship an Android that reports bogus values so people reyling on shitty tools (again Geekbench, CPU-Z, AnTuTu) get fake numbers and these are then used in reviews, advertisements and so on...
- mid 2016 situation: Amlogic 'talks' about 2 GHz: https://browser.geekbench.com/geekbench3/8052062 (of course back then the SoC was also only allowed to clock up to 1.4 GHz with single threaded loads)
- end of 2016 situation: Amlogic adjusts the faked top cpufreq number from 2.0 GHz to 1.5 GHz: https://browser.geekbench.com/v4/cpu/search?page=2&q=s912&utf8=✓ (it's still 1.4 GHz in reality and with multi-threaded loads it's even less)
- 2018 situation: BS numbers finally confirmed: http://forum.khadas.com/t/cpu-frequency-up-to-2ghz/2010/5?u=tkaiser (but I have no idea what those Vim2 users are doing? All brainwashed? It's so easy to check for real performance. Why is no one doing this but is instead blindly trusting in irrelevant BS numbers?)
-
4 hours ago, tkaiser said:
If you want the same happen now with S912 you need to go to Khadas and annoy them about their flagship product Vim2 only running at 1.2 GHz when multi-threaded performance is needed.
In case anyone with access to the hardware (be it a Vim2 or any other S912 device) wants to help with checking the issue: http://forum.khadas.com/u/tkaiser/activity/replies
-
On 21.4.2018 at 3:59 PM, chwe said:
I guess, and that's just a guess that also their closed source SoCs benefit from the expertise they have now inside the company how to do it properly.. They might or might not cheat you with the closed source ones (I've no clue). But at least their in-house knowledge is grown.
Expertise? Knowledge? You were talking about Rockchip now but what should've changed? Still their target audience are absolutely clueless people who buy numbers. Rockchips' customers (TV box makers) have to advertise their boxes with BS numbers (1.5 GHz and stuff like that), those tools used for reviews (CPU-Z, Geekbench and so on) have to report these BS numbers too and how high the CPU cores clock in reality is something entirely different (and irrelevant anyway! Why does no one get this? These boxes all have crappy thermal design so why does anyone expect el cheapo SoCs performing great in shitty plastic boxes?)
Anyway: if you want to change something wrt Amlogic here (for whatever reason) you need to make some noise. The thread title here is absolutely useless (I proposed 'Amlogic cheating' for a reason) and it's rather useless to further discuss this stuff here. Hardkernel got some pressure by the 'MHz fanatics' who are too stupid to differentiate between performance and clockspeeds. If you want the same happen now with S912 you need to go to Khadas and annoy them about their flagship product Vim2 only running at 1.2 GHz when multi-threaded performance is needed.
-
16 minutes ago, JMCC said:
But, for example, when the cheating was first discovered for the S905 by some other developer (his name started with "W", I can't remember), then Hardkernel got Amlogic to give them binaries that unlocked the real CPU freq
Only some 'MHz fanatics' were really concerned. Or to be more precise: people who do not understand the difference between performance and clockspeeds and who also do not understand the challenges to run chips at high clockspeeds (both consumption and heat increase a lot). Again: https://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appear-to-be-limited-to-1-5-ghz-not-2-ghz-as-advertised/#comment-530956 (there you can also read what happened then in detail to get more control over clockspeeds on C2)
If I'm concerned about performance I need a use case first and then I test for performance with this use case (and don't rely on theoretical clockspeeds since this is plain stupid). That's what both Willy Tarreau and @willmore did unlike those people who for whatever reasons bought an ODROID-C2 instead of an RPi 3 due to '2 GHz' vs. '1.2 GHz' (those people exist en masse). So it was pretty obvious once that happened that an A53 'clocked at 2 GHz' performing like one clocked at 1.5 GHz is just that: limited to 1.5 GHz. So what? This is on those devices always the result of consumption and thermal constraints so why bother?
Since I mentioned 'use case' and Raspberry Pi 3:
- If you need the performance for a use case called 'AES encryption' (VPN, full disk encryption, stuff like that) then looking at clockspeeds is what? Plain stupid as usual! Both ODROID-C2 regardless of being able to clock at 2 GHz or just 1.5 GHz performs as crappy as the RPi 3. They both do not support ARMv8 Crypto Extensions and perform magnitudes slower than any cheap NanoPi NEO2 or Orange Pi Zero Plus running at below 1 GHz CPU clockspeed: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829
- RPi 3 is the SBC with the most screwed up DVFS/cpufreq/clockspeed situation. The problem should be well known since 2015: an awful lot of RPi suffer from underpowering and run then frequency capped (limited to 600 MHz). But just like in situations when throttling is happening the kernel has not the slightest idea at which clockspeed the CPU cores are running and reports bogus values like 900 MHz on RPi 2, 1200 MHz on RPI 3 and 1400 MHz on RPi 3+ while in reality being limited to 600 MHz. Is this 'cheating' or at least a problem? Not when your target audience is only absolutely clueless people (RPi users). They're happy to achieve top clockspeeds only in idle and being limited to 600 MHz once performance would be needed and even start to complain once they are made aware of the real problem (seriously: check this link, it's unbelievable)
-
1 hour ago, chwe said:
IMO the 'next' generation of TV boxes will combine something like TV-box (with recording function) and cheap home NAS with acceptable performance.
This already happens. RealTek RTD1295 and RTD1296 devices do exactly this. They run an Android for the media stuff and an embedded OpenWRT for NAS stuff. No idea how it's done on the NAS boxes based on these RealTek SoCs.
Which kernel version and u-boot do they use? How performant are these boxes? Nobody cares since all that's relevant are whether these boxes do what they're advertised for and then some BS numbers like count of CPU cores and their clockspeeds that keep clueless NAS and TV box consumers happy.
RTD1296 will be used on BPi W2 and OPi R2. No idea whether we'll ever see sources for 'firmware', bootloader and kernel. No idea why anyone want to run Linux on devices that need such crap. But it clearly is absolutely irrelevant for RealTek as long as they think about their target audience (clueless people once again) who simply don't give a sh*t about all that stuff as long as the box does what it's advertised for (that's playing movies, doing some gaming and serving as a performant NAS thingy).
-
1 hour ago, JMCC said:
in the mid/long term the company's reputation plays an important role. And the minority of experts who have earned respect through their work and contributions (e.g. you guys Armbian core developers) have an important impact in forming that reputation: their contribution spreads from specialized blogs and forums to more public-oriented informational webpages, youtubers, etc.
LOL!
It's now 5 months that I discovered S912 cheating wrt CPU clockspeeds as every other Amlogic SoC. What's the impact? None.
- Why should the average Amlogic consumer care? That's TV box manufacturers selling to clueless Android users that trust in BS numbers presented by CPU-Z. They see 2 GHz and are happy.
- Why should Amlogic care? It's those consumers that they have to keep happy and they are happy when they can tell their neighbour that their TV box has 8 cores running at 2 GHz while the neighbour's has only 4 cores 'at 1.5 GHz'. CPU clockspeeds are BS for the use case anyway so everything those clueless people care about are irrelevant numbers.
- Why should Amlogic SBC users care? Well, they are in fact the only ones affected but if they would care about performance and not clockspeeds they would've known anyway (since then you test the performance and not rely on BS numbers like clockspeeds). It's stupid to think something that's rated for 2 GHz is faster than something else that's rated for 1.5 GHz (but that's what all those disappointed ODROID-C2 users thought)
And all of this including vendor reputation is completely irrelevant for their market. That's not Linux geeks and blog readers but clueless TV box consumers searching for the cheapest box possible that has best looking specs (many many CPU cores, high clockspeeds and all the other irrelevant BS that's irrelevant for the 'TV box use case' anyway. How many of those consumers know that video decoding happens on the VPU and gaming is the GPU's task? Exactly: none)
And all vendors in this market behave the same. Even Rockchip (only a few Rockchip SoCs are 'open sourced' but the majority not and there the same funny stuff happens of course)
-
22 minutes ago, chwe said:
If the s912 can only reach 2GHz in a single core mode, I'm fine but lie to the customer is a shot in your own knee. It needs a lot of time to rebuild your reputation, probably not that much an issue for the 'cheap as hell' tv box, but in case you want to be one of the 'premium' TV-Box SoCs it gets problematic
The S912 is limited to 1.5 GHz with single threaded loads and way less with multithreaded CPU loads. For the very simple reasons that the device category targets absolutely clueless users (why is this so hard to understand?!). The difference between the two boxes below is simply that the upper one is made for people who know how heat dissipation works (it's ok or even great when the surface gets warm since this means heat is transported out of the thing) and the lower is bought by clueless people who want boxes that stay cool since they're clueless:
Amlogic produces SoCs that are stuffed in those cheap plastic boxes. And since good heat dissipation is limited or impossible due to clueless consumers the 'thermal budget' dictates clockspeeds anyway (throttling!). And also only due to their customers being absolutely clueless they can't promote such facts but have to create the impression that there are many many CPU cores inside running at high frequencies.
Since you mentioned 'premium' TV-Box SoCs: That's for example Broadcom STB SoCs like the BCM7271. Which CPU cores? ARM? MIPS? How many? Which clockspeeds? Nobody knows for sure since those things are put into boxes that are not bought by clueless consumers who want to base their decision on BS numbers but are given to TV consumers by broadband providers 'for free'. Nobody cares about technical details since these things just work. There's no need to cheat on consumers since consumers do not have to decide. And it's a pretty new phenomenon that those premium STB SoCs have more than one or two CPU cores. Since video decoding on the CPU is plain BS anyway!
-
16 minutes ago, tkaiser said:
It's easy to choose appropriate hardware for any job but then (not so) surprisingly you pay a lot more.
BTW: Not always: those people who are for whatever reasons fascinated by 'as much CPU cores as possible' and love octa-core SoCs for no reason should better have a look at NanoPi Fire3: http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=206
Less expensive and faster than any Amlogic stuff (see Willy Tarreau's reviews -- he's the one who also discovered Amlogic cheating on us wrt clockspeeds 2 years ago)
And can now a moderator please split all the 'Amlogic still cheating with clockspeeds' stuff into an own thread with that title? Thanks and sorry for hijacking the original thread.
-
And BTW: It really doesn't matter for the 'TV box use case' (which is the only one Amlogic has to care of) whether their SoCs are artificially limited to lower clockspeeds when more cores are busy or whether thermal throttling does the same anyway.
Their challenge is making products for absolutely clueless people. The products these SoCs end up in (cheap TV boxes) can't be designed with good heat dissipation since those clueless people who should buy the boxes will never understand that a warm or even hot enclosure is something good: https://www.cnx-software.com/2017/11/08/khadas-vim2-board-review-part-1-unboxing-and-dual-tuner-board/#comment-548927 -- a TV box with a good thermal design moving the heat efficiently out of the enclosure gets negative ratings and won't be bought since... clueless people being the target audience of these devices.
TL;DR: If you as Linux guy want to use Android toys as hardware you have to accept Android rules (cheap consumer crap being the design principle). It's easy to choose appropriate hardware for any job but then (not so) surprisingly you pay a lot more.
-
3 minutes ago, Da Xue said:
Didn't know that. S912 can only do 1.2GHz with 4 cores?
You should know since I discovered this here and we talked about this already wrt S905X. Here is the summary: https://www.cnx-software.com/2017/11/08/khadas-vim2-board-review-part-1-unboxing-and-dual-tuner-board/#comment-548918
The 'Gouwa' guy in the comment thread is an official person from Khadas (not helping to further diagnose the issue and now also part of the Amlogic cheating game)
-
21 hours ago, balbes150 said:
there are normal manufacturers who give the correct information. https://www.khadas.com/vim
The Khadas guys know that S912 is limited to 1200 MHz when more than 3 cores are busy but of course they prefer to hide this information since their target audience can't cope with. Which is understandable given SBC users focused on CPU clockspeeds instead of CPU performance are not the smartest people.
Temps
in Libre Le Potato
Posted
If you read through the other thread closely you'll realize that there's nothing related to temperatures. It's just some proprietary closed sourced code running on an own MCU inside the SoC controlling the clockspeeds, ignoring the cpufreq framework running in the Linux kernel and reporting bogus values back to the kernel. It's Amlogic you're dealing with.
The benchmarks @Da Xue did a while ago clearly demonstrate this: https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ (see the openssl numbers. If S905X would be running at 1.5 GHz as claimed the openssl scores need to be much better compared to RK3328, but this is an indication that the code running on the M3 Core simply does what it wants while cheating on the kernel and reporting wrong cpufreq clockspeeds while running lower in reality.)