Re: [Xenomai-core] Fwd: problem in pthread_mutex_lock/unlock
Nero Fernandez wrote: Thanks for the rootfs, Gilles. Although i am unable to use it directly (i get 'illegal instruction' error while running any application/busybox-applet), i will try to construct a similar test-setup for further testing. It is an EABI rootfs. Is EABI enabled in your kernel configuration? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Fwd: problem in pthread_mutex_lock/unlock
Nero Fernandez wrote: Thanks for your response, Philippe. The concerns while the carrying out my experiments were to: - compare xenomai co-kernel overheads (timer and context switch latencies) in xenomai-space vs similar native-linux overheads. These are presented in the first two sheets. On what ARM system do you get these latency figures? I really doubt the linux kernel has a bounded latency under 35us. Because: - the preempt_rt people, which work on getting a bounded latency get something around 200us on AT91, an ARM9; - there would be no reason of the preempt_rt effort if the linux kernel interrupt latency was already bounded. So, I take it that you do your measurement without generating a load. We do our measurements using the latency test, while generating a load for several hours. And on the average ARM, we usually get an interrupt latency around 50us. Please add some load on the system, and do the measurments again. The best source of load we have found so far is to load the LTP testsuite while running the latency test. If you tell me what ARM SOC, or at least what ARM architecture revision you use (the ARM920T core is an armv4, and the ARM926EJS is an armv5, so ARM 9 does not tell us much), I can provide you with the root filesystem we use for our tests. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Fwd: problem in pthread_mutex_lock/unlock
Nero Fernandez wrote: Yes, the measurements are on no-load scenarios. I will try to repeat my measurements with system-loads as you suggest. You can find a working root filesystem image with Xenomai 2.5.3 compiled here: http://www.xenomai.org/~gch/pub/rootfs-arm926-ejs.tar.bz2 The root password is empty, the system launches a telnet daemon, so you can log on the board via telnet. To run the tests, launch in a first telnet session: echo 0 /proc/xenomai/latency latency -T 2 -H in a second telnet sesssion, launch: dohell When you see Listening on any address 5566, run on the host: netcat target-name-or-IP 5566 where target-name-or-IP is the name of your arm board in the host /etc/hosts file or its IP address. Now, you can let the system run as long as the latency test prints message. When the dohell script is done, it will kill the latency test, which will cause it to print the histogram values and exit. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Fwd: problem in pthread_mutex_lock/unlock
Nero Fernandez wrote: As far as the adeos patch is concerned, i took a recent one (2.6.32) and back-ported it to 2.6.18, so as not to lose out on any new Adeos-only upgrades. There is no such thing as an Adeos patch for linux 2.6.32 on the ARM platforme. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
