From owner-freebsd-chat Thu Apr 10 19:12:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA19930 for chat-outgoing; Thu, 10 Apr 1997 19:12:05 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA19897 for ; Thu, 10 Apr 1997 19:11:55 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA08433; Fri, 11 Apr 1997 11:41:46 +0930 (CST) From: Michael Smith Message-Id: <199704110211.LAA08433@genesis.atrad.adelaide.edu.au> Subject: Re: Informix efficiency--any ideas? In-Reply-To: <199704100825.RAA01491@papillon.lemis.de> from "grog@lemis.de" at "Apr 10, 97 05:25:40 pm" To: grog@lemis.de Date: Fri, 11 Apr 1997 11:41:45 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, chat@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk grog@lemis.de stands accused of saying: > > > TBH, I don't know how the various SMP implementations would come into > > play here; specifically on the send/recv model I would expect > > (assuming an idle system) that one half would be running on each CPU, > > ie. the long-term throughput would be that of the slowest component > > rather than of the system as a whole. In contrast, the lock-step > > model using semaphores basically ensures that a single client/server > > pair runs as a single logical thread. > > Now that's an interesting thought. Basically, the socket > implementation doesn't even need to be as fast as the semaphore > implementation (*if* you're restricting your semaphore counter to 1. > IIRC, you can have more than one on System V), since it can queue. > That might explain why we were getting up to 30% idle on System A. I would expect that the server would only use multiple semaphores if it could guarantee the order in which it woke on them, as otherwise there could be problems with transaction ordering. > In the meantime, we have found some more documentation. It seems that > there are "protocols" for talking to the server. One is called > tlitcp, and the other is called ipcshm. System A was using ipcshm, > and system B was using tlitcp, so now we're repeting a (longer, more > accurate) benchmark the other way round. I would expect that the TLI/TCP interface will be much more efficient in the SMP context than the IPC/SHM interface, simply because by nature it will offer better decoupling between the client and server. Could be wrong, of course 8) It would be _very_ informative to be able to run this benchmark on a well-configured SMP FreeBSD system, as I understand that Informix runs well under the SCO emulation. I would imagine that the SMP Mips systems you are looking at would be a lot more expensive 8) > Greg (ps. what do you think of Viewsonic's 21" monitors? They're reasonably available around here...) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[