Sorry to subject you all to the following, but THIS irritated the heck out of m e. Can anyone put some pressure on this guy to get a clue as to what's going on ? ------------------------------------------------------------------------------ >As you've no doubt heard, CUNYVM is no longer functioning as a DISTRIBUTE >server. However, there are many LISTSERVs out there which still do not >know this because their PEERS NAMES has not been updated. ............... I wonder if it's because the updates ARE SITTING IN QUEUE AT CUNYVM WAITING TO BE TRANSMITTED?I understand that priority for CPU goes to the users that pay fo r your toys. But, it would seem to make a LOT of sense to be willing to trade a little CPU for increased throughput in terms of the whole network. Right now, t he UCBCMSA-CUNYVM and the CUNYVM-PSUVM are the most overloaded links in the ent ire net -- yet he's asking us to set up a situation where DISTRIBUTE jobs are b eing forced over one of those links only to turn right back around with at leas t 1 if not 2 or more copies of a file destined for sites within 1 hop of CUNY i tself. This is certainly non-optimal, especially in the case of the US to Europ e links. >I have allowed a few jobs to go thru tonight, but I am not going to do >this anymore, so please get your tables current immediately, or files >will be lost. *flame on* Good grief, man! 'Allowed', indeed. Your tone leaves much to be desired. Are yo u saying that you intend to intentionally drop files destined for other sites f or reasons of site policy? I thought that part of the agreement to join BITNET was that you would always make your best effort to deliver files destined for o ther nodes untouched whenever possible. Sheesh. You have a 3090-200. I have a c rummy 4341-1, and you're griping about CPU usage. *I* can find the CPU to suppo rt DISTRIBUTE, and up until WSUVM1 began using LISTSERV, *I* was the only one i n the entire Northwest. It takes a few thousand cycles to process a DISTRIBUTE job - big deal. It saves trasmission time, spool space -- something even you h ave to keep track of. The whole idea behind Eric's LISTSERV is to REDUCE the nu mber of duplicate files getting passed around -- which, by the way, HAVE to pas s through your precious 3090 and take up your resources. Suppose you want to send a file to about 25 people, scattered about the net; sa y 4 on the West Coast, 4 in the South, 10 in Canada, and the rest in Europe. Us ing DISTRIBUTE, you end up with 4 copies of the file -- 1 to LISTSERV@OREGON1, 1 to LISTSERV@UTCVM (or thereabouts), 1 to LISTSERV@CANADA01, and 1 to LISTSERv @DEARN. Now compare sending the things directly -- 25 copies of the same file g oing to different places. The advantage is clear, both in processing time and i n resource utilization. We have the tools IF we decide to use them. *FLAME OFF* My apologies. Decisions like this on really get me steamed, especially when mad e by someone at a hub node and network performance suffers. ---------- David Boyes (503) 686-4394 |BITNET: 556@OREGON1 Systems Group |ARPA : 556%OREGON1.BITNET@ University of Oregon Computing Center| WISCVM.WISC.EDU UUCP: [your fav backbone]...!tektronix!uoregon!oregon2!oregon1!556