No performance difference between 1.5, 1.75 & 2GHz

[TanteJu]

Exactly what do you expect HK should do about it? You want your money back?

Yes, why not?

Amlogic sells the S905 based SoC as 2ghz, this is in no way the fault of HK .

I didn't buy a bare "Amlogic S905 CPU" from Hardkernel, I bought a complete system (called the "Odroid C2").
Advertised like this:

[meveric]

I don't think Apple have ever said publicly how much RAM an iPhone has (see e.g. http://www.apple.com/uk/iphone-6/specs/ ).

You find specs on other pages, still it was just an example and can be transported to any company any phone or any similar setting.
An adverticed feature is not available "at the moment" cause someone screwed up a software component.
The result is not that the devices will be declared with different specs (which would be stupid since the devices DOES have different specs) but instead the faulty software is being fixed as soon as possible.
Since HardKernel is neither providing the Hardware (the SoC in that case) NOR the Software (Kernel comes from AmLogic as well and HardKernel just adds patches of their own on top).
HardKernel has to redirect the complains to AmLogic, and THEY need to fix that issue. Either by fixing the software. OR if it really turns out that is "impossible" they need to publicy announce that it's a 1536MHz SoC. HardKernel can't do that, they did not produce the SoC, they did not have manufacture specs. They just order the SoC which was said to be a 2.0 GHz SoC.

But ignoring that detail, I think that if Apple did something like this then they would quickly find themselves subject to a class-action lawsuit.

Highly doubt that. First of all it happens all the time.. follow the news around Apple one iOS update issue follows the next, non working WLAN, non working bluetooth and so on.. They just send another update and no one talks about it anymore. It happens.. It happens not only with Apple but with all companies. Google's Androids has just as much issues as well.

This is exactly what happened when the iOS 7 to iOS 8 upgrade reduced the amount of Flash storage available by about 25%: https://www.theguardian.com/technology/ ... d-capacity .

Actully that's something completely different. I would call it stupid, but it's very common around these days and most likely around the people who file such law sues.
Just if you think about it. You buy a device that cost $300 and it turns not out to be what you THOUGHT it would be and now you sue the company that sells these phones for $5m??
What kind of dumbshit is that? Why would anyone expect to get more back then the device is actully worth (except maybe a reasonable compensation for your trouble)? Cause people like drama and there are really dumb laws that allow for such stupid law sues!

A couple years ago I bought a Alcatel One Touch 997D smartphone. http://www.gsmarena.com/alcatel_ot_997d-5110.php
It's adverticed with a 4GB internal storage. Wanna know how much the device has free after I turned it on for the first time? 1.4 GB!
Means 65% less than advertices. You think anyone EVER sue that company for that? NO cause the company is not called Apple!

Passing the blame to a supplier isn't really acceptable, legally.

Actually it very much IS! That's what everyone does. Who do you think does Apple blame if something is not working on their phone? Do you really think they gonna blame themselves for not having things planed and tested more intensly before they send out a new iOS patch or a new phone that bends when you put pressure on it, or where the touch screen fails after a while in million of devices?
They gonna blame their suppliers!
YOU might not blame the suppliers. YOU might (and can) complain about the company that sold you the product. But that company instead WILL blame their suppliers in the end!

Exactly what do you expect HK should do about it? You want your money back?

Yes, why not?

Amlogic sells the S905 based SoC as 2ghz, this is in no way the fault of HK .

I didn't buy a bare "Amlogic S905 CPU" from Hardkernel, I bought a complete system (called the "Odroid C2").
Advertised like this:

Obviously this adverticement is from pollin.de. So if you bought that device from there, the only one you can blame for anything is pollin themselves. Cause for pollin HardKernel is also just a "supplier"
You blame the one you bought it from, they blame the one they got it from. That's the way it is.
In the end you will have paid for shipping and handling, to get your money back and even if you get your money back in full, in the end they might just publish a patch that fixes everything and you just wasted huge amount of time and effort just to vent some hot air!
But it's your right to ask for compensation, and if you want to go to court for it, you probably will get right.

[endecotp]

meveric, I'm curious to know where you live. Is it a place with much less consumer-protection law than the rest of us?

[rooted]

meveric, I'm curious to know where you live. Is it a place with much less consumer-protection law than the rest of us?

You must live in Britain, the US is MUCH more laxed in this area.

[meveric]

oh no, in fact we have very high customer protection over here.. If I order something online over here I have two weeks of sending it back without any reason if I want to. Same if someone comes to me and talks me into signing a phone contract or a magazine contract (or anything like this) on the street. I can nullify this two weeks after I realized how dumb I was in doing so

I'm not talking about not getting your rights. If it turns out that the device is really just capable to do 1.5 GHz then people can think about what they can do about compensation.

But currently nothing is confirmed, HardKernel bought the SoCs from AmLogic. They adverticed them as 2GHz and just shortly ago we discovered that's not true. Now the only thing we can do is wait for the reaction of AmLogic. Maybe it's a simple software fault and a different u-boot, or a Kernel fix solves this issue.
If that's not the case, then we should think about compensation.
For all we know currently it's a "BUG" nothing more, nothing less. If it turns out to be a bug that can not be solved, you can think about what to do next.

It's not like that the board suddenly stops working cause it can't do 2GHz.
No one noticed it for months, so apparently no one missed it up to now and suddenly everyone acts like the world is gonna end cause of this.

I'd say let's wait and see what AmLogic comes up with. It's their product, they messed it up, HardKernel depends on their reaction and with that so do we.
If it turns out it's a hardware issue and can't be solved, HardKernel is forced to change their product description as well as has to think about compensation for people that are upset cause of this.
But until that point (or at least until we have waited a resonable time for response and reaction for them to fix the issue) we should just let HardKernel handle the issue and let them press AmLogic.

[rooted]

It's not like that the board suddenly stops working cause it can't do 2GHz.
No one noticed it for months, so apparently no one missed it up to now and suddenly everyone acts like the world is gonna end cause of this.

I'd say let's wait and see what AmLogic comes up with. It's their product, they messed it up, HardKernel depends on their reaction and with that so do we.

That's what I was trying to say, the C2 performs so well at 1.5ghz that there is little to no reason to get all butthurt about it. Do I want 2ghz...sure I do, but I'm not going to flip out if it ends up not being possible. It certainly isn't HK fault, this is all Amlogic. If it turns out to be a design flaw Amlogic should reimburse HK for each SoC purchased and then HK can dole out monies to dissatisfied owners upon request.

One person did notice, but through testing not due to lack of performance.

And where do you live that you have such freedom to return things? I know it's Europe, Germany I'm guessing. In the US we have no such thing, we can simply complain to the BBB which is unlikely to help resolve anything.

I think 30 days is an appropriate amount of time to find out if it's something that can be resolved in software. I've asked someone that I believe has a S905 based Wetek to verify this issue on that device, hopefully they have one and will test and let us know.

[Snk]

I certainly would return my C2 to HK.
Once I bought a product with a particular specification and received another below it.
Although HK bought the soc's the Amlogic is the right thing to do.
I just hope that this is just something with kernel or u-boot and is easy to get around.
Once the kernel is currently used 3.1xx very old and probably will not be updated to 4.xx.
Or will some developer is already updating the kernel to 4.x?

[meveric]

And where do you live that you have such freedom to return things? I know it's Europe, Germany I'm guessing. In the US we have no such thing, we can simply complain to the BBB which is unlikely to help resolve anything.

Yep, we have very good customer laws.. In Germany even for "USES" HardWare you have a warranty of AT LEAST 6 months.
If I go into a PC store and buy a used PC, and it breaks down after 3 months, I can bring it back to where I got it from and they either have to replace it or to give me my money back.
Also many stores don't even look at the warranty. If you bring back an item they take it back without asking.

But hey Americans have a habit to get compensated for their own stupidity
Sueing a company cause they did not put "warning hot" on their HOT COFFEE mugs, and then getting several hundred thousands dollars as a compensation?
In Germany a court would ask you if you're stupid, and the only compensation you would get is if you're really stupid and someone neglects their mission to overwatch you and cause of that you were able to do something stupid like trying to sue someone for your stupidity.

[koschi]

Well, I opened this thread, but actually didn't expect that much feedback

With plenty of other manufacturers producing S905 based Android boxes, that are being advertised at "up to 2GHz", I don't think HKs is at fault.
Maybe it could have been discovered through more thorough QA, but hey, shit happens, this could have happened in our F500 company as well.
Usually you don't care for benchmarks at less then 100% speed, only the latest and greatest software levels, tuned but not 101% stable drivers, undocumented settings, etc...
The more scores, points, SAPs, the better. But who cares or tests for performance at just 75% of the clock speed?!?
I usually wouldn't do either, but that article of Willy Tarreau made me want to confirm it. Well, he was right, lets find out why...


The question is just, whats next?
Will Amlogic provide a fix, or just ignore the problem? In that case I'm certainly not going to buy any Amlogic based product, ever again.
I do love love my C2s for their stability, easy cooling and recent SW environment. HK had other successful boards with different chips before as well, no such severe issue like this one was found though (from what I got starting late in ARM). I would definitely be up for future boards as well, but certainly not Amlogic ones...

[rooted]

I do wonder if the S905H was to fix this issue.

[TanteJu]

One person did notice, but through testing not due to lack of performance.

Confused. Are you talking about VW - or HK?

And where do you live that you have such freedom to return things? I know it's Europe, Germany I'm guessing. In the US we have no such thing, ...

Wait what? It was in the US where VW was sued for billions of dollars.

But hey Americans have a habit to get compensated for their own stupidity

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[rooted]

One person did notice, but through testing not due to lack of performance.

Confused. Are you talking about VW - or HK?

And where do you live that you have such freedom to return things? I know it's Europe, Germany I'm guessing. In the US we have no such thing, ...

Wait what? It was in the US where VW was sued for billions of dollars.

But hey Americans have a habit to get compensated for their own stupidity

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What is your infatuation with VW? Do you own a diesel powered VW?

[brad]

Firstly I think we need to give HK some more time to investigate a reasonable solution to the issue, which I believe they are actively looking into.

Secondly the C2 is advertised as a fanless board operating at 2GHz CPU speed and this is what a customer would expect, anything less is false advertising, be they aware of it or not. amlogic might be the producers of the CPU and might even be at fault but hard-kernel sell and market the device making them responsible.

In Australia false advertising is against the law and the consumer is entitled to a full refund and or compensation.

[mlinuxguy]

I'm still enjoying my C2's even at 1.5ghz and no overclocking available
However, when a company such as ARM or Amlogic hides sections of the startup configuration and code in signed binary blobs its up to them to make that code perfect.

The assistance of many opensource developers solving such problems is prevented by such an approach. I understand the need to protect IP (such as codecs), but I also see how the RPI + Broadcomm approach allows clock frequency and voltage control through a config.txt file in the boot subdirectory. This at least exposes the board to some level of tweaking, testing, and pushing the board limits.

In the previous issue of thermal throttling it took HK/Amlogic about 2 weeks after identification of the problem to come up with a fix (new thermal tables and PWM driver). The s905 design is assembled from standard ARM IP blocks, assuming they didn't screw something up in the IP block layout such as missing a clock line/divider/ or some such hardware bug, then a bog standard ARMv8 should overclock if you have access to the signed binary blobs.

I would like to see the C2 and subsequent boards support overclock via boot.ini Its nearly what config.txt does for the RPI but missing all the clock control
ref RPI3 overclocking http://www.jackenhack.com/raspberry-pi-3-overclocking/

If they had supported config.txt like clock frequency settings I would have found the issue back in beta with this board when I was trying to overclock.

[TanteJu]

Do you own a diesel powered VW?

No. Do you own an Amlogic powered Odroid?

[afremont]

I agree with what Brad said. I personally think it's okay that it doesn't meet specs right now, but in the long run amlogic needs to fix it or own up to it and change the marketing to reflect the truth of the matter. I don't think hk is directly to blame, but they probably should have noticed it.

I disagree with the poster that said this wasn't noticed because of lack of performance, because that's exactly how it was found. A 25% reduction in clock speed is significant.

Sent from my Moto G (4) using Tapatalk

[rooted]

Do you own a diesel powered VW?

No. Do you own an Amlogic powered Odroid?

Yes I own 4.

[rooted]

I disagree with the poster that said this wasn't noticed because of lack of performance, because that's exactly how it was found. A 25% reduction in clock speed is significant.

In what real world application would you notice this, ARM performance varies so much it's not possible to know. Even two different devices running the exact same SoC performance can vary by 25%. Especially when you take into account thermal throttling.

Similar to the XU4, the big cores being 2ghz doesn't increase performance. I downclocked to 1.6ghz to run with no fan and it takes the same amount of time to compile the Linux kernel that it did with the fan and top speed set to 2ghz.

The S905 will overheat at 2ghz and depending on how it reacts it could actually be slower.

Did Samsung get sued over the international S5 overheating and downclocking, no because it is 2ghz although isn't really usable.

The C2 originally overheated, perhaps originally it was doing 2ghz and this is part of the 'fix'. Pure speculation of course.

Unless a device is advertised as 2ghz STABLE it certainly isn't false advertising. No one advertises like this since it would cause them to be in an actionable position in many countries.

But being locked at 1.5ghz is different of course, that means it isn't 2ghz as advertised.

[afremont]

Since you asked, I'm thinking any CPU bound process, especially one that fits inside the cache is suffering a 25% performance penalty. I could be wrong, but I'd need someone to tell me why. Software decode and encode of media, data compression and decompression, even aircrack-ng fits into the realm of real-world applications that are not getting what they thought.

"Similar to the XU4, the big cores being 2ghz doesn't increase performance. I downclocked to 1.6ghz to run with no fan and it takes the same amount of time to compile the Linux kernel that it did with the fan and top speed set to 2ghz."

I'm not sure that Kernel compilation is a fair way to benchmark this, since that's about as I/O bound as you can get.

"Unless a device is advertised as 2ghz STABLE it certainly isn't false advertising. No one advertises like this since it would cause them to be in an actionable position in many countries."

