Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!dayton!meccts!mn-at1!alan From: alan@mn-at1.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: IP Datagram sizes Message-ID: <383@mn-at1.UUCP> Date: Wed, 27-May-87 16:32:19 EDT Article-I.D.: mn-at1.383 Posted: Wed May 27 16:32:19 1987 Date-Received: Sat, 30-May-87 05:40:28 EDT References: <8705261555.AA14106@ames-nas.arpa> Reply-To: alan@mn-at1.UUCP (0000-Alan Klietz) Distribution: world Organization: Roseville, MN Lines: 35 In article <8705261555.AA14106@ames-nas.arpa> yamo@AMES-NAS.ARPA (Michael J. Yamasaki) writes: > >Selecting 576 for a gateway between ethernet and HYPERchannel is >a losing proposition. Yes. In 1985, we did some benchmarks to determine the impact of running screen editors on the Cray-2. The worry was that CPU overhead for context switching would be prohibitively expensive. It turned out that while the CPU impact was acceptable (8% usage of 1 CPU for 32 users running heavy simulated vi), the Hyperchannel was com- pletely saturated. It turns out that a Hyperchannel is limited to ap- proximately 300 blocks/sec. This is independent of block size. By plotting block size to bandwidth, you get a curve that flattens out to around 8 megabits/sec for a block size of 64-128 kilobits, but it nudges 11 megabits/sec for block sizes larger than 512 kilobits. (Not coincidentally, this is the block size we chose for the Extended File System.) These are special conditions (dedicated LAN, no gateway, low-lossage), obviously, but it would be nice if future protocols could be designed not to limit packet sizes to 64K just because of a 16 bit field width. (Shades of Intel :->) -- Alan Klietz Minnesota Supercomputer Center (*) 1200 Washington Avenue South Minneapolis, MN 55415 UUCP: ..rutgers!meccts!quest!mn-at1!alan Ph: +1 612 626 1836 ..ihnp4!dicome!mn-at1!alan ARPA: alan@uc.msc.umn.edu (was umn-rei-uc.arpa) (*) An affiliate of the University of Minnesota