I am trying to obtain a bitmap of the number of cores which are online in an android device. I am trying to create a command line tool in C++ that does some additional functionality based on how many cores are on and in particular which cores are available.
I have tried to use the following to try and get the number of cores on in C++:
cpus = sysconf( _SC_NPROCESSORS_ONLN );
This gives me the number of cores in the system but not which cores are presently ON.
Does anyone know a potential way to do this?
There's no clear cut answer to this problem.
You can use nproc to see how many cores you have available, but this won't tell you how many cores you have online.
You can use top to view the utilization of each core. You can then parse the information from top to infer which cores are presently on.
I was able to get the core online status using this:
int numCPU = 1;
char *status = (char*)calloc(32,sizeof(char));
char *directory = (char*)calloc(1024,sizeof(char));
sprintf(directory, "/sys/devices/system/cpu/cpu%d/online", numCPU);
FILE *online = fopen(directory, "r");
if(online)
{
size = fread(status, sizeof(char), 32, online);
}
printf("Core %d status=%d", numCPU, status);
Related
I've used many apps that show the speed in MHz on my phone, but where are they getting the information from? I am trying to get the minimum and maximum frequencies of my processor, but am stuck. I've tried reading from:
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
but, the only folders under cpufreq are "power", "subsystem", "uevent", and "topology".
/sys/devices/system/cpu/cpufreq/
Also has no files.
/proc/cpuinfo
Has a lot of information, but it only shows BogoMIPS instead of both.
Is there elsewhere should be looking or is there some special equation that I need to use in order to calculate it from the data that I do have?
For me,this code works:
String cpuMaxFreq = "";
RandomAccessFile reader = new RandomAccessFile("/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq", "r");
cpuMaxFreq = reader.readLine();
reader.close();
I have spent much time trying to find out where is my mistakes while Im flashing the PIC16F688. The Pic has successfully flashed using PicKit2. Im using the Pic to convert analog pressure sensor to digital output and sending the data via Bluetooth, but the Bluetooth is not receiving stable numbers of data. The data is consist of 4 character decimal number that is between 0 and 1023.
The problem is that the Bluetooth can't wait at specific number and keep reading it, instead, it is reading the 4 digits in random.
I think my mistake is within the configuration of internal oscillator.
I'm attaching my code, the code is written to configure the flexiforce sensor circuit that outputs analog voltage up to 5v, and then the pic duty is to convert it to digital as I mentioned above.
it might be my wiring is not correct, please If you could help out with this one
and what configuration "at edit project" do I need to choose for Mikro PRO software?
I used "Bluetooth terminal" app to see my data asynchronous from Bluetooth.
Thank you.
char *temp = "0000";
unsigned int adc_value;
char uart_rd; int i;
void main()
{
OSCCON = 0x77;
ANSEL = 0b00000100;
CMCON0 = 0X07;
TRISA = 0b00001100;
UART1_Init(9600);
Delay_ms(100);
while (1)
{
adc_value = ADC_Read(2);
temp[0] = adc_value/1000+48;
temp[1] = (adc_value/100)%10+48;
temp[2] = (adc_value/10)%10+48;
temp[3] = adc_value%10+48;
for (i=0;i<4; i++)
UART1_Write(temp[i]);
UART1_Write(13);
Delay_ms(1000);
}
}
You can use itoa function to convert ADC integer value to characters for sending over UART. If there is error in calculation then you wont get appropriate value. Below code snippet for your reference :
while (1)
{
adc_value = ADC_Read(2);
itoa(adc_value, temp, 10);
for (i=0;i<4; i++)
UART1_Write(temp[i]);
UART1_Write(13);
Delay_ms(1000);
}
Please check Baud Rate you have configured at both ends is same or not. If baudrate mismatches then you will get Random value at Bluetooth Terminal where you are reading values.
What i would suggest, if you have a logic analyser, hook it up. If you don't recalculate your oscillator speed with the datasheet. It could just be that the internal oscillator is not accurate enough. What also works, is to write a function in assembly that waits a known time (by copy-pasting a lot of NOPs and using this to blink a led. Then start a stopwatch and count, say, 100 blinks. This is what i used to do before i had a logic analyser. (They are quite cheep on ebay).
I am trying to set the Performance Monitor User Mode Enable register on all cpus on a Nexus 4 running a mako kernel.
Right now I am setting the registers in a loadable module:
void enable_registers(void* info)
{
unsigned int set = 1;
/* enable user-mode access to the performance counter*/
asm volatile ("mcr p15, 0, %0, c9, c14, 0\n\t" : : "r" (set));
}
int init_module(void)
{
online = num_online_cpus();
possible = num_possible_cpus();
present = num_present_cpus();
printk (KERN_INFO "Online Cpus=%d\nPossible Cpus=%d\nPresent Cpus=%d\n", online, possible, present);
on_each_cpu(enable_registers , NULL, 1);
return 0;
}
The problem is that on_each_cpu only runs the function on Online cpus and as shown by the printk statment:
Online Cpus=1
Possible Cpus=4
Present Cpus=4
Only one of the four is online when I call on_each_cpu. So my question is, how do I force a cpu to be online, or how can force a certain cpu to execute code?
Thanks
You don't need to run the code on every cpu right now. What you need to do is arrange so that when the offline cpus come back online, your code is able to execute and enable the access to the PMU.
One way to achieve that would be with a cpu hotplug notifier.
I've been working on a cryptographic (POT) protocol in Java for my master's thesis.
It uses cryptographic Pairings and therefore makes use of an external java library called jPBC (http://gas.dia.unisa.it/projects/jpbc/).
As I want one side of the protocol to run on a mobile device, I 've made a simple GUI in Android ADT with a single button that starts the protocol. However, the protocol runs about 200 times slower on my phone (Samsung S2 plus, ARM Cortex A9 32 bit processor) than on my laptop (Intel Core i7, but only using half a core). As the difference in processors might explain a factor 10 but certainly not a factor 100/200 I figured the difference in performance would be due to the inefficiency of the jPBC library on Android.
The jPBC library makes extensive use of BigInteger for all of its calculations so I decided to investigate if BigInteger could be extra inefficient on android (it's not super efficient on normal computers either). I executed a loop of 1200 bit BigInteger calculations on the phone and the laptop. I've come up with some results that I cannot explain:
10^6 Additions and subtractions take 205ms on laptop, 48 025ms on phone (x 200).
10^5 Multiplications and divisions take 814 ms on laptop and 13 705ms on phone (x 17).
10^3 Modular Exponentiations (modPow) take 5079ms on laptop and 22 153ms on phone (x 4.5)
As there is much to be said about these results, I'll just stick to this simple question:
Can anyone either reproduce these results and confirm that BigInteger addition is immensively slow on Android, or tell me what I've done wrong?
The code:
Java method:
public static long bigIntCalculations(){
System.out.println("starting bigIntCalculations");
Random random = new Random();
BigInteger start = new BigInteger(1200, random);
BigInteger temp = new BigInteger(start.toString());
long nOfIterations = 1000000L;
long time1 = System.nanoTime()/1000000;
for (long i = 0; i < nOfIterations; i++) {
start = start.add(temp);
start = start.subtract(temp);
}
long result = (System.nanoTime()/1000000)-time1;
System.out.println(result);
return result;
}
In Android:
/** Called when the user clicks the button1*/
public void runProtocol(View view) {
long duration = Test.bigIntCalculations();
String result ="Calculations take: " + duration + " ms";
Intent intent = new Intent(this, DisplayMessageActivity.class);
intent.putExtra(CALC_RESULT, result);
startActivity(intent);
}
Many thanks!
Only x4.5 for 1200-bit modular exponentiation is a terrific result, considering the underpowered hardware. It's also a testament to how bad the JDK's BigInteger implementation is.
The Android standard library uses OpenSSL BigNum for some under-the-hood operations. Without peeking, I would guess modular exponentiation and modular inverse are handled in native code, while simpler arithmetic is handled in Java code.
For tight loops of addition and multiplication you would be generating lots of garbage, and GC performance disparity between platforms could also be having a large impact -- my guess is that some warmup + a much smaller benchmark will show closer results.
My performance pain point is modular exponentiation, so I'm pretty happy with Android performance. If that were not the case, I'd be looking at porting libraries such as gmp4j or gmp-java (two libraries by that name) to Android. Two of these provide a BigInteger-compatible API. Another offers a more direct mapping to GMPLib, which can be ideal in terms of memory management (GMP numbers are mutable).
Update
After checking the time resolution, we tried to debug the problem in kernel space.
unsigned long long task_sched_runtime(struct task_struct *p)
{
unsigned long flags;
struct rq *rq;
u64 ns = 0;
rq = task_rq_lock(p, &flags);
ns = p->se.sum_exec_runtime + do_task_delta_exec(p, rq);
task_rq_unlock(rq, &flags);
//printk("task_sched runtime\n");
return ns;
}
Our new experiment shows that the time p->se.sum_exec_runtime is not updated instantly. But if we add printk() inside the function. the time will be updated instantly.
Old
We are developing an Android program.
However, the time measured by the function threadCpuTimenanos() is not always correct on our platform.
After experimenting, we found that the time returned from clock_gettime is not updated instantly.
Even after several while loop iterations, the time we get still doesn't change.
Here's our sample code:
while(1)
{
test = 1;
test = clock_gettime(CLOCK_THREAD_CPUTIME_ID, &now);
printf(" clock gettime test 1 %lx, %lx , ret = %d\n",now.tv_sec , now.tv_nsec,test );
pre = now.tv_nsec;
sleep(1);
}
This code runs okay on an x86 PC. But it does not run correctly in our embedded platform ARM Cortex-A9 with kernel 2.6.35.13.
Any ideas?
I changed the clock_gettime to use the CLOCK_MONOTONIC_RAW , assigned the thread to one CPU and I get different values.
I am also working with a dual cortex-A9
while(1)
{
test = 1;
test = clock_gettime(CLOCK_MONOTONIC_RAW, &now);
printf(" clock gettime test 1 %lx, %lx , ret = %d\n",now.tv_sec , now.tv_nsec, test );
pre = now.tv_nsec;
sleep(1);
}
The resolution of clock_gettime is platform dependent. Use clock_getres() to find the resolution on your platform. According to the results of your experiment, clock resolutions on pc-x86 and on your target platform are different.
In the android CTS, there is a case that has the same problem. read timer twice but they are the same
testThreadCpuTimeNanos fail junit.framework.AssertionFailedError at
android.os.cts.DebugTest.testThreadCpuTimeNanos
$man clock_gettime
...
Note for SMP systems
The CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are realized on many platforms using timers from the CPUs (TSC on i386, AR.ITC on Itanium). These registers may differ between CPUs and as a consequence these clocks may return bogus results if a process is migrated to another CPU.
If the CPUs in an SMP system have different clock sources then there is no way to maintain a correlation between the timer registers since each CPU will run at a slightly different frequency. If that is the case then clock_getcpuclockid(0) will return ENOENT to signify this condition. The two clocks will then only be useful if it can be ensured that a process stays on a certain CPU.
The processors in an SMP system do not start all at exactly the same time and therefore the timer registers are typically running at an offset. Some architectures include code that attempts to limit these offsets on bootup. However, the code cannot guarantee to accurately tune the offsets. Glibc contains no provisions to deal with these offsets (unlike the Linux Kernel). Typically these offsets are small and therefore the effects may be negligible in most cases.
The CLOCK_THREAD_CPUTIME_ID clock measures CPU time spent, not realtime, and you're spending almost-zero CPU time. Also, CLOCK_THREAD_CPUTIME_ID (the thread-specific CPU time) is implemented incorrectly on Linux/glibc and likely does not even work at all on glibc. CLOCK_PROCESS_CPUTIME_ID or whatever that one's called should work better.