Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!bbn!oberon!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (Don Speck)
Newsgroups: news.admin
Subject: Re: How to eliminate the cost of over 1/5 (or more) of net traffic
Summary: send shortest job first
Keywords: stargate moderated news
Message-ID: <6556@cit-vax.Caltech.Edu>
Date: 16 May 88 02:47:22 GMT
References: <1616@looking.UUCP> <719@fig.bbn.com> <196@ssbn.WLK.COM> <52918@sun.uucp>
Distribution: na
Organization: California Institute of Technology
Lines: 29

[ in reference to Chuq's prioritized batching scheme ]

I had to throttle one of my outgoing newsfeeds.  First in, first out.
A backlog accumulates during the week, and clears on the weekends.
The throttle will top off the uucp queue for that site to a certain
level and hold the rest until something gets sent.  With a backlog
that can reach thousands of articles (and no batching for that site)
it was *essential* to keep the backlog out of the uucp queue.
Grading is not enough.	So, I can attest to the value of a throttle
(and of weekend phone rates).

[ in reference to binaries, etc ]

One of the distinguishing features of binaries and other machine-readable
postings is their large size.  I would guess that the larger the posting,
the less likely that it will be read by a human, especially a busy human.

As I recall, only about 2% of postings exceed 16K bytes, yet they account
for half of the total bytes.

I propose that batches be sorted in shortest-first order.  This will hold
the problem postings for the weekend, and, if done widely, will encourage
more succinct postings (and speed the propagation of cancel messages).
The st_mtime of the article file would be a good tie-breaker.

(I wonder if it would help the compression ratio.  I already sort batches
by article filename in pursuit of higher compression).

Don Speck   speck@vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck