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>