semaphore access speed

migurus · #1 (**permalink**) 09-17-2008

I am investigating some locking scheme using semaphores. To evaluate basic system speed I run a loop of getting some semaphore info and display it:

while : ; do ./semshow; done > res.txt

I ran this on 3 boxes - two similar modern HP XEON boxes, one running SCO OpenServer 5, the other is Fedora 2.6.9, and one old PIII box under modern Linux (have no info).
The results are very counter intuitive:
H/W | OS | avg number of runs ber sec
---- | --- | -------------------------
XEON | SCO | 1700
XEON | Fedora | 500
PIII | Linux (recent distro, unknown) | 900
All three systems were pretty much idle at the test run time.

I would like to ask, what would be the factors that makes ancient Unix to outperform modern OSes, also, how come PIII box outperform modern XEON box under similar OS. Any ponters would be appreciated.

The semshow program is very basic, see listing below:

Code:

 
#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include  <sys/timeb.h>
#include <time.h>
#include "semlib.h"
#define MODE_CREATE     0
#define MODE_REMOVE     1
key_t   IPCKEY;
main(int argc, char *argv[])
{
  int   sid, i;
  pid_t last_rpid, last_wpid;
  char  dbuf[80];
  union semun           arg;
  unsigned short        vals[NSEMS];
  struct timeb tb;
  struct tm *tp;
        if((IPCKEY = get_ipc_key()) == -1)
        {
                errexit("Can Not Obtain IPC Key");
        }
        if((sid = semget(IPCKEY, NSEMS, 0)) == -1)
        {
                errexit("Can Not Get Semaphore ID");
        }
        memset(vals, 0, sizeof(vals));
        arg.array = &vals[0];
        if(semctl(sid, NSEMS, GETALL, arg) == -1)
        {
                errexit("Can Not Get Semaphore Values");
        }
        if((last_rpid = semctl(sid, RDLOCK, GETPID)) == -1)
        {
                errexit("Can Not Get Semaphore R-Pid");
        }
        if((last_wpid = semctl(sid, WRLOCK, GETPID)) == -1)
        {
                errexit("Can Not Get Semaphore W-Pid");
        }
        ftime(&tb);
        tp = localtime(&tb.time);
        strftime(dbuf, sizeof(dbuf) - 1, "%T", tp);
        printf("%12li.%03i %s  RD:[%i]  WR:[%i] %i/%i\n",
                tb.time, tb.millitm, dbuf, 
                vals[RDLOCK], vals[WRLOCK],
                last_rpid, last_wpid);
        exit(0);
}

semlib.h has these defs:

Code:

 
#define NSEMS   2
#define RDLOCK  0
#define WRLOCK  1
union   semun   {
        int             val;
        struct semid_ds *buf;
        unsigned short  *array;
};

otheus · #2 (**permalink**) 09-18-2008

Here's one answer: your time measurement is buggy. See man on ftime() under Linux:

Quote:

This function is obsolete. Don't use it. If the time in seconds suffices, time(2) can
be used; gettimeofday(2) gives microseconds; clock_gettime(3) gives nanoseconds but
is not yet widely available.

Under libc4 and libc5 the millitm field is meaningful. But early glibc2 is buggy and
returns 0 there; glibc 2.1.1 is correct again.

migurus · #3 (**permalink**) 09-18-2008

The Fedora box has
/lib/tls/libc.so.6 -> libc-2.3.5.so
so, I assume the version is 2.3.5.

But that is besides the point.

The pure number of times system ran the program within a second would indicate overall system's power, so to speak. To my astonishment PIII under linux managed to run almost twice as many cycles withi a second than Xeon 3.2GHz under linux. Then the same Xeon h/w under old SCO OSR run twice as fast as PIII box.

otheus · #4 (**permalink**) 09-18-2008

But Problem #1 is that you are measuring this the wrong way. You have too many dependencies on library calls that are irrelevant to what you are trying to measure. Take out ALL the semaphore code, re-test, and see what times you get. Or, run a 10,000 x loop around the semaphore. Then scale down to the nearest second so that microseconds mistimings aren't coming into play.

Problem #2 is that semaphores require bus-access and are relatively independent of Processor speed.

migurus · #5 (**permalink**) 09-18-2008

I replaced the ftime with gettimeofday and re-run, the results are the same.

To summarize again,
same h/w :
program under SCO runs 3 times faster than under Linux,
same OS :
program runs 2 times faster on old PIII than on modern Xeon

Any reasons? any ideas?

otheus · #6 (**permalink**) 09-18-2008

I'm sorry, but you still haven't eliminated all "loose variables". But your semaphore code in a loop of 1000 or so and bench again.

migurus · #7 (**permalink**) 09-18-2008

I simplified my program to the very basic minimum, it gets ipc key, gets semaphore id and reads values of semaphores and then it outputs on line (time and semaphore values). That is all it does.

Then I run it in following manner:
$ while : ; do tstshow; done > x.txt
and I hit interrupt key after waiting for some time.

sample of the x.txt file content:
1221785538 [1,99]
1221785538 [1,99]
1221785538 [1,99]

Then to see how many times system was able to run it I do:
$ cut -c-12 x.txt | uniq -c

sample of the output:
616 1221785538
615 1221785539
612 1221785540

That tels me the system is capable of running this simple process just roughly 600 times per second.

Just to be consistent I would repeat results here:
PIII under Linux - 900 times/sec
Xeon 3.2 Linux - 600 times/sec
Xeon 3.2 SCO - 1800 times/sec
Systems are idle at the time of test.
How would you explain the results I got? I am trying to find a bottleneck on the modern h/w running Linux.

Please see my new simplified code below:

Code:

 
#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <time.h>
#define NSEMS   2
main(int argc, char *argv[])
{
  int           sid;
  ushort        vals[NSEMS] = {0, 0};
        if((sid = semget(get_ipc_key(), NSEMS, 0)) == -1)
        {
                errexit("Can Not Get Semaphore ID");
        }
        if(semctl(sid, NSEMS, GETALL, vals) == -1)
        {
                errexit("Can Not Get Semaphore Values");
        }
        printf("%12li [%i,%i]\n", time(NULL), vals[0], vals[1]);
        exit(0);
}

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

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes	Rate This Thread
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode	Rate This Thread: