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
carla@boulder.Colorado.EDU (Carla Mowers) (07/29/89)
Nat Mishkin writes: > 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. Let's assume that our times are skewed in that the data transmission times are lower than in the average user's environment. This would effectively magnify all other times involved in making a remote procedure call. In general, for a portable RPC product, these are the only times one has control over from one network environment to another. So I would claim that the comparison is still useful. Further, if we remove data transmission times, most of what remains involves data marshalling. Consider how the products were affected in that respect. Sun had an advantage in that the measurements were made on a Motorola-based system, whose byte ordering tends to be favored by the XDR encodings. Apollo had an advantage in that the tests were made in a homogeneous setting, eliminating the need for any data conversions. Netwise uses ASN.1 encodings which tend to not favor any particular processor, and are not improved by a homogeneous environment. So, if anything, we've magnified our own weaknesses more than those of Sun or Apollo. Tony Andrews Netwise, Inc. 2477 55th St. Boulder, CO 80301 Phone: 303-442-8280 UUCP: onecom!wldrdg!tony
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