Date: Wed, 24 Jul 2002 16:35:04 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jay West <jwest@classiccmp.org> Cc: freebsd-hackers@freebsd.org Subject: Re: SysV IPC message queues performance Message-ID: <3D3F39A8.D47FE97@mindspring.com> References: <008901c23322$cdf0f320$9701a8c0@HPLAPTOP>
next in thread | previous in thread | raw e-mail | index | archive | help
Jay West wrote: > 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). It's pretty clear that you are expecting an explicit yield by the sending process to the receiving process with your test program. Rather than looping, you should *not* use IPC_NOWAIT, and set an alarm for your timeout period, putting the process to sleep. That way, the looping will not use it's entire quantum, thus preventing the other program from running to the point of the message being delivered. Discussion: Unfortunately, you can not mix IPC with other operations trivially, because IPC does not use decriptors or signals, so the operations tend to be blocking (OK, if you can handle it) or polling (always bad). It is actually fairly trivial to add kevents for IPC messages; look at the signal deliver kevents for an example of a process based rather than a descriptor based event notification. It's all of about 6 lines. It beats the hell out of writing your own setjmp/longjmp based threading library to deal with IPC in an asynchronous way. 8-). If the code has to be portable to other platforms other than FreeBSD, then you will probably want to use signals to notify of IPC messages pending -- again: don't use a polling loop. An alternative is to use multicast/unicast network connections to do the work; such connections can be selected upon, since they utilize sockets, and can therefore be rationalized through the normal system interfaces for multiplexing operations. > 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. Shared memory would have been my first choice, assuming that there was not interrupt notification required -- apparently, a lot of vendors these days do not recognize that there hardware is not the most important thing in the machine, or that for a given application, talking to their hardware is not the *only* task that your application has to perform, and thus they leave interrupt notification out of their cards. If you need notification in the shared memory case, though... I don't understand trying to pretend you don't in the IPC case. > 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. You could always add an explicit yield. THis is *not* recommended. -- Terry 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?3D3F39A8.D47FE97>