LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Bill Rubin <WGRCU@CUNYVM>
Thu, 20 Nov 1986 17:00 EST
text/plain (36 lines)
First, there was close to a 2000 file queue at OHSTVMA to be sent to PSUVM
earlier this week. The PSUVM link was in an INACTIVE state at OHSTVMA for
a couple of hours (at least), and it is not clear that anyone made attempts
to start it.
 
As for ARPA digests, to help speed Bitnet traffic, we've got all ARPA mailing
list files of greater than 300 lines going thru the net at priority 55. The
reasoning behind this is that of all things you're expecting on the net, digest
files such as IBMPC, or worse, UNIX-SOURCE, are not one that you have any idea
when they will show up, so an extra few hours can't hurt, and it's better that
they do not sit in front of other priority 55 files such as stuff you've
requested from file servers. Since I am one of the originators of the priority
55 for file server files philosophy, I can take the blame, I suppose. I have
recently been rethinking this and begun to think that perhaps a smallest out
first without regard to priority scheme might work better than what we have
now. My original feeling was that files from the server were not that important
and should not block other more important files. But when you look at it in
practice, what is more important than a file that you've manually asked to have
sent to you! The only problem with setting these files to priority 55 is that
some of our servers send files that are 15,000 records long (even though
people who still have DISK DUMP set as their default should be tarred and
feathered - flames to me, please). It's for that reason that I was thinking
an all one priority queueing scheme would work best, especially when you get
people who send 100,000 record files at priority 0. I'm interested in comments,
please mail to me directly and I'm summarize to the list.
 
As for duplicate IBMPC Digests, the problem is that the sending site is timing
out before WISCVM can acknowledge receipt of the file. There is a simple
solution - the sending site can change their timeout value so the transmission
does not appear to the sender to have not completed normally. Matt Korn of
WISCVM asked them to do this several weeks ago, and judging from the fact that
he had to purge several hundred duplicate IBMPC digests yesterday, I gather
that they have not yet changed it.
 
Bill

ATOM RSS1 RSS2