NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/bbs/misc/910

Internet Message Format | 1992-09-09 | 3.6 KB

Path: sparky!uunet!cs.utexas.edu!sun-barr!sh.wide!wnoc-kyo!kuis!aegis!davidg
From: [e-mail] (Dave McLane)
Newsgroups: comp.bbs.misc
Subject: Re: Running a BBS under DOS, OS/2, or Linux?
Message-ID: <[e-mail]>
Date: 9 Sep 92 13:52:14 GMT
References: <[e-mail]> <[e-mail]>
Organization: Aegis Society, Kyoto Japan
Lines: 70

[e-mail] (Tony Shepps) writes:

>[e-mail] (Dave McLane) writes:

>> Putting the news on second 330MB ESDI hard disk made some
>> improvement, but not much. Putting the system on a 486 33MHz made
>> some improvement, but not much.

>Our configuration is much like yours, Dave.  We found the greatest
>improvement was to be had by going to a faaaaast SCSI drive.  The ESDI drive
>was NOT an improvement.

I'd like to know what you did as I just sent back a SCSI drive that
was so bloody slow compared to my ESDI that I couldn't believe it.
Could have just been the drive (Seagate ~300 MB) or the controller
(Ultrastore 12F) but I gave up on it. It was a slow as the 180MB
IDE drive I had at first....

>Another thing that lead to some improvement, but not much, was to "nice" the
>news unbatching process.  The hard drives still grind, and I/O is still the
>major bottleneck on the system, but the users can get in there while the
>unbatching is happening, and nobody complains about slowness.

I have mine niced to the max, and it's still too slow. However,
about here I think we need to define what's 'slow'.

I've found that users' perception of speed is a function of both of
these factors. If the system runs at a relatively constant speed it
will be perceived as 'faster' than a system which may be overall
faster but varies greatly in speed. Thus I have two criteria: 1) how
long after you enter a command do you get a response, 2) how
constant is that response.

One of the main features of Aegis is it's overall and relative speed
as line charges are quite high here and people want to be able to
logon quickly, issue a command or two, have their stuff sent to them
and hang up. Average access time is about 3 minutes/call. Except for
local calls (10 yen/3 minutes) everything else is charged in how
many seconds you get for 10 yen: from Tokyo you get 6.5 seconds.
People get nervous with the telco meter clicking away and nothing
coming on their screen :-)

>A typical Unix performance problem caused by placing active partitions at
>opposite (or at least near-opposite) sides of a disk.  That kind of
>configuration causes a lot of unecessary overhead as the disk heads spend
>all their time seeking and less time actually doing reads/writes.  Of
>course, the news is so large that it will cover most of the disk anyway!

Yes, I think it's just facts of life of the OS, hard disks and the
amount of data we're talking about.

Being new to UNIX, I thought it was just my 386 33MHz, but as I
mentioned before I now have access to a Sparc Station and it also
grind when it's doing news. But only on the news server which is
also the dial-in machine.  So when it grinds I just log on to
another machine on the net and it's smooth sailing.

I want to do the reverse: people will log onto (and remain) on the
gateway machine and news (and it's processing) will be on another
machine. The only part I haven't figure out is how to let readnews
run from the gateway machine as I don't think it supports NNTP and I
use it in a lot of scripts to automatically grab news for people and
send it to them....

Dave

--
Dave McLane
JUNET: [e-mail] (ONLY within Japan: post otherwise)
Nagaokakyoshi, Kyoto Japan Tel: [phone] Fax: [phone]