home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!wupost!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!caen!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!telcom.arizona.edu!leonard
- Newsgroups: vmsnet.networks.tcp-ip.multinet
- Subject: Re: Lingering processes - possible efficency improvem
- Message-ID: <1992Nov8.130057.3966@arizona.edu>
- From: leonard@telcom.arizona.edu (Aaron Leonard)
- Date: 8 Nov 92 13:00:56 MST
- Reply-To: Leonard@Arizona.EDU
- References: <18951.2afb696e@ecs.umass.edu>
- Distribution: na,local
- Organization: University of Arizona Telecommunications
- Nntp-Posting-Host: penny.telcom.arizona.edu
- Lines: 37
-
- In article <18951.2afb696e@ecs.umass.edu>, jhwelch@ecs.umass.edu writes:
- |
- | We're running MULTINET on a burdened vax 11/780 and any kind
- | of performance improvement would be of help.
- |
- | In a future release of multinet would it be possible to have
- | the processes created to service SMTP and FINGER (and maybe others?)
- | linger for a short time like FAL connections do for DECNET?
-
- 1. Take the amount of money the Massachusetts taxpayers are
- squandering annually by having you run your 780 (electricity
- consumption, airconditioning, software licensing, floorspace,
- maintenance if any).
-
- 2. Divide this amount into two parts.
-
- 3. Take one part of this money and buy a VAXstation 4000/90 or
- a MicroVAX 3100/80 with 48MB of third-party RAM and a couple
- of fast SCSI disks. Install this box. Haul the 780 off to the dump.
-
- Your peformance problems will be solved. You will stop worrying
- about the overhead of creating `fingerd' processes and be able
- to perform productive work instead.
-
- 4. Give the other half of the money to me for improving your
- performance and saving your state so much money at the same
- time.
-
- Best,
-
- Aaron
-
- Aaron Leonard (AL104), <Leonard@Arizona.EDU>
- University of Arizona Network Operations, Tucson AZ 85721
- "It's not a bug, it's a form of flow control."
- - Jerry Leichter on why crash-prone Unix is a suitable
- platform for NSFNET core routers
-