I have an ARM-based embedded machine based on S3C2416 board. According to the specifications I have available there should be a 533 MHz ARM9 (ARM926EJ-S according to /proc/cpuinfo
), however the software running on it "feels" slow, compared to the same software on my Android phone with a 528MHz ARM CPU.
/proc/cpuinfo
tells me that BogoMIPS is 266.24. I know that I should not trust BogoMIPS regarding performance ("Bogo" = bogus), however I would like to get a measurement on the actual CPU speed. On x86, I could use the rdtsc
instruction to get the time stamp counter, wait a second (sleep(1)), read the counter again to get an approximation on the CPU speed, and according to my experience, this value was close enough to the real CPU speed.
How can I find the actual CPU speed of given ARM processor?
Update
I found this simple Pi calculator, which I compiled both for my Android phone and the ARM board. The results are as follows:
S3C2416
# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 266.24
Features : swp half fastmult edsp java
...
#./pi_arm 10000
Calculation of PI using FFT and AGM, ver. LG1.1.2-MP1.5.2a.memsave
...
8.50 sec. (real time)
Android
# cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 2 (v6l)
BogoMIPS : 527.56
Features : swp half thumb fastmult edsp java
# ./pi_android 10000
Calculation of PI using FFT and AGM, ver. LG1.1.2-MP1.5.2a.memsave
...
5.95 sec. (real time)
So it seems that the ARM926EJ-S is slower than my Android phone, but not twice slower as I would expect by the BogoMIPS figures. I am still unsure about the clock speed of the ARM9 CPU.
Best Answer
AFAICT the clock of a S3C2416 looks just like that of a S3C2443, or similar processors of its family. The Linux source code for it suggests that there are a number of closely-related clocks.
Choice snippet:
Update from OP
I have been looking for this output from
dmesg
, but I could not find anything - thedmesg
output was littered with debug messages, and the beginning was missing. Clearly the kernel message buffer was too short to hold all messages until I connect by telnet. By putting/bin/dmesg > /tmp/dmesg.log
early in the startup process, I was able to get this output, confirming what I wanted to know: