Very Computer

I'm in charge of a small network (6 SGI workstations), and I've been
looking into getting a cheap PC to use as a fileserver and to run a CD
burner.  Recently, I was informed of the possibility of getting a 100MHz
Pentium for free.  Obviously, this won't be able to handle the
fileserver aspect of this, but is there any chance of using it to run a
CD burner?

Thanks,
Mark Wagner

Quote:> I'm in charge of a small network (6 SGI workstations), and I've been
> looking into getting a cheap PC to use as a fileserver and to run a CD
> burner.  Recently, I was informed of the possibility of getting a 100MHz
> Pentium for free.  Obviously, this won't be able to handle the
> fileserver aspect of this, but is there any chance of using it to run a
> CD burner?

  Geez, you call that ancient?

   Back when burners first came out, that would either be a
top-of-the-line computer, or a not-yet-available-burner.

   CD burning in and of itself doesn't require much CPU - only throughput,
assuming that you're not going to be converting .mp3's to .wav's on the
fly, or something like that.  As long as your hard drive can keep spitting
out data as fast as the burner needs it, you're going to do fine.

  As for the file server aspect, CPU isn't a terrible concern, provided
that you have a good disk subsystem.

steve

Quote:>I'm in charge of a small network (6 SGI workstations), and I've been
>looking into getting a cheap PC to use as a fileserver and to run a CD
>burner.  Recently, I was informed of the possibility of getting a 100MHz
>Pentium for free.  Obviously, this won't be able to handle the
>fileserver aspect of this,

Why? How much network and file access are you expecting? How old is the
P100?  FWIW, I run a P90 as a file server for my group at work(6 WinNT
systems), and a Cyrix6X86/120 (P133 equivalent) as a fileserver at home.
With the proper hard drives, and enough memory (16M or more), it should be
useable as a file server.

Quote:>but is there any chance of using it to run a CD burner?

Most certainly.

Quote:>Thanks,
>Mark Wagner

Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employer's.)

The problem *is* the disk system.  I'm fairly sure this computer can't
handle the large disk sizes needed -- this is a computer graphics lab at
a university, and student projects tend to get into the several hundred
megabyte range, so to keep two semesters worth of student projects on
disk at a time, I figure any fileserver will need at least a 20GB hard
disk, and preferably a much larger one.

My main concern for setting up this server is keeping the cost low --
this year's entire hardware budget, and part of next year's budget, is
already going towards replacing one of the SGI machines with a newer
model.

--
Mark Wagner

Quote:> The problem *is* the disk system.  I'm fairly sure this computer can't
> handle the large disk sizes needed -- this is a computer graphics lab at
> a university, and student projects tend to get into the several hundred
> megabyte range, so to keep two semesters worth of student projects on
> disk at a time, I figure any fileserver will need at least a 20GB hard
> disk, and preferably a much larger one.

  A new IDE controller that can handle large disks doesn't cost much, and
if you're using Linux, it shouldn't matter if the BIOS of the machine
supports large disks or not - only that Linux supports the controller that
you purchase.  Then you can put in all of the disks that you want.

  If it's going to be keeping student projects, you had better consider
redundancy in the disks, unless you want a few hundred really, really
angry students forming a *-mob three days before the end of the
semester....

steve

Try to over-clock it.  My (free) file server is running on a
overclocked 133 to 200.  My (free) file server works quite well for
four LAN (10M) connections and a T1 (1.5M) internet connection.

Quote:> > Pentium for free.  Obviously, this won't be able to handle the
> > fileserver aspect of this, but is there any chance of using it to run a
> > CD burner?

Should be fine for SCSI.  Might be a problem for IDE.

Quote:

>   Geez, you call that ancient?

>    Back when burners first came out, that would either be a
> top-of-the-line computer, or a not-yet-available-burner.

But they ususally have problems with data underrun caused by network
latency.

Quote:

>    CD burning in and of itself doesn't require much CPU - only throughput,

But IDE drives take some CPU time.

Quote:> assuming that you're not going to be converting .mp3's to .wav's on the
> fly, or something like that.  As long as your hard drive can keep spitting
> out data as fast as the burner needs it, you're going to do fine.

>   As for the file server aspect, CPU isn't a terrible concern, provided
> that you have a good disk subsystem.

> steve

Depends on buffering...

Quote:>>   Geez, you call that ancient?
>> Back when burners first came out, that would either be a
>> top-of-the-line computer, or a not-yet-available-burner.
> But they ususally have problems with data underrun caused by network
> latency.
>>    CD burning in and of itself doesn't require much CPU - only
>>    throughput,
> But IDE drives take some CPU time.

.. And you need to ensure the CD-R's buffer stays full.

In the "bad old days," this meant that if the system connected to the
CD-R had _anything_, and I mean _anything_, other than the CD burning
software running, there was a good chance of burning a coaster.

More recently, the units tend to have a meaningfully useful amount of
memory on them, on the order of a few MB of RAM.  That's REALLY
helpful, the CPU only forcibly needs to talk to the CD-R once every
few seconds in order to top up the buffer, rather than it needing to
be every few milliseconds.  With this approach, the probability of the
buffer emptying falls to near zero.  You only have a problem if your
system starts swapping like crazy, and with cheap RAM, that's much
less of a problem than it used to be.

