Re: Current top myths about Usenet

In <[email protected]> D <[email protected]> writes:



>On Wed, 14 Feb 2024, Paul W. Schleck wrote:

>> 6. Usenet costs a lot of money, and is technically difficult, to access

>Good evening Paul,

>How much compute, network and storage to you need to run a news server?
>I thought about trying it out for myself under the protective "roof" of
>my own company. That way I can also deduct the cost from my profits
>while being of some use to others. =)

>Best regards, 
>Daniel

Daniel,

Reading the INN server documentation, the answer appears to be, "It
depends:"

  https://www.eyrie.org/~eagle/software/inn/


Also asking some friends and colleagues who run personal NNTP servers or
even multi-user ISP's/NSP's, the answer is also, "It depends," but they
offer some helpful details.


One friend who operates a personal NNTP server writes:

"The best thing I can offer is this:

   http://panix.com/v-colo/plans.html

I run my news server with a full-ish, non-binary feed on a V-C 2 package
from Panix.  That's a 6GB RAM system, 10-20GB of disk space, and the
network isn't an issue at all; and I use the machine for other purposes
too (email, personal login, etc).  This would obviously need to be more
robust if the server was used by lots and lots of people, but I don't
feel like co-location would be a significant problem nowadays.

The hard part, IMO, is the expertise of getting everything set up,
getting feeds, and keeping it running."


Another colleague who runs an NNTP server for a national ISP/NSP writes:

"The answer is too dependent on the details - how many users, how much
they use, and what groups you want to carry. But... that's probably only
true if you're trying to do things at scale for thousands of users.

FYI, we have one feeds machine and two readers. When I architected this
originally, it was for load management. I'd still do it that way,
because it's a commercial service and because machines are cheap. But
it's drastically overkill for any lesser demand, and waaaay more
capacity than we need.

For our machines, the load is trivial. Here's average disk i/o stats on
the active reader machine since boot (~30 days):

reader1# iostat -y
device  read KB/t    r/s     MB/s write KB/t    w/s     MB/s   wait   actv  wsvc_t  asvc_t  wtime   time
ld0         20.24      0     0.00      24.37      5     0.12    0.0    0.0    0.00    0.41   0.00   0.00
ld1          3.99      0     0.00      63.78      0     0.00    0.0    0.0    1.95   13.93   0.00   0.00
ld2         20.57      0     0.01      17.89      4     0.08    0.0    0.0    0.01    0.50   0.00   0.00
ld3          4.20      1     0.00       4.70      0     0.00    0.0    0.0    0.00    0.61   0.00   0.00
ld4         62.14      0     0.01      27.53      0     0.00    0.0    0.0    0.00    3.48   0.00   0.00
ld5         62.13      0     0.01      27.50      0     0.00    0.0    0.0    0.00    4.23   0.00   0.00

The only stats that matter (given the low load) are r/s and w/s. As you
can see, it's... basically no disk load at all. Even spinning rust
wouldn't be challenged. But why bother with that? Buy a used SATA 256GB
or 512GB MLC SSD, and you're probably set for life.

Now, the thing to remember is, you can make the wrong choice configuring
your server, and that would make the machine problematic even with
SSDs. Do not use file-per-article under any circumstances. Use cyclical
buffers, which are an option in INNd and may be the default now. If
you're using some other news server, make sure you do the same.

In 1995 the load was enormous. In 2000 it was even worse. But by then
cycbuffs were a thing, and they solved the problem. Nowadays, volume is
much lower, absent binaries, and aside from dealing with spam issues,
it's not all that much.

As for network and CPU - they're both just as trivial, except for daily
processing, which happens overnight and takes fairly little time.

So the short answer is: As long as you do it right, you could probably
do it on a Raspberry Pi."


Hope this helps.  If you wish, I could put you directly in touch with
these individuals for further questions.

--
Paul W. Schleck
[email protected]