![]() |
Hello and Welcome from United States to the UNIX and Linux Forums! Thank You for Visiting and Joining Our Global Community.
|
|
google unix.com
|
|||||||
| Forums | Register | Forum Rules | Links | Albums | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| High Level Programming Post questions about C, C++, Java, SQL, and other programming languages here. |
More UNIX and Linux Forum Topics You Might Find Helpful
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| semaphore | raguramtgr | UNIX for Dummies Questions & Answers | 7 | 06-15-2009 09:39 AM |
| Semaphore | Jaken | Shell Programming and Scripting | 2 | 04-04-2009 05:10 PM |
| dmidecode, RAM speed = "Current Speed: Unknown" | Santi | Filesystems, Disks and Memory | 0 | 02-16-2006 06:16 AM |
| Semaphore | vjsony | UNIX for Dummies Questions & Answers | 3 | 04-07-2003 02:06 PM |
| semaphore | yls177 | UNIX for Dummies Questions & Answers | 1 | 10-08-2002 11:18 PM |
![]() |
|
|
LinkBack | Thread Tools | Search this Thread |
Rating:
|
Display Modes |
|
||||
|
My version of truss does not have -c flag, or any other flag similar to the one I used with trace under Linux.
On Linux : $ /sbin/sysctl -a |grep shm ... <snip error msgs> vm.hugetlb_shm_group = 0 kernel.shmmni = 4096 kernel.shmall = 2097152 kernel.shmmax = 33554432 Q: Why would SHM parameters affect semaphore performance? Also, just in case I ran this $ /sbin/sysctl -a |grep sem <snip error msgs> kernel.sem = 250 32000 32 128 Last edited by migurus; 09-24-2008 at 07:55 PM.. Reason: added info |
|
||||
|
Thanks Otheus and Jim, I got quite detailed answer here:
semaphore access speed | KernelTrap So, the 2.6.9 kernel is not the best for modern h/w. I appreciate everebodys time! |
|
|||||
|
Kudos to you for your tenacity! However, I don't think this is the end of it.
I did a little research on strcmp's answer. 2.6.9 was released in 2004 and is standard with RHEL 4, which shipped with glibc 2.3.4. Pentium 3's were old in 2004. RHEL 5 ships with kernel 2.6.18 and glibc 2.5.12. So I did some benchmarks. I followed strcmp's suggestion and used a "falling timer" method, where the loop starts and ends after the time() call notes a change in seconds. There's a 10 to 100 ms variance on either side of the fall, so I took an average of several runs. Then I divide the ops/s number by the CPU speed (cycles/s) to get "tics per op".
For tics/op, smaller is better. So the 2.6.18 kernel is indeed faster than the 2.6.9 kernels. The Xeon is MUCH slower. Presumably the kernels were compiled by a lowest common denominator. No Optimization flags were enabled, but there was a difference in compilers: the 2.6.9 hosts used gcc 3.4.6, while the newer ones were with gcc 4.1.1. Also, it should be noted that we don't have an AMD running 2.6.9 nor a Xeon running 2.6.18. It very may well be that the problem is that these kernels were not compiled optimally for the various architectures. Why the Xeons are so much slower is quite surprising, given their characteristic use as HPC components. Regardless, none of these results seem to explain the fundamental question: Why is SCO so much faster?? Last edited by otheus; 10-08-2008 at 05:57 AM.. Reason: I said the Xeon is much faster when it was much slower. |
|
|||||
|
Here is my code:
Code:
#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <time.h>
#define NSEMS 2
/* change this per CPU to run between 8 and 12 s*/
const static int maxloop = 10000000;
main(int argc, char *argv[])
{
time_t start,last,stop;
long int i;
int estimate = 100;
int sid;
key_t key;
ushort vals[NSEMS] = { 0, 0 };
key = ftok("/tmp",99);
last=start=time(NULL);
for (i = 0; i < 1000; ++i) {
usleep(10);
last=time(NULL);
if (last > start) break;
}
start=last;
last = 0;
for (i = maxloop/8; i < maxloop; i++) {
if ((sid = semget(key, NSEMS, IPC_CREAT | 0777)) == -1) {
perror("Can Not Get Semaphore ID");
}
if (semctl(sid, NSEMS, GETALL, vals) == -1) {
perror("Can Not Get Semaphore Values");
}
}
/* do the last 1/8th until the second changes.
If your processor reaches the maxloop before that,
change the maxloop or the divisor or the "estimate" */
stop=time(NULL);
for (i = maxloop - maxloop/8; i < maxloop; ++i) {
if ( !(i % estimate) ) {
last=time(NULL);
if (last > stop) break;
stop=last;
}
/* repeat semaphore opts */
if ((sid = semget(key, NSEMS, IPC_CREAT | 0777)) == -1) {
perror("Can Not Get Semaphore ID");
}
if (semctl(sid, NSEMS, GETALL, vals) == -1) {
perror("Can Not Get Semaphore Values");
}
}
stop=last;
printf("%.2f semop/s (%i/%i) [%d]\n", (double)i/(stop-start), i, stop-start, estimate);
}
|
| Sponsored Links | ||
|
|
![]() |
| Bookmarks |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|