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
|
