Massman

For now it's just in a test bios, but coming soon in public versions I guess. Good to see MSI catching up! :celebration: Thanks to Pt1t for the pic!

WR is the group record. On Monday we'll post the target scores for each WR to make it more clear for everyone. The WR prize is awarded to the person who has the WR at the end of the competition, not the first to break it.

United Overclockers is closing in on KPC#2. Also in the overall ranking ... nice!

Ranking is live! Hit refresh to see updated score rankings!

I have been looking at the possibilities of integrating ARM devices on HWBOT. The biggest problem at this moment is proper hardware detection. Looking at what Futuremark did for their 3DMark, that is not acceptable. It seems they just look for the device information, match it to a device in their database, and then relay that information to the user in the benchmark UI. This Hardkernel Odroid is not in their database, so simply no information about the specs is provided. Not good, and I now understand why they do not have ORB-support (individual pages for each score) for the ARM version - they can't show accurate system information. Playing a bit with the CPU-Z for Android, as well. Mine's dump #14322. This one is a lot better at detecting the system information, although it does not recognise I'm running an Exynos4 SoC. It says Cortex-A9, which is correct, but on the Samsung Galaxy S3 it says Exynos. That makes me believe they also do some ad hoc analysis of the hardware components. CPU-Z can accurately read the CPU frequency, though, which is good. It doesn't display any information on the current GPU frequency, so that's a little less good. All in all, the biggest problem of hardware detection is still present. Something that may hold us back in building rankings for the ARM devices .

MOA Qualifer prize provider <=> MOA Final HW provider

http://forum.hwbot.org/showthread.php?t=82702 If you clock "compare on HWBOT", the score will be submitted automatically!

Android is just an OS, and 3DMark is just one of the benchmarks we can run to see how performance is scaling when overclocking. I need to run Linux for HWBOT Prime, but that's an adventure for later. Honestly speaking, this ARM overclocking is a lot more fun than I anticipated. It's very different from the "usual" overclocking we do, and it reminds me a lot of those early days some people love to reminisce about. Nothing is a given with these devices, and most of the performance gain comes from extensive usage of Google Search and reading hundreds of forum posts. At best, you end up with a ready-to-flash kernel that provides you with a couple of overclocking options. But as far as I can see, no one has pushed the Exynos4 to its limits performance wise. I haven't found any research in base clock frequency overclocking, no research in dram overclocking, let alone bus overclocking. For all the people that say over and over again that "the past used to be better", well ... the past is back. Oh, here are my new top scores with 1920arm, 800mali. 1920mhz is more stable, so it's easier to finish the benchmark. I think it might be more heat than voltage related.

Maybe you get 300K on Ice Storm

Fixed it!

http://www.msi-moa.com/index.html

Haha, well ... it doesn't involve more than just editing a config file and then follow a "compile kernel" how-to. No need to take your hat off for that. Also, I lost the functionality of the on board LAN port. So that's definitely not good. Anyway, I've figured out how to change the CPU frequency and voltage. Was able to create a 2.1GHz - 1.5V setting, and select it in OS. But it's very unstable (which is a great indication that the frequency is actually being set. It's essentially editing a P-state table - pretty simple, but a lot of manual work. So that is one bridge built. For future testing, I will need to enhance my cooling solution by either going LN2 (hehe) or adding perhaps a strong fan or so. As for the Mali GPU overclocking, I am not entirely sure how it works yet. I've been digging through the kernel source code, but I find no reference to the various oc settings that can be configured via the .config files. It is definitely not via a P-state table. It seems to me that the current clock settings of 400/533/640/800 are nothing more than making use of the available ACLK dividers. According to the Exynos user manual, the available dividers are: - aclk_100 => 400 x 1,00 = 400 MHz - aclk_133 => 400 x 1,33 = 533 MHz - aclk_160 => 400 x 1,60 = 640 MHz - aclk_200 => 400 x 2,00 = 800 MHz - aclk_266 (for gps) ?=> 400 x 2,66 ?= 1064 MHz - aclk_400 (for mcuisp) ?=> 400 x 4,00 ?= 1600 MHz I have not found exactly where that aclk divider is configured yet. But that should just be a matter of time. As far as I can see though, the only options for further overclocking the Mali GPU is either 1) hope that the 266 divider works or 2) figure out how to overclock the apll. Option number 2) is pretty similar to overclocking the BCLK frequency on IVB to increase the GPU frequency. The main issue of course is that all frequencies linked to aclk will be overclocked, and I have not yet mapped out all the connections. Second issue with the Mali GPU is something I picked up from the Odroid forums. Apparently the DVFS scaling is broken when overclocking the GPU. DVFS stands for Dynamic Voltage Frequency Scaling, and basically comes down to the automatic overvoltage for given frequencies. To overcome this issue, the overclock options are tied to specific voltage settings. These are the settings: - 533 MHz - 1.075V - 640 MHz - 1.125V - 800 MHz - 1.2V No idea where to adjust the voltages yet.

