Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jul 2002 10:00:09 -0500
From:      "Jay West" <jwest@classiccmp.org>
To:        <freebsd-hackers@freebsd.org>
Subject:   SysV IPC message queues performance
Message-ID:  <008901c23322$cdf0f320$9701a8c0@HPLAPTOP>

next in thread | raw e-mail | index | archive | help
I already asked this question on freebsd-questions. No answers were to be
found, and several of the list members there pointed me to this list as a
likely spot to get some suggestions. My apologies in advance, I did try to
find the charter for this list to make sure asking this question here wasn't
out of line, but the links I found were broken so if this query is "bad
form" please forgive me, but at least point me to the proper resource. I was
thinking there used to be a list for people developing applications on
freebsd (freebsd-developers maybe) but can't find such a list.

I'm writing a rather major project under FreeBSD, and making fairly heavy
use of SYSV message queues so that multiple processes can communicate. I am
finding the response times for round trip message delivery between two given
processes to be pretty horrid, typically about .5 to 1 second per message
set (send query from process A to process B, then process B sends a response
back to process A and process A displays the response).

I stripped down the code in two programs to help isolate the problem. The
basic gist is the main process (A) forks a child (B). Process A prompts for
a line of input from the keyboard. Each line that it gets, it puts on the
message queue with a target ID of process B. Process A then does a timed
wait using IPC_NOWAIT in a clock time loop for up to 5 seconds, looking for
a response from process B. When it finds a message on the queue it prints it
on the console and then goes back to the "wait for terminal input" loop.
When process B fires up, it constantly loops checking the message queue with
IPC_NOWAIT and no clock time loop - just constantly scanning. When it sees a
message for it (with the process B pid), it gets the message and then
immediately puts a constant "OK" response message on the queue targeted at
it's ppid. This is a tight loop, constantly running.

One  wrinkle... Process A has the ability to take a long list of "commands"
from a batch file, instead of getting the lines from the keyboard. When it
runs this "command file", it prints the command it sends (just garbage in
the example), then prints the response from process B. Watching this run,
there is a good 0.5 to 1.0 second time elapse as each send/response pair
displays.

The real problem is the speed of this inter process communication. Because
the data being transferred between processes is at times being used to
simulate DMA transfers between "virtual computer peripherals", I really need
about 2mbits per second of throughput just to match the original hardware,
and I'm afraid the message queues just aren't fast enough. To get that speed
I may have to write my own message exchange structures with semaphores and
shared memory (ie. build my own messaging mechanism), but I'd rather not do
that if there is just something that can be tweaked with message queues.
More to the point, if message queues are slow only on FreeBSD, I would think
the core team might should take a look at that because there are certainly
some packages which make use of them that would be hindered on FreeBSD.

At one point I saw a program on the net that did benchmarks on a given
system of sending the same data via message queues, sockets, pipes, etc. but
I can't seem to find it anymore. The long and short of my question is - are
SYSV IPC message queues on FreeBSD (or in general) known to be fairly slow?
If only on freeBSD, is there anything that can be tweaked to speed them up?
If not, or if they're just slow on all implementations, can someone suggest
which of sockets, pipes, etc. are known to be awfully fast?

As a side note - the code for process B that sits there constantly scanning
the message queue with IPC_NOWAIT, this seems to be a huge waste of cpu
time. On some platforms I have seen a system call for "release quantum",
which basically is put in tight loops to keep a process from hogging the cpu
(release remainder of the timeslice). Does this mentality apply to freebsd,
and is there such a call?

Thanks VERY much in advance

Regards,

Jay West






---
[This E-mail scanned for viruses by Declude Virus]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008901c23322$cdf0f320$9701a8c0>