Am 23.11.2016 um 18:32 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 23.11.2016 um 11:45 schrieb Grazvydas Ignotas notasas@gmail.com:
On Tue, Nov 22, 2016 at 10:49 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
- it shows that the thermal throttling makes clock OPP go down to 750/500 MHz,
sometimes in multiple steps
Hmm still using those TI unsupported low frequencies? I'd drop them just in case they have some problem, they must have had a reason to remove it from mainline.
Well, yes. And we have good reasons to add them... Initially it was to get the boards booted without freezes.
I have tested 6 of the new CPU boards with 1.0GHz and 1.25GHz only and I sometimes get a freeze even with the bash-loop which I didn't see with 500/750 included.
With 500/750/1000/1250 it seems as if the 4GB RAM boards have a slightly higher risk to freeze, but this is not statistically validated.
Anyways this would not be enough reason to keep the lower OPP even when we have fixed the freezes, because there is another effect:
The chips get hotter. During high-load they typically oscillate between 98° and 108° instead of 90 and 100°. The reason seems to be that even with thermal throttling to 1GHz (and not deeper) there is more average energy dissipated inside the chip and this results in a higher average temperature. Well, higher average performance as well :)
This may become a general problem: we might get it up to 1.7GHz peak clock rate by fixing the freeze issue, but thermal throttling might reduce the average clock rate to let's say 1.2GHz. Then it is the same as running them permanently at 1.2GHz.
Maybe, is this the reason why TI dropped the 1.7GHz specification because nobody can use it 100% of the time without overheating the chip even with active cooling?
Also the latest datasheet (swps051k) lists 1.014V as the lowest allowed voltage, I'd not ever go below that in tests like this as you may end up triggering several unrelated issues and then arrive to wrong conclusions.
I have not seen any problem with lower frequency OPPs so far and they significantly reduce power consumption in low-load situations.
So unless we really find a problem I think we better should keep them.
Anyways, having them reduces the 1.25GHz freeze risk a little for the tests I am running.
- since this OPP change also includes VDD-MPU changes (between 1.25V
and 0.85V) it shows that the Palmas regulation works fine
- what makes a really big difference is running the bash-loop vs. the NEON-loop
- high-load freezes almost immediately after switching from 1GHz to 1.25GHz
What about 1.2GHz? ED already announced 1.2GHz as fully working on the forums, but I fear it might actually not work with NEON.
Yes, it is likely that it fails at 1.20GHz as well. Maybe a little later than with 1.25GHz. I will try in the next run.
I have not seen any difference and most boards freeze quickly with 1.2GHz as soon as the NEON-loop is started.
Even at 1.1GHz I see freezes, but it seems to sometimes need a little more time.
So the "freeze-barrier" is somewhere between 1.0 and 1.1 GHz.
And it has small fluctuations between different boards. Some a little higher and some a little lower. This indicates indeed a hardware influence with statistical parameter variations of components. Anyways it is astonishing that these variations are so small and reproducible.
- it is indeed the Cortex A15 MPU/NEON core and not any peripheral on the OMAP5 SoC
A weird reason could still be that the DRAM interface is used differently/faster if we run NEON at >1GHz. But the EMIF DRAM clock is constant if CPU clock changes.
The test doesn't use memory at all, it operates on registers only, except repeatedly reading and writing to the same locations, which should always hit L1 cache.
OTOH now that I think about it, it might actually start doing writes after a task switch because ARM doesn't write-allocate cache. You can comment out lines with ldrd and strd instructions (add @ at the start of lines 24 and 29) and then there will be no chance for it to do RAM accesses, except kernel reloading the instructions after a task switch (after interrupts or whatever). This should rule out any RAM issue.
Ah, good to know! I will try that next and see if we have any differences. But anyways it becomes more and more clear that we only have a CPU issue and no peripheral or RAM.
Since this also has no observable influcene I think we have pinpointed the CPU cores - and their power supply.
I will now start to analyse/understand/experiment how to really fix it.
BR and thanks, Nikolaus