On Fri, 10 Feb 1995 12:12:00 EST Bill Verity <[log in to unmask]> said: >I've been trying to follow these discussions but I'm still not clear. >Would our running the TCP/IP product help our load? Most of our BITNET >traffic goes out over BITNET-II which is in fact the Internet lines. >RSCS is rarely saturated. The SMTP machines are the ones that can't keep >up. To answer these questions it helps to separate the "core node" function of PSUVM with its "traffic producer" function. That is, on the same machine you are running a LISTSERV that is used both as a core router and to deliver mail for PSU's own mailing lists. The core function only makes sense if you are running your server in NJE mode. That is, you cannot act as a switchboard for NJE jobs unless you run your server in NJE mode. One could probably work out a setup based on a specially configured LTCP where you would receive jobs from your region via NJE, and use SMTP to deliver them to the other core nodes involved. This however would not be a good use of your or the receiving core site's resources. If as a central NJE switchboard site you need to cut 7 copies of a job and send them to other core sites, it is more cost effective (on VM) to do that using NJE. The idea of LTCP is to (1) decrease the use of this switching function by reducing the number of such switching "hops" from the current LISTSERV-NJE setup, which is based purely on BITNET topology, and (2) move the switching functions to cheap workstation or PC systems. As a producer of traffic for PSU's own lists, it would however help if you switched to the version LTCP that is about to be released, the one with the change to stop using BITNET altogether. It would not help PSUVM itself, since on VM a NJE delivery is less expensive than an SMTP delivery, but it would help the other core sites because you would no longer be sending them jobs via NJE for the traffic that PSU lists generate. In general, as traffic producers migrate to LTCP, the load on the core will be reduced. Finally, as a delivery engine it would help if you ran a copy of the unix (or VMS) LISTSERV on a cheap workstation-class system and configured your VM LISTSERV to direct all Internet messages to that machine. This trades the current set of SMTP messages, with all the queuing and delivery done on VM, with "leaner" SMTP messages that have just one recipient on a local, well connected machine. Your SMTPs would be able to deliver these messages immediately and would not accumulate a queue on their 191. Having only one RCPT TO: to process would also speed up the delivery compared to the current setup, so the spool queues would probably go away. Eric