In fact, in these Super Modern Days, there are CD burners that are
_so_ smart that they can wait until the buffer has enough data to burn
a track/sector/cluster/whatever-unit-of-measure, and if it runs out of
data, it'll happily stop and wait for more input.  Plextor seems to be
the "famous name" in this regard.

If the CD-R is a pretty new unit, there oughtn't be any major problems
even with a _fairly_ old system, just so long as the CD-R has decent
buffers.  If it's an ancient CD-R, well, that could be a problem...
--

http://www.cbbrowne.com/info/languages.html
"Other than that, Mrs. Lincoln, how was the play?"

Was not mine experience with 100 Mhz 486 (PCI). It was all-SCSI box
though. And it had one of the first generation CD-Rs (SCSI though).
The primary reason I got this burner was because I've convinced my
supervisor that my 486 linux box does not produce nearly as many
coasters as the NT 3.5 driven Pentium box that the burner was originally
attached to. Not only that but I don't remember a single case when
the buffer was less than 80% full. I've burned in excess of a hundred
CDs on that machine in 1996-1999 and in 2001.

Quote:> More recently, the units tend to have a meaningfully useful amount of
> memory on them, on the order of a few MB of RAM.  That's REALLY
> helpful, the CPU only forcibly needs to talk to the CD-R once every
> few seconds in order to top up the buffer, rather than it needing to
> be every few milliseconds.  With this approach, the probability of the
> buffer emptying falls to near zero.  You only have a problem if your
> system starts swapping like crazy, and with cheap RAM, that's much
> less of a problem than it used to be.

Cheap RAM will be a problem regardless of the task. Right?

Quote:

> In fact, in these Super Modern Days, there are CD burners that are
> _so_ smart that they can wait until the buffer has enough data to burn
> a track/sector/cluster/whatever-unit-of-measure, and if it runs out of
> data, it'll happily stop and wait for more input.  Plextor seems to be
> the "famous name" in this regard.

> If the CD-R is a pretty new unit, there oughtn't be any major problems
> even with a _fairly_ old system, just so long as the CD-R has decent
> buffers.  If it's an ancient CD-R, well, that could be a problem...

.. but not for the load reasons if it's a SCSI drive. Most likely it's
just worn to the point that it can't function as a writer any longer.
But that really depends.

Step another generation back, to 1994-1995, when PCI was just getting
installed, NT 3.1 was the "server standard," people were using WFW,
and Linux was pretty much new...

cdrecord ought to play much better, even on ancient hardware, than the
CD burner software of the mid'90s, to be sure...

Quote:>> More recently, the units tend to have a meaningfully useful amount of
>> memory on them, on the order of a few MB of RAM.  That's REALLY
>> helpful, the CPU only forcibly needs to talk to the CD-R once every
>> few seconds in order to top up the buffer, rather than it needing to
>> be every few milliseconds.  With this approach, the probability of the
>> buffer emptying falls to near zero.  You only have a problem if your
>> system starts swapping like crazy, and with cheap RAM, that's much
>> less of a problem than it used to be.

> Cheap RAM will be a problem regardless of the task. Right?

No, the point is that with RAM _being cheap_, people tend to have more
of it, and are vastly less likely to swap...

Quote:>> In fact, in these Super Modern Days, there are CD burners that are
>> _so_ smart that they can wait until the buffer has enough data to
>> burn a track/sector/cluster/whatever-unit-of-measure, and if it
>> runs out of data, it'll happily stop and wait for more input.
>> Plextor seems to be the "famous name" in this regard.  If the CD-R
>> is a pretty new unit, there oughtn't be any major problems even
>> with a _fairly_ old system, just so long as the CD-R has decent
>> buffers.  If it's an ancient CD-R, well, that could be a problem...
> .. but not for the load reasons if it's a SCSI drive. Most likely
> it's just worn to the point that it can't function as a writer any
> longer.  But that really depends.

Wouldn't there be an issue of minscule [on-the-CD-R] buffers emptying
on something rather old?

There was a server at an old office devoted to the CD-R, and there
were express instructions not to have anything else going on whilst
burning a CD.  That was in about '94, and I used to use the machine to
scan images, so it's certain it was doin' SCSI...
--

http://www.cbbrowne.com/info/wp.html
"I have stopped  reading Stephen King novels.  Now I  just read C code
instead."  -- Richard A. O'Keefe

I've seen Promise ATA66 controllers going for $15.  The one in my old
Celeron is giving me good performance, even if the memory is running at
100MHz.  I'm quite happy with it as a file server - BX chipset, 512MB RAM,

I got a CD-R running under RedHat 6.0 on an IBM 466DX2.  It is certainly
do-able on your machine.

Good luck.

Quote:> I'm in charge of a small network (6 SGI workstations), and I've been
> looking into getting a cheap PC to use as a fileserver and to run a CD
> burner.  Recently, I was informed of the possibility of getting a 100MHz
> Pentium for free.  Obviously, this won't be able to handle the
> fileserver aspect of this, but is there any chance of using it to run a
> CD burner?

> Thanks,
> Mark Wagner