carla@boulder.Colorado.EDU (Carla Mowers) (07/25/89)
The results presented in Joshua Levy's RPC paper are based on data that is now nearly nine months old. An article I've posted to comp.misc contains some performance measurements based on new releases of both the Netwise and Apollo products. A new Sun product has not been released since Joshua's measurements were made. The article contains data collected in early June of 1989 by Netwise. All source code used for these measurements may be obtained by sending a request to "tony@wldrdg.UUCP". Please direct all other questions and comments to this account as well. This article is being posted from this account due to technical difficulties with the USENET feed at Netwise. Of course, you should probably take any numbers presented here with a large grain of salt. What one party measures doesn't necessarily correlate well to the environment another is interested in. The leap-frog nature of the game means that any measurement won't be valid long. Internally, we have a next- release prototype that improves on the performance of our currently shipping product as, I'm sure, do the other vendors. The suggestion from Lars Poulsen that ASN.1 encodings lead to poor performance isn't necessarily true. Our performance numbers show us approaching Sun's RPC in several areas (opaque buffers still need work), and our current prototype is, at worst, 2% slower than Sun in the categories we tested. The flexibility of ASN.1 can actually be an advantage. Our prototype exploits this for large buffers. By using a longer length form (one byte longer) we can get the ASN.1 buffer aligned such that bcopy() can make the transfer from the user's buffer to the transmission buffer much more quickly. I believe you'll find the posted information basically lacking in hype. If you view this as a commercial use of the net, I'm sorry. I'm simply responding to an article that contained outdated information regarding one of our products. Tony Andrews Netwise, Inc. 2477 55th St. Boulder, CO 80301 Phone:303-442-8280 UUCP: onecom!wldrdg!tony
mishkin@apollo.COM (Nathaniel Mishkin) (07/27/89)
I'm trying (as I did in my previous posting) to cut down the cross-posting here. Let's try to move the rest of this conversation to comp.protocols.misc. In article <10258@boulder.Colorado.EDU> carla@boulder.Colorado.EDU (Carla Mowers) writes: >The results presented in Joshua Levy's RPC paper are based on data that is >now nearly nine months old. An article I've posted to comp.misc contains >some performance measurements based on new releases of both the Netwise >and Apollo products. A new Sun product has not been released since Joshua's >measurements were made. Actually, the NCS versions (1.0 and 1.1) are more or less the same, in terms of functionality and performance. You don't want to know the mess that's been made of version numbers. Apollo OS versions sr10.1 and later have a newer version of NCS with improved bulk data performance. (This version is called NCS 1.5.) These improvements will also appear in a new NCS version running on Apollo (sr10.2) and non-Apollos and will be called NCS 1.5.1. >Of course, you should probably take any numbers presented here with a large >grain of salt. What one party measures doesn't necessarily correlate well to >the environment another is interested in. Some grains of salt: The data reported in your paper was obtained by running client and server on the same machine. I have to take a fair bit of exception with this. I would imagine that the time to make a remote call is dominated (or at least significantly determined by) the networking costs (i.e. the cost of sending and receiving network messages). The cost of sending intra-machine network messages can be assumed to be roughly zero (relative to the inter-machine cost, anyway). Your tests may thus have measured the relative speeds of things that are a small fraction of the total cost of making a remote call. -- -- Nat Mishkin Apollo Computer Inc., Chelmsford, MA mishkin@apollo.com
conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (07/27/89)
Noting your responses to the RPC article, Nat, can you tell me if NCS represents -only- a specialized RPC functionality, or is there more to the product? -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/27/89)
In article <44a7f591.1d6d5@apollo.COM>, mishkin@apollo.COM (Nathaniel Mishkin) writes: > > (about the RPC #'s) > > Some grains of salt: The data reported in your paper was obtained by > running client and server on the same machine. I have to take a fair > bit of exception with this. I would imagine that the time to make a > remote call is dominated (or at least significantly determined by) the > networking costs (i.e. the cost of sending and receiving network messages). > The cost of sending intra-machine network messages can be assumed to > be roughly zero (relative to the inter-machine cost, anyway). Your tests > may thus have measured the relative speeds of things that are a small > fraction of the total cost of making a remote call. > -- > -- Nat Mishkin > Apollo Computer Inc., Chelmsford, MA > mishkin@apollo.com ahem. Ttcp measurements of raw user-to-user-space TCP and UDP over ethernet and through the loopback drivers do show substantial differences, but much less than 100%. These measurements have been done on the presumably different Sun Microsystems and Silicon Graphics systems (if they're identical, someone's lawyers probably want to know :-). Loopback could be expected to save an interrupt, and maybe a byte copy or two if you're stuck with a bad ethernet controller, but it does not affect the protocol code or number of checksums or byte copies between network buffers and user space. The big work is required or finessed regardless, and costs the same, unless the ethernet hardware is helping. Vernon Schryver Silicon Graphics vjs@sgi.com
cks@white.toronto.edu (Chris Siebenmann) (08/01/89)
mishkin@apollo.com (Nathaniel Mishkin) writes: | I would imagine that the time to make a remote call is dominated (or | at least significantly determined by) the networking costs (i.e. the | cost of sending and receiving network messages). At least with Sun's RPC running over tcp, this is not the case as I discovered to my surprise last summer. If you're exchanging structured data, the networking overhead is completely swamped by XDR overhead, even for Sun<->Sun connections using only integers. -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks