Folks,
Me and Nick have been back and forth with the IFC6410, using Linaro's utopic Ubuntu + 3.17 kernel, and I can now declare it stable enough to run toolchain tests, maybe not yet builds.
The reason is that the kernel, although stable, is only just because it throttles speed to a minimum. So, the core runs at 920MHz and the memory bus is at its minimum frequency. Nick gathers we could speed it up by a factor of 30% and 40% respectively while remaining on the safety zone.
However, that would still be not enough. Currently, the boards build LLVM in 7hs, when a Panda does it in 5h, a Chromebook does in 3.5hs and a Chrome2 in 2hs. Improving it by 85% would get us just under 4hs, which is still worse than a Chromebook. If we increase the CPU clock to 1.5GHz per core, we may get it fast enough (but still slower than the Chrome2), to be useful.
Their form-factor are better for rack-usage (remote serial, remote reboot, small footprint), so even being slower than Chrome 2s, they'll be faster than Chrome 1s and much more rack-friendly. That, of course, assuming they remain stable at 1.5GHz. Heating will be an issue, but we now have a decent server room and we can buy rack-mounted fans for them, if we need it.
In a nutshell, I won't give up on them just yet, but I won't speed up replacing the other boards with them either. We may have to wait a few more releases to be sure, but I'm not expecting anything going in production before February.
cheers, --renato
PS: Nick, if you want to increase the clock speeds now just to see what happens, I'm game.
On Thu, Dec 11, 2014 at 2:49 PM, Renato Golin renato.golin@linaro.org wrote:
The reason is that the kernel, although stable, is only just because it throttles speed to a minimum. So, the core runs at 920MHz and the memory bus is at its minimum frequency. Nick gathers we could speed it up by a factor of 30% and 40% respectively while remaining on the safety zone.
I have re-run my benchmark because i wasn't happy with what i had told you.. i had taken the 40% improvement from an early benchmark i did at low speed. so, i have executed the benchmark at 918Mhz instead. For reference, the benchmark is:
sysbench --test=cpu --max-requests=50000 --num-threads=4 --max-time=15 run
I don't know how good/bad this is as a benchmark.. but it seemed ok for my 2-cent benchmarking.
The benchmark report min/avg/max time it took to process 1 request during the test run.
At 918Mhz, using the vendor 3.4 kernel, i am seeing (in ms):
25.02/26.05/31.89
And with our current 'mainline' kernel, i am getting:
25.14/58.72/121.67
and it's quite consistent over multiple runs. So it's much more than 40% actually.. if we apply these ratios we get theoretical numbers that makes more sense... the ifc6410 should definitely be faster than panda..
cheers nico
On 11 December 2014 at 14:36, Nicolas Dechesne nicolas.dechesne@linaro.org wrote:
and it's quite consistent over multiple runs. So it's much more than 40% actually.. if we apply these ratios we get theoretical numbers that makes more sense... the ifc6410 should definitely be faster than panda..
Nice!
So, we can do this in two stages: first, we move the bus clock all the way up. Test. Then we move the CPU clock one step at a time. Test. Rinse, repeat.
We should find a comfortable and performing level somewhere between 1.2 and 1.5 GHz.
cheers, --renato
linaro-toolchain@lists.linaro.org
-
Nicolas Dechesne -
Renato Golin