Personal achievement today. Scored 4160 with CyanogenMod 10.1.2 rom. Modified and re-compiled the kernel myself to get a Mali GPU overclock of 800MHz :D . Nothing too impressive, to be honest, but this is the first time I managed to compile the kernel. I have no prior knowledge of Linux whatsoever, so it's an achievement for me . I have a vague idea how to code the CPU overclock >2GHz ... trying that later this week!

Very nice!

It's mid-october - you will get the official invite and date via email next monday

More information will follow on Monday

Hehe. The developers for these kernels don't really want to open more volt/freq options because "it increases power consumption". Default load is like 10W

Because it highlighted a specific manufacturer, and I want to get this issue looked at without too much drama. We're looking into it. One thing is very clear though: XTU does not calculate the score based on the estimated overclock.

My first overclock. Flashed a new kernel and now running 2000 on ARM, and 800 on Mali GPU. Going up from 2700 to slightly over 4000. The CPU isn't too stable though, 3dmark would crash at physics test once in a while.

As far as I know, the main issue is that the the Kernel has to provide overclocking for your specific SoC. In this case, the Exynos 4412. There are kernels out there which have predefined settings upto 2000MHz, but we are far from the more ideal situation like on RPi where it's only a matter of adjusting the boot config file. The way I see it, currently most ARM devices are in a phase where x86 was maybe 15 years ago. The BIOS we have today for architecture like Haswell, are graphical interfaces to control specific MSR. Most of the work for overclocking has been done by Intel and mainboard vendors - the interface we have is super-super-simple. For ARM, we are currently looking at the datasheets containing registers and equations. The information can be put in the kernel and that leaves a little room for tweaking, but what we are basically still doing is recompile and flash new "bioses" (if you compare to x86). The Raspberry Pi is somewhat closer to the BIOS interface as we know it - you can adjust the settings in one file - but it's still very basic. What we have to do for this device to overclocking it past the "known" limitations is quite similar to using the PLL diagnosis in SetFSB or using RWutility to read registers. Only, well ... the changes are not realtime.

You and me both, hehe. At least I now found out how to read a kernel, and I think with the right guide I'll be able to "update" an existing one.

WR Targets updated: CPU Frequency: 7084.32 MHz Memory Frequency: 2202 MHz

Fixed Fixed We can't do this manually as the competition points are a part of the HWBoints engine. There are an entire series of equations, checks and calculations when giving (any type of) points to a submission. Manually overriding could potentially break any of these calculations and if we don't keep track of what manual changes we make, it becomes impossible to debug if we have any issues. As for the competition points - in the original plans they were supposed to be limited in time to ~ 3 months I believe. We had quite some discussion about this internally and I honestly can't remember anymore how we implemented this two years ago. I will check with the developers. Reported this issue - this is not correct. http://forum.hwbot.org/showthread.php?t=7966 http://forum.hwbot.org/showthread.php?t=5828 Disallowing ES for the non-Pro users was a change made as requested by the community. In above threads, you will find about 600 posts on the ES topic. Can't check, please disable points for ES scores.

Done.

@Knut, can you check if this is the problem on your end indeed?