They do claim 2GHz fanless operation so that's quite a claim to be making if you're throttling the CPU just to keep it cool enough to run without a fan. I'm not quite seeing any truth in advertising with that claim.

The real problem is that I (and I'm sure others) chose this platform because of the wide margin in core speed between the C2 and the Pi3. At 1.5GHz, there is no more wide margin. I still like the C2 (despite the current lack of VPU support by Amlogic), but I'm real curious to see how this all plays out in the end. Personally, I'd rather see the CPU throttle at 2GHz rather than be unalterably limited to 1.5GHz by a binary blob. At least then, I could put a better sink and fan on it and get more performance. Just trying to have some rational civil discourse here, not start or participate in a flame war.

[rooted]

The real problem is that I (and I'm sure others) chose this platform because of the wide margin in core speed between the C2 and the Pi3. At 1.5GHz, there is no more wide margin. I still like the C2 (despite the current lack of VPU support by Amlogic), but I'm real curious to see how this all plays out in the end. Personally, I'd rather see the CPU throttle at 2GHz rather than be unalterably limited to 1.5GHz by a binary blob. At least then, I could put a better sink and fan on it and get more performance. Just trying to have some rational civil discourse here, not start or participate in a flame war.

I agree with everything you said here.

I also agree kernel compilation isn't the best metric, it's just the most intensive thing I personally do.

You are wrong about the performance margin, the benchmarks you have most likely seen for the C2 compared to the Pi 3 have been made while the C2 was bound @ 1.5ghz. If you didn't research performance between the two and based your purchase on clock speed alone I stand corrected.

They do claim 2GHz fanless operation so that's quite a claim to be making if you're throttling the CPU just to keep it cool enough to run without a fan. I'm not quite seeing any truth in advertising with that claim.

All SoC thermally throttle, so I disagree.

[meveric]

They do claim 2GHz fanless operation so that's quite a claim to be making if you're throttling the CPU just to keep it cool enough to run without a fan. I'm not quite seeing any truth in advertising with that claim.

All SoC thermally throttle, so I disagree.

I also disagree with that statement. 2GHz "fanless" can also mean "2GHz" burts for a few seconds tops like it's with the Qualcom 810 processors before it throttles a lot.
That's actually very common in cellphones.

[afremont]

I also disagree with that statement. 2GHz "fanless" can also mean "2GHz" burts for a few seconds tops like it's with the Qualcom 810 processors before it throttles a lot.
That's actually very common in cellphones.

I understand, but that's not what appears to be happening here. It appears that the processor isn't even being allowed to exceed 1.5GHz ever, not even in bursts. If that's the case, how can it be acceptable to claim that it runs at 2GHz? That said, I probably shouldn't have used the word "throttled"; maybe I should have said "arbitrarily locked". My original point being that it appears that the Amlogic provided "binary blob" is not allowing (by error or intention) the clock to even get to 2GHz, ever.

I understand that any high speed CPU that heats to some manufacturer pre-determined temperature level will slow down automatically to prevent thermal overrun, that's a hardware thing. Given that phones don't even have room for a decent heat sink and extremely poor (nonexistent) ventilation, it's not surprising that they would do that quite often.

According to the datasheet that was released, on page 36 the maximum Tj (junction temperature) is 125C. Has anyone seen anything even close to that yet? 65C or 70C is simply not that hot by today's standards, but that's the highest reported numbers that I can recall seeing on the forum. Since the temp sensor is actually inside the die, it seems to me that we aren't even close to having a valid reason for restricting the clock to 75% of the advertised rating.

[rooted]

According to the datasheet that was released, on page 36 the maximum Tj (junction temperature) is 125C. Has anyone seen anything even close to that yet? 65C or 70C is simply not that hot by today's standards, but that's the highest reported numbers that I can recall seeing on the forum. Since the temp sensor is actually inside the die, it seems to me that we aren't even close to having a valid reason for restricting the clock to 75% of the advertised rating.

Initially some were seeing temperatures in the 100+ range and it was causing the device to lock up, HK worked with Amlogic to resolve the problem.

That's what I was referring to earlier, about that Amlogic fix perhaps limiting the CPU speed to 1.5ghz either intentionally or accidentally. We would need the original files to test if the C2 was initially capable of 2ghz before the fix.

Also there are three revisions to the C2, few of us have the first revision. I wonder if all three have this issue. I haven't been home in a week so I haven't been able to test the revision I have.

*edit*
I'm wrong, the C2 wasn't reporting that it was 100C

I do know the thermal testing mlinuxguy did the temperature of the C2 did increase at the 2ghz frequency but I don't think he differentiated the results enough to tell if the board was indeed hitting 2ghz.

[crashoverride]

The C2 originally overheated, perhaps originally it was doing 2ghz and this is part of the 'fix'. Pure speculation of course.

I also wondered if using the original released image would show 2Ghz performance. Perhaps someone should test that. My recollection of the issue was that is was not an overheating issue at all. Rather, it was a 'stepping' issue. The board ran fine until the governor requested a stepping decrease. The step itself causes the problem as the temperature was comfortably below the maximum operating threshold.

They do claim 2GHz fanless operation so that's quite a claim to be making if you're throttling the CPU just to keep it cool enough to run without a fan. I'm not quite seeing any truth in advertising with that claim.

The real problem is that I (and I'm sure others) chose this platform because of the wide margin in core speed between the C2 and the Pi3. At 1.5GHz, there is no more wide margin.

The "grass is not greener" for RPi. There are threads on their forum showing that device needed firmware (super secret hidden binary blobs also) adjustments to the operating performance characteristics. There are also angry mobs with pitchforks and torches there too. They just delete the posts.

[rooted]

The C2 originally overheated, perhaps originally it was doing 2ghz and this is part of the 'fix'. Pure speculation of course.

I also wondered if using the original released image would show 2Ghz performance. Perhaps someone should test that. My recollection of the issue was that is was not an overheating issue at all. Rather, it was a 'stepping' issue. The board ran fine until the governor requested a stepping decrease. The step itself causes the problem as the temperature was comfortably below the maximum operating threshold.

You're 100% correct, I was just reading over that topic.

I'm open to being wrong, happens all the time

@mlinuxguy
Do you care to speculate if the fix had anything to do with what we are seeing?

*edit*
You already did in this thread.

[rooted]

Crashoverride, could you run sysbench and test your results against these:

http://forum.odroid.com/viewtopic.php?p=127163#p127163

This is a quick way to see if we had 2ghz initially since mlinuxguy and odroid did this in February when we first got the C2

[crashoverride]

It would be better if someone else did it. My boards are configured for development and often have custom kernels and configurations. I tried keeping a "spare" C2 with stock configuration for testing, but I always end up using it for something else.

[rooted]

No worries I should be home tomorrow and can test it.

[mlinuxguy]

Here is where things get "interesting"
These are graphs of my beta board prior to the thermal fix and after the thermal fix
Prior: http://forum.odroid.com/viewtopic.php?f ... 50#p131261
(enclosed in a tight box with lid and small heatsink)
I did nothing to check the real clock frequency back then, just drove the CPU's as hard as possible to the thermal limits

Post fix: http://forum.odroid.com/viewtopic.php?f ... 50#p134007
Notes: all these tests were on my beta board, I've never tested my other 2 new ones in this manner.

The "interesting" part is
(1) I was testing a beta board (I thought it was just PCB revisions that changed later not CPU)
(2) I never checked instruction retirement rate at each clock freq
(3) What was it throttling down to in those tests if it was locked at 1.5ghz? (note: it could go below)
(recall it goes 2ghz, 1.7ghz, 1.5ghz, etc..) the temp does drop at the supposed 1.7ghz (could it be dropping due to under-volting?)

It should be a simple matter of finding an early C2 image (pre-thermal fix), and re-testing
I think the images here should be pre-thermal patch: http://www.odroid.in/mirror/dn.odroid.com/S905/Ubuntu/ (Date is Feb 4th 2016)

Speculation part (to be updated after tests)
To see if It's possible that the thermal fix broke the higher clocks, we need to deduct what can be guessed of the black box.
Recall there were 2 parts to the fix:

"We've updated C2 thermal throttling to fix the overheat and crash problem under high temperature
by adjusting VCCK/VDDEE voltage table (including PWM driver) according to each frequency level and modifying trip-point, cooling-map and min_state of thermal-zones."

We found the PWM driver for the DCDC converters was not correctly implemented. It causes the hang state with the over-heating problem.

That reads like a normal fix to the voltage table, however the PWM fix was needed since it was causing our lockups when the frequency was changed.
I would expect the voltage table to be either linear or their values chosen to be close enough, so I would ignore the volt table change. It would typically only effect stability anyway.
However the PWM fix is interesting. This was needed as it was locking up the processor on a clock change. Now the question is what kind of PWM driver is this? It doesn't drive the processor clock since that's from a PLL, so it likely drives the voltage as requested by their updated voltage table.

The Amlogic S905 PDF states it uses DVFS to achieve 2ghz

"full-blown DVFS requires complex voltage regulators and PLL or DLL circuits"

Google search

"Multiple internal PLLs for DVFS operation"

amlogic PDF

The S905 PDF section 22.2 shows the clock trees and 2ghz as needed to divide down to get 50mhz for Ethernet. So a 2ghz PLL clock does exist, plus the next table shows all the divide down frequencies that exist "Assuming 2ghz fixed source clock". If those didn't work all sorts of problems would happen to various subsections
What we do not see from the s905 PDF are the "hidden variables" i.e. the binary blob and M3 controller links to the processor clock generation PLL.
Given they mastered the other clocks PLL's and dividers, my guess is the M3 interaction with processor clock generation is broken. Code wise or worse, hardware. It's probably very complex and prone to errors.

Short answer is I doubt the thermal fix is related to this issue

[rooted]

Number 3 is what had me really interested when looking at your data earlier.

I knew you were driving the board hard for thermal testing and wasn't testing per frequency thermals but I noticed the temperatures seemed to indicate we originally had the 2ghz slot.

I tried to look at all the threads related to initial C2 tests but there are so many posts in various threads, I had hoped to find two benchmarks or tests that would shed some light.

[mlinuxguy]

Number 3 is what had me really interested when looking at your data earlier.
I knew you were driving the board hard for thermal testing and wasn't testing per frequency thermals but I noticed the temperatures seemed to indicate we originally had the 2ghz slot.

My theory right now (till i get a chance to sleep on it) is that we are "under-volting" the processor to account for the temperature drops.
If the processor has its voltages cut to the lower value associated with their 1.7ghz table entry then the temperature should drop....
I guess driving the S905 at higher voltages than necessary for a real PLL clock of 1.5ghz would be ok if the S905 can really handle 2ghz...

The frequency/voltage table would look something like this:
(totally made up numbers)
2.0ghz = 1.4v
1.7ghz = 1.2v
1.5ghz = 1.1v
So its cranking along at a supposed 2ghz (really an over-volted 1.5ghz) and we hit thermal limit, so it moves down the table to 1.7ghz and outputs 1.2v to the S905
Now 1.7ghz is still really 1.5ghz so the processor retires the same instructions per interval but now is much cooler at a lower voltage.

Working theory so far anyway...
Note: it's over-volting the processor when the PLL is still 1.5ghz, but you are driving the CPU with the 2ghz voltage value
As the frequency drops from 2ghz you are just moving the voltage driving the processor down into the correct range for 1.5ghz.
When you hit 1.5ghz their tables should be correct all the way down to the lowest frequency.

Edit: Something that would be a silver lining here is that they could clip the voltage values for frequencies higher than 1.5ghz to all be the same as the voltage for 1.5ghz and we would save power and have cooler systems! Nothing but a signed binary blob change by HK!
Assuming it can't be fixed and we want something positive

[meveric]

I just tested my Debian Jessie image from 10th of March 2016 (pre-thermal patch - Kernel build from 3rd March 2016)
Using a fan to keep the temperature low and sysbench as written in the first post to test (avg of 4 runs)
I got the same results as on the first post with no differences between 1.5GHz and 2.0GHz.

I watched temperature, it never went above 38°C and that is with nearly 30°C room temperature right now *sweat*

So this bug is around for quite a while already.

[rooted]

Which revision C2 meveric?

[meveric]

That was the rev 0.2 board. My rev 0.1 board is being backuped for the next couple hours
But I think at least with the current Kernel there is no speed difference on 0.1 either.

[odroid]

Please don't waste your valuable time.
All the Coretex-A53 based Amlogic SoCs have the same issue. S905, S905 Rev-C(S905H), S905X and even S912.
The kernel clock frequency 1.75 and 2Ghz do not exist in the BL3x blobs.
It must be Amlogic's fault. But we should detect it earlier in our internal development stage. Really sorry about that mistake.

We've been modifying/testing the BL3x code to find a maximum feasible/stable clocks like 1.53Ghz, 1.58Ghz, 1.61Ghz, 1.65Ghz, 1.68Ghz, 1.71Ghz, etc for a couple of weeks.
But 1.65Ghz seems to be the maximum one due to some power and heat issues. We will run the burnA53 on Ubuntu and the Stress app on Android with 10 set of C2 boards in this weekend (for 48 hours stability test) to make sure it.
Once we will have a test result, we will report it on this thread with update package for further sampling test in early next week.

If we disable two cores, the SoC can run up to 1.75Ghz probably. But we need further stability test too.
And yes. I fully agree most people don't like this approach.

Anyway, we know well 1.65Ghz or 1.75Ghz is still very far from the 2Ghz. So we will change the C2 specification in our home page next week as per the test result.
And we must consider some compensation for C2 users. But we need to check what we can do first.

Please accept my sincere apologies for the mistake and kindly understand our situation.

[mlinuxguy]

Thanks for the information Odroid
Keep in mind there should be some "binning" that can be done by individual users (some CPU's could clock higher).
You also have many in the community that would be perfectly willing to do active cooling so it would be great if you could add
1.68Ghz and 1.71Ghz as some over-clock for us willing to do active cooling.

This would only be feasible if you have some way for us to choose the over-clocked speeds. The normal max would remain whatever you determine the
max feasible clock under passive cooling.
Please consider what I mentioned earlier about adding this feature to boot.ini, A volt/freq entry commented out for the normal
user with a comment above it showing sample over-clocks

I have 2 of my odroid-c2's with slightly cut-down giant northbridge coolers that could potentially go higher than what you are finding stable.
assuming of course its temperature that is setting the limits and not issues with clock-line stability

[crashoverride]

All the Coretex-A53 based Amlogic SoCs have the same issue. S905, S905 Rev-C(S905H), S905X and even S912.

Intel Core processors have this same problem except they call it the "Turbo Boost(tm)" feature.

So if possible, I would recommend:
1 core @ 2.0 Ghz
2 core @ 1.75 Ghz
4 core @ 1.5 Ghz (or 1.65 Ghz if its stable)

For what its worth, this issue has no impact on my use of the C2 since my workloads are bound by factors other than CPU.

[Snk]

Please don't waste your valuable time.
All the Coretex-A53 based Amlogic SoCs have the same issue. S905, S905 Rev-C(S905H), S905X and even S912.
The kernel clock frequency 1.75 and 2Ghz do not exist in the BL3x blobs.
It must be Amlogic's fault. But we should detect it earlier in our internal development stage. Really sorry about that mistake.

We've been modifying/testing the BL3x code to find a maximum feasible/stable clocks like 1.53Ghz, 1.58Ghz, 1.61Ghz, 1.65Ghz, 1.68Ghz, 1.71Ghz, etc for a couple of weeks.
But 1.65Ghz seems to be the maximum one due to some power and heat issues. We will run the burnA53 on Ubuntu and the Stress app on Android with 10 set of C2 boards in this weekend (for 48 hours stability test) to make sure it.
Once we will have a test result, we will report it on this thread with update package for further sampling test in early next week.

If we disable two cores, the SoC can run up to 1.75Ghz probably. But we need further stability test too.
And yes. I fully agree most people don't like this approach.

Anyway, we know well 1.65Ghz or 1.75Ghz is still very far from the 2Ghz. So we will change the C2 specification in our home page next week as per the test result.
And we must consider some compensation for C2 users. But we need to check what we can do first.

Please accept my sincere apologies for the mistake and kindly understand our situation.

Hey buddy, even with the addition of an active cooler on the processor, it is not possible to achieve this frequency of 2Ghz?
I believe most here, have the condition to enter your system, a fan on the heatsink.

[Bl4ckD0g]

Please don't waste your valuable time.
All the Coretex-A53 based Amlogic SoCs have the same issue. S905, S905 Rev-C(S905H), S905X and even S912.
The kernel clock frequency 1.75 and 2Ghz do not exist in the BL3x blobs.
It must be Amlogic's fault. But we should detect it earlier in our internal development stage. Really sorry about that mistake.

We've been modifying/testing the BL3x code to find a maximum feasible/stable clocks like 1.53Ghz, 1.58Ghz, 1.61Ghz, 1.65Ghz, 1.68Ghz, 1.71Ghz, etc for a couple of weeks.
But 1.65Ghz seems to be the maximum one due to some power and heat issues. We will run the burnA53 on Ubuntu and the Stress app on Android with 10 set of C2 boards in this weekend (for 48 hours stability test) to make sure it.
Once we will have a test result, we will report it on this thread with update package for further sampling test in early next week.

If we disable two cores, the SoC can run up to 1.75Ghz probably. But we need further stability test too.
And yes. I fully agree most people don't like this approach.

Anyway, we know well 1.65Ghz or 1.75Ghz is still very far from the 2Ghz. So we will change the C2 specification in our home page next week as per the test result.
And we must consider some compensation for C2 users. But we need to check what we can do first.

Please accept my sincere apologies for the mistake and kindly understand our situation.

Thanks for the information!
Always good to receive "official" information while we were speculating about what it could be.

For the Amlogic side... it's a shame (same as VW).
It looks like cheating. There's no other word for this.
Hope you consider a "best class" and transparent supplier for a XU5 or a C3 when they come out.

And looking forward for the next information and steps...

[afremont]

I'm satisfied. I think hardkernel has done what they need to do. Maybe they should have discovered this during evaluation, but mistakes can happen especially when you can't get a complete datasheet.

That said, I'm not the least bit impressed by amlogic on this. This appears to be no mistake, it seems to be little more than misrepresentation IMNSHO.

The C2 is still a decent platform and I won't be wielding any torches or pitchforks because of this. I will be a little more skeptical of amlogic marketing claims from here on out.

These part vendors all need to spend a little more effort on engineering and much less on marketing and datasheet secrecy.

Sent from my Moto G (4) using Tapatalk

[endecotp]

If the BL3 (etc) blobs were open-source.........

[mlinuxguy]

Intel Core processors have this same problem except they call it the "Turbo Boost(tm)" feature.

So if possible, I would recommend:
1 core @ 2.0 Ghz
2 core @ 1.75 Ghz
4 core @ 1.5 Ghz (or 1.65 Ghz if its stable)

This statement brings to mind what I suggested back in this thread on Feb 16th
http://forum.odroid.com/viewtopic.php?f ... 38#p125407
TLDR -->

Optional extra: Turbo-Boost mode
This occurred to me after running across the boost mode frequency support in the C2's kernel.
We could add a turbo boost frequency and temperature, if the temperature max is hit it will drop
out of turbo mode into its normal frequency set.
To do this we would still need the S905 tech manual to create code to overclock the CPU's
We could set the Turbo frequency, voltage, and max temperature in the device-tree, if its
not there, then there is no turbo mode.

Here is my updated idea
(1) HK implements overclock tables, but sets the max to whatever is determined stable, call it 1.6ghz for now
(2) We as a community in conjunction with HK look into the turbo boost code in the kernel and implement it
(3) The goal would be a turbo boost mode that disables additional cores as the clock frequency climbs, at some tbd mystical max you are running on 1 core

Alternative idea
Simply implement the ability to over clock via boot.ini and another row for the # of active processors.
We the community can then control how our boards boot, their max clock, and max number of active cores

That would also allow the adventurous among us to do silly things like immerse C2's in mineral oil or liquid nitrogen....

[rooted]

And we must consider some compensation for C2 users. But we need to check what we can do first.

Please accept my sincere apologies for the mistake and kindly understand our situation.

I hope Amlogic will step up but seems they knew about this already and kept quite. I'm sorry to hear this, I know some may want to blame HK but it isn't your fault.

Do you know if the S905H has this issue?

[mlinuxguy]

Do you know if the S905H has this issue?

All the Coretex-A53 based Amlogic SoCs have the same issue. S905, S905 Rev-C( S905H ), S905X and even S912

The s905h is listed

[rooted]

Do you know if the S905H has this issue?

All the Coretex-A53 based Amlogic SoCs have the same issue. S905, S905 Rev-C( S905H ), S905X and even S912

The s905h is listed

Thanks, don't know how I missed that. Seems like Amlogic is in for a shiat storm.

[Snk]

Unfortunate ... I see that I will sell my C2 and will leave for XU4 .
This decrease in performance is pretty damning . I imagine the image Amlogic thereafter.

Enviado de meu SM-G900M usando Tapatalk

[rooted]

Unfortunate ... I see that I will sell my C2 and will leave for XU4 .
This decrease in performance is pretty damning . I imagine the image Amlogic thereafter.

Enviado de meu SM-G900M usando Tapatalk

What decrease in performance?

The device isn't 2ghz but the performance numbers haven't changed, matter of fact they will increase some once HK releases an update.

[koschi]

@Hardkernel

Thanks for picking this up and taking it seriously!

My C2 are slightly actively cooled, I'd certainly vote for an option for individual overclocks as well.
Right now in the hottest part of summer here and under full BOINC load (4x100% CPU), I have temperatures between 53 and 72°C (this one doesn't get much air ). With improved cooling I could get all to mid fifties °C and would appreciate the opportunity to tune each C2 to its own maximum...

[Snk]

Seeing it this way ... Once the clock is 1.5Ghz , a correction that HK launch , performance can increase. Certainly not blame HK , since even Android Box are disclosed as 2Ghz .

Enviado de meu SM-G900M usando Tapatalk

[mlinuxguy]

It occurred to me that the default clock sits at the fake "2ghz" meaning its being driven by higher voltages than necessary
I wonder if this translates into any power savings when they reduce the default clock table to max 1.5ghz (or whatever it ends up being).

An easy test would be for us to measure the power consumption of an idle C2 with the frequency set to "2ghz"
# cpufreq-set -u 2016000

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
2016000
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
2016000

Measure the power draw of the C2
Keep in mind its being over-driven by higher voltages than necessary for the real 1.5ghz

Redo the power measurement after setting it down to 1.5ghz
# cpufreq-set -u 1536000

Its possible we would be saving a bit of power by driving the CPU at the proper voltages for its real 1.5ghz
It should idle cooler too

Update:
My Killawatt meter isn't very sensitive, but at the fake "2ghz" it pulled 8watts, while at 1.5ghz it pulled 7 watts
I tried to get a USB LCD power meter in between with a 2amp USB charger powering it but the C2 wouldn't boot, just blink lights.
So if anyone has a more sensitive power meter setup they could see more detail, but it does appear about 1 watt +- something is being drawn with the
fake "2ghz" voltage setting versus the 1.5ghz voltage setting

Update #2
It might be better to test the C2 at full load on all 4 cores instead of idle. Measure the power draw at both fake "2ghz" and 1.5ghz