🚀 go-pugleaf

In article <30b5bac6.78441152@news>,
[...]
>bri@blah.math.tu-graz.ac.at wrote:
>>The problem with USENET around here, B. Ward, <bri@blah.math.tu-graz.ac.at>
>>24 Nov 95
>>
>>I've been watching the USENET situation here at TU Graz with amazement at
>>the ridiculous manner they've set up their news server. This seems to
>>reflect a deeper problem with news in the whole of Austria, but I can't be
>>sure because I don't have access to the other news servers.

From my experiences I would say that most other news-servers in austria are 
affected in the same way.

>>The symptom we see most directly is that articles take a long time to get
>>here. During good times, they're only two days late. At the time I'm
>>writing this, things are 5 days to a week late (even for articles posted
>>at, say, uni-linz.ac.at). That's just plain ridiculous. There's a reason
>>for this.
>>
>>Put simply, the reason is that no one actually talks to one another.

this is one of the major problems within the ACOnet. You simply don't get
any information.

>>All incoming aconet news appears to come in through a central server called
>>newsfeed.aco.net. This in itself is a stupid idea. In theory, this server
>>has to feed 10 or so other servers, which, with a full feed like that
>>(alt.binaries.* included!), is certainly enough to make it melt. It only
>>seems to have two external feeds that actually give it anything, anyway (but
>>that's actually almost okay).

things are even worse: newsfeed.aco.net has MANY more outgoing feeds to nearly
all sites in eastern europe. This would not be a problem (the machine has
the resources to handle the feeds), but they use  nntplink via file-feeds,
not stdin feed (see discussion of nntplink below).

[...]
>>So, basically, there's really no backup, really no peering, etc. But wait,
>>there's more! They've taken the usual old approach that they always seem to
>>do when there's a problem like this - throw six tons of CPU at it and hope
>>it goes away. news.tu-graz is a DEC Alpha, news.kfunigraz is some HP
>>monster, and newsfeed.aco.net is an RS/6000. As anyone experienced with
>>USENET administration knows, this doesn't work,

CPU most certainly won't help. but a machine with a fast IO-subsystem will.
DECs have fast IO. If you have many news-reader (as any campus-wide news-
server most certainly has), you HAVE to add RAM. You wouldn't want to have
an Inn which is low on RAM.

[...]
>>(It gets even better, too. There's a newsgroup, at.network.aconet, that
>>tells of scheduled outages and things. But of course, after the five days
>>that it takes for those articles to get here from Vienna, the outage has
>>come and gone..)

at.network.aconet is only a mailinglist gated to the news. all network-admins 
of the universities are most certainly subscribed to the mailing-list.

>>So, now that I've explained how a bad news system is set up, let me tell
>>you about a good one that's perfectly feasible here. I have some personal
>>experience with this - it's at the Pennsylvania State University (PSU),
>>where I graduated from many moons ago.
>>
>>PSU has four news servers on campus (there are actually five, but I don't
>>count psuvm (the big iron) because it's a mutant and is just as well
>>ignored). Three of the four are "well-fed," meaning that they have external
>>feeds. These all feed each other - mostly with nntplink because that's
>>more or less instant propagation - which really lessens the load on not
>>only the internet feed itself, but the servers as well, because once one
>>server has an article, then they've all got it and no longer needs to be
>>transmitted. This is the key point, and the thing they don't do here.

Not 100% true. news.sbg.ac.at does it (and I already offered news-feeds
to anyone in *.at in another thread in at.usenet).
I talked to some admins @ newsfeed.aco.net some weeks ago. they use file-
feeds (not channels), because they are easier to debug. looks like they
tried nntplink, but went back to using file-feeds.

>>The
>>result is that in the worst case, you'll probably see an article about six
>>hours after it was posted. Most of the news goes through one server,
>>because it has the fastest feed, but there is backup when you need it and
>>that's something aconet doesn't have.

This is mostly a political problem. When the BMWF made the MAN-deal with
the PTV, the contract looked roughly like that:
	- no volume charges for all traffic going from or to vienna
	  (which makes sense if you look at the overall traffic)
	- volume charges for any other traffic betwenn the universities.

When the MAN was first deployed in austria, our dept. started some video-
conferences with uni-linz. This was stopped within days by aconet/bmwf
due to the high costs. We were told to use MBone (which is tunneld to
Vienna and from there to Linz). So if I start a full-feed to anyone, I most 
certainly will be stopped within a few weeks.

To make things worse, the (not only) international traffic of 5 2-Mbit lines 
must go through one 2-Mbit line (MAN->Vienna).

>>(These aren't fast machines, either. The one machine that most of the news
>>for PSU passes through is a Sun SPARCStation ELC, for example.)
>>
>>[thanks to Dave Barr for providing me with some specifics about this]
>>



>>So, how does this relate to Austria? How could one fix it up?
[...]
>>
>>The things I'm worried about, and why I'm writing this, are the servers in
>>the provinces. The connections aren't so bad from Vienna outwards (normally,
>>that is; as I write this, they're doing nasty things in Vienna making them
>>abnormally slow). There's plenty of bandwidth there; the response times
>>just aren't as quick. With news, response times are important. Furthermore,
>>the connections between the provinces (say, between Graz and Linz),
>>although they go through Vienna, are also pretty spiffy.

Actually they don't go through vienna (that's why they're OK).

:1 mike@loewe:->traceroute news.tu-graz.ac.at
:traceroute to news.tu-graz.ac.at (129.27.2.10), 30 hops max, 40 byte packets
: 1  nawirouter (141.201.2.1)  3 ms  2 ms  2 ms
: 2  141.201.105.1 (141.201.105.1)  4 ms  3 ms  9 ms
: 3  Sbg.ACO.net (193.171.20.18)  5 ms  4 ms  4 ms
: 4  Graz.aco.net (193.171.16.51)  33 ms  21 ms  37 ms
: 5  192.231.67.1 (192.231.67.1)  26 ms  27 ms  22 ms
: 6  fstgal00.tu-graz.ac.at (129.27.2.10)  24 ms  28 ms  28 ms
:2 mike@loewe:->

>>The solution is thus obvious.
>>
>>Each of the servers like:
>>
>>news.tu-graz.ac.at
>>news.kfunigraz.ac.at
>>news.uni-linz.ac.at
>>news.sbg.ac.at
>>news.uibk.ac.at
>>news.uni-klu.ac.at
>>
>>should talk to (that is, feed), say, three of the servers in Vienna (trying
>>real hard to avoid newsfeed.aco.net), and _also_ each other. This would
>>ultilize the network available, provide a reasonable backup, offload the
>>servers, and stay that way for a while to come.

I don't think that additional feeds to Vienna will help the situation.
The MAN->Vienna line is already overloaded. (Perhaps backup-feeds during
the night when line-utilization is lower).

It would help in any case to have the news-servers update each other with
nntplink (as I said, there is a standing offer for feeds from news.sbg.ac.at).

But: I think that all these feeds will be shut down within weeks by aconet/bmwf
due to costs. Still I would give it a trie.

-- 
Thomas 'Mike' Michlmayr can not assert the truth of all statements in 
this article and still be consistent. <mike@cosy.sbg.ac.at>