9 Oct
2004
9 Oct
'04
11:21 a.m.
I said I'd look at what is in there, here's the scoop.
Boom 1U case, room for MB, PS, many fans, two HD's, slimline floppy and
slimline CD, and a single PCI card
ASUS TUSI-M motherboard
Intel Celeron 1.2ghz, 256K cache, 100mhz FSB
(2) 512mb low profile SDR DIMMS
Mitsumi SR243T1 slim cd
Citizen OSDA-39D floppy drive (heavily modified with a dremel tool to fit
right)
20gb PATA drive for OS
160gb PATA drive for data, list, websites, etc.
The motherboard ide controller is ATA100 or 133, I forget which. Before you
snivel at the hardware... the classiccmp server doesn't NEED to be extremely
fast and seems to do just fine with the horsepower it has. Of course that's
because it runs FreeBSD (trolling).
The end-goal here is reliability in case of drive failure. I see two
options. I could get an additional 160HD, a Promise raid 1 card, and a riser
card (think I already have one). Then the OS & data would be on one 160gb
drive and we'd mirror to the other 160gb. This is the cheapest option.
The other option would be using a motherboard with built-in raid. This would
involve replacing the motherboard, the memory, and the cpu. Perhaps the
power supply too, which may or may not mean a new case.... I would still
need to buy another 160gb drive. Definitely a lot more expensive. Plus since
it's an older 1U case, trying to find a motherboard that fit it just right
may be troublesome with boards being sent back cause they dont fit, etc.
Plus the frustration of trying to make sure the newer/faster processor
heatsink and fan would fit into the 1U case, which can sometimes be
impossible.
In the event that the server runs out of horsepower, if we go the first
route, we wouldn't have lost any investment cause we'd still be able to use
the two 160gb PATA drives. The only money wasted would be on the promise
RAID controller.
So, my vote would be to go with another 160gb, riser card, and promise raid
1 card. But I'm open to any and all options. Theres about $200 or so in the
kitty right now for the server. I'd love some input, mayber there's options
I haven't thought of.
Regards,
Jay West
9 Oct
9 Oct
9:03 p.m.
On Sat, 9 Oct 2004 18:21:40 -0500
"Jay West" <jwest(a)classiccmp.org> wrote:
So, my vote would be to go with another 160gb, riser
card, and promise
raid 1 card.
Those Promise "RAID" cards don't do hardware RAID. They
handle RAID
entirely in software, by there own BIOS for booting / DOS and via a
proprietary drivers for the OS. Stay away from this. (IIRC NetBSD has a
driver for this crap that recognizes the Promise RAID layout and uses it
as a RAIDframe software RAID volume or the like.)
As you are running FreeBSD: What about vinum(4)???
The machine should be fast enough to handle RAID1 in software. No
problem with the Promise BIOS stuff, no cost for an extra PCI card.
If you want real hardware RAID look for a 3ware card.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
10 Oct
10 Oct
1:33 a.m.
Jochen wrote...
Those Promise "RAID" cards don't do
hardware RAID. They handle RAID
entirely in software, by there own BIOS for booting / DOS and via a
I don't
*THINK* that is true, at least as a generalization. There may be
some low end cards from promise that don't really do hardware raid, and
there may be promise chips built into some motherboards that don't really do
hardware raid, but - my experience is that most of their ata raid cards
actually do hardware raid. Can someone clarify for sure?
As you are running FreeBSD: What about vinum(4)???
The machine should be fast enough to handle RAID1 in software. No
problem with the Promise BIOS stuff, no cost for an extra PCI card.
I won't do
OS-land raid. Doing any raid level in the OS is simply... brain
dead. For the same reasons that I refuse to use a WINmodem in a windows
machine. It's inherently bad engineering to waste/degrade the main systems
cpu for this kind of thing.
If you want real hardware RAID look for a 3ware card.
I'll look at 3ware, but like I said I was under the impression many (most)
promise cards did do real hardware raid.
Jay West
5:47 a.m.
Jay West wrote:
I would agree with you if the server was a SPARCstation5 or
something. As you said yourself, we've got cycles to burn here.
Actually, I *did* agree with you for a long time, for almost exactly
the same reasons, but was coerced - I like my job and the client's
always King - into using Linux software RAID1 a couple of years ago.
The last time I logged into that box it had over 600 days uptime, and we
have several production machines of our own running RAID1 in software.
Promise says they do, and proves it by the fact that there's a RAID
BIOS setup. They lie, pure and simple.
Doc
Jochen wrote...
I haven't seen any Promise chip that does hardware RAID. I have a
simple rule of thumb - if I define a LUN in the RAID BIOS and my OS sees
the physical member disks, it ain't RAID. All the Promise models we've
tested or I've heard feedback on do exactly what Jochen says.
Those Promise "RAID" cards don't do
hardware RAID. They handle RAID
entirely in software, by there own BIOS for booting / DOS and via a
I don't *THINK* that is true, at least as a generalization. There may be
some low end cards from promise that don't really do hardware raid, and
there may be promise chips built into some motherboards that don't
really do hardware raid, but - my experience is that most of their ata
raid cards actually do hardware raid. Can someone clarify for sure? As you are
running FreeBSD: What about vinum(4)???
The machine should be fast enough to handle RAID1 in software. No
problem with the Promise BIOS stuff, no cost for an extra PCI card.
I won't do OS-land raid. Doing any raid level in the OS is simply...
brain dead. For the same reasons that I refuse to use a WINmodem in a
windows machine. It's inherently bad engineering to waste/degrade the
main systems cpu for this kind of thing. If you want
real hardware RAID look for a 3ware card.
I'll look at 3ware, but like I said I was under the impression many
(most) promise cards did do real hardware raid.
6:29 a.m.
It was written....
I haven't seen any Promise chip that does
hardware RAID. I have a
simple rule of thumb - if I define a LUN in the RAID BIOS and my OS sees
the physical member disks, it ain't RAID. All the Promise models we've
tested or I've heard feedback on do exactly what Jochen says.
Interesting. I
haven't used a promise card in a long time... but I thought I
recalled the OS (FreeBSD) only seeing the logical drives, not the physical
ones. I could well be wrong. Looks like 3ware two drive raid 0,1 controllers
can be had for $115. Add to that a $60 some odd cost for another 160gb
drive, and we should be cool.
I would agree with you if the server was a
SPARCstation5 or something.
As you said yourself, we've got cycles to burn here.
Just because you CAN do a
thing, doesn't mean you should. I view cpu cycles
as precious and not to be used frivolously even when available in good
supply. Perhaps it dates back to my mentality of pouring over machine code
to save a cycle here and there :)
The last time I logged into that box it had over 600
days uptime, and we
have several production machines of our own running RAID1 in software.
I wasn't
saying it wasn't reliable, just not the best use of the main cpu.
I'd also lay odds that it isn't as fast.
Thanks for the input Doc!!
Jay West
7:19 a.m.
Rumor has it that Jay West may have mentioned these words:
It was written....
Yea, but if you don't get caught, it ain't illegal, right??? ;-)
I would agree with you if the server was a
SPARCstation5 or something.
As you said yourself, we've got cycles to burn here.
Just because you CAN do a
thing, doesn't mean you should. I view cpu cycles as precious and not to be used
frivolously even when
available in good supply. Perhaps it dates back to my mentality of
pouring over machine code to save a cycle here and there :)
I understand that mentality as well, but most times, CPU's sit around
twiddling their thumbs waiting for the HDs (especially IDE) anyway...
If you can whiz away a few cycles to keep the CPUs *busier*, everything
speeds up.
I wasn't saying it wasn't reliable, just not
the best use of the main cpu.
I'd also lay odds that it isn't as fast.
As fast as what? Hardware raid? Of course.
The last time I had a striped software raid setup (2 4.3G IBM UltraStar
7200rpm SCSI drives on a Diamond MultiMedia Fireport 40 (symbios chipset
wide card) I gained ~75% thruput compared to a single drive. Sure, maybe I
could have gotten 85-90% out of a hardware SCSI raid card, but I didn't
have the $300 to drop for that... And the system still *got faster* because
the CPUs weren't in IO-wait nearly as often.
It all depends on the application, just like any other benchmark; and it
all depends on where your bottleneck(s) is(are).
If IO-wait is minimal, and the CPUs are taxed (or you can foresee that they
would be in the near future) then I wholeheartedly agree with you.
Laterz,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger -- sysadmin, Iceberg Computers
zmerch(a)30below.com
What do you do when Life gives you lemons,
and you don't *like* lemonade?????????????
4:49 p.m.
Jay West declared on Sunday 10 October 2004 01:29 pm:
It was written....
As well, I've played quite a bit with software RAID, and have used
Linux's software raid 5 at work on production Compaq quad Pentium Pro
boxes, on a Sun E3000, and various other things including some 533MHz
Alpha machines with Qlogic FC cards and FC JBODs. I've never noticed a
bit hit in CPU performance when using software raid. In every case, I
was able to max out the I/O channel performance when doing benchmarks of
the software raid.
I've never had data loss from software raid, except when I failed two
drives in a raid 5 set at once (oops). Even pulling the cord when the
machine was rebuilding the raid left the data intact, which impressed
me.
You might get better speed by using a hardware raid card, but unless
you're doing stuff that needs high performance. Besides, I've had more
issues with hardware raid doing stupid things or having poor
performance, but that's probably because I was using "older" PC raid
stuff.
Pat
--
Purdue University ITAP/RCS --- http://www.itap.purdue.edu/rcs/
The Computer Refuge --- http://computer-refuge.org
I would agree with you if the server was a
SPARCstation5 or
something. As you said yourself, we've got cycles to burn here.
Just because you CAN do a thing, doesn't mean you should. I view cpu
cycles as precious and not to be used frivolously even when available
in good supply. Perhaps it dates back to my mentality of pouring over
machine code to save a cycle here and there :)
The last time I logged into that box it had over
600 days uptime,
and we have several production machines of our own running RAID1 in
software.
I wasn't saying it wasn't reliable, just not the best use of the main
cpu. I'd also lay odds that it isn't as fast.
8:38 p.m.
On Sun, 10 Oct 2004 13:29:49 -0500
"Jay West" <jwest(a)classiccmp.org> wrote:
Interesting. I haven't used a promise card in a
long time... but I
thought I recalled the OS (FreeBSD) only seeing the logical drives,
not the physical ones.
Maybe FreeBSD has a special driver that can detect the
Promise RAID
setup and do the software RAID just like the Promise BIOS?
I could well be wrong. Looks like 3ware two drive raid
0,1 controllers
can be had for $115. Add to that a $60 some odd cost for another 160gb
drive, and we should be cool.
You have to by two RAID controllers if you wane be
real save. You need a
spare in case the RAID controler fails. The RAID controler is a single
point of failure!
Just because you CAN do a thing, doesn't mean you
should. I view cpu
cycles as precious and not to be used frivolously even when available
in good supply. Perhaps it dates back to my mentality of pouring over
machine code to save a cycle here and there :)
It depends on the load that the
server already has and how much overhead
software RAID1 causes. Typically RAID1 doesn't cost that much CPU. To
the past - present comparision: CPUs got a _lot_ more faster then disk
dirves in the past 20 years. See the thoughts behind the BSD LFS.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
11 Oct
11 Oct
3:12 a.m.
On Mon, 11 Oct 2004, Jochen Kunz wrote:
You have to by two RAID controllers if you wane be
real save. You need a
spare in case the RAID controler fails. The RAID controler is a single
point of failure!
They call that controller duplexing. Separate controllers,
active,
preferrably on separate buses.
It depends on the load that the server already has and
how much overhead
software RAID1 causes. Typically RAID1 doesn't cost that much CPU. To
the past - present comparision: CPUs got a _lot_ more faster then disk
dirves in the past 20 years. See the thoughts behind the BSD LFS.
I have never
trusted OS-level disk redundancy schemes, and never
will. Promise controllers have strange ways of doing things, and
most certainly do require OS-level software assistance. Disks
attached to a Promise RAID1 controller can be taken off the Promise,
and attached to a regular IDE port, and will work as-is. Typical
RAID controllers that do hardware-supported RAID store state and
config info on the attached drives, so they usually claim a few
sectors for that.
Cheers,
--fred (happily using SAN, Compaq RAID and InforTrend IDE RAID.)
6:43 a.m.
At 16:12 11/10/2004, Fred N. van Kempen wrote:
On Mon, 11 Oct 2004, Jochen Kunz wrote:
In my experience, running servers purely as a hobby, I've found the version
of RAID1 as presented by cheap ATA controllers on FreeBSD more than
adequate, a considerable speed up than a single drive, and definitely
better than not having a raid, when a drive goes down!!
I've used various cards (mostly SiL 0680 chipset) on FreeBSD without
problem. At least on the 0680, they do write something to the disc, as
taking the drives out of one machine and putting them on a different card
in a different machine caused them to be spotted as a RAID pair before the
OS had even had a chance to boot. Drives can be removed, and they do work
on their own however too, so I don't know what gets stored where?
You can mirror on FreeBSD using either vimum, which is pure software raid
and will work across any drives no matter what types or controllers they
are on (even a mix) or for most ATA IDE RAID cards, the ata driver has
built in support (`man atacontrol`) which I presume negotiates with the
card bios and sorts out who does what.
Oh, as far as the SiL0680 specifically is concerned, from personal
experience FreeBSD 4.10 works fine... 5.2 works, but 5.2.1 panics on boot
(even booting the install). Later snapshots are OK again though, but for
the moment 4.10 is still recommended for production servers, at least until
5.3 is out, which is apparently only a couple of weeks off. 5.3 apparently
offers some new facilities (geom_vinum and gmirror) but I've not used them,
or anything later than 5.2 yet, just seen them discussed while sorting out
beta bugs on the freebsd-current list.
Rob.
It depends on the load that the server already
has and how much overhead
software RAID1 causes. Typically RAID1 doesn't cost that much CPU. To
the past - present comparision: CPUs got a _lot_ more faster then disk
dirves in the past 20 years. See the thoughts behind the BSD LFS.
I have never
trusted OS-level disk redundancy schemes, and never
will. Promise controllers have strange ways of doing things, and
most certainly do require OS-level software assistance. Disks
attached to a Promise RAID1 controller can be taken off the Promise,
and attached to a regular IDE port, and will work as-is. Typical
RAID controllers that do hardware-supported RAID store state and
config info on the attached drives, so they usually claim a few
sectors for that. 
8:03 a.m.
I'm a little puzzled towards this hardware vs. software RAID,
and worrying about computrons (aka CPU speed).
For all the .*n[i,u]x's out there, the software RAIDs are
pretty damn reliable. If you have reliability problems I'd
dare say it's elsewhere. Hardware gets you more performance,
but you really have to need it.
Second, CPUs are just stupid silicon office products, they
are SUPPOSED to work hard. Who cares if would like coffee
breaks? I think most people also grossly overspec CPU, because
(1) it sounds cool and (2) they don't really know what's needed
(caveat, it's so cheap to overspec it's a perfectly valid
approach, but no sense losing sleep over it).
I build and run servers for a living (not exclusively) and I can
tell you that even a crappy 100MHz P1 does a LOT of work with
just decent hardware and enough memory. A gigacycle CPU with
512M, two EIDE channels, a real operating system, does REAL work!
Mailman is slow because it's bloated, but a lot of software
today is like sausage, I'll eat it well-cooked but refuse to
look inside.
You might as well get your money's worth from these cheap
capitalist products, and don't worry about the needs of
marketing. Big disks and more memory, you can hardly go wrong
(or cheaper).
1:19 p.m.
I'm a little puzzled towards this hardware vs.
software RAID,
and worrying about computrons (aka CPU speed).
Everyone who is talking about
"software raid is ok because I've used it
without trouble"... that's a pretty insufficient argument. Kinda like
someone saying "Oh, you can format double density floppies to single density
and it works great because I did it". B.S. - a little education and you'd
see why it's precarious. I've seen people who argue about that because they
have "proof it works fine". Just wait till a few months go by and their data
doesn't appear anymore :) Not that software raid doesn't work, it does, and
quite well. But all I'm saying is a better argument might sway me. That one
doesn't.
Look at what has to happen with software raid. The software has to set up
twice as many DMA transfers, handle twice as many interrupts, block waiting
on I/O twice as many times, and send double the data across the bus. I'm
aghast that many of the classiccmp'ers here aren't revolted by that just on
principle. The same mentality got us MS/Windows "Oh, don't worry about the
cpu cycles, it's just trivial to add this little pop-up box...". Trivial
adds up.
Jay "vying for freds 'grumpy old' title" West
1:50 p.m.
On Mon, 11 Oct 2004, Jay West wrote:
Everyone who is talking about "software raid is
ok because I've used it
without trouble"... that's a pretty insufficient argument. Kinda like someone
saying "Oh, you can format double density floppies to single density and it
works great because I did it". B.S. - a little education and you'd see why
it's precarious. I've seen people who argue about that because they have
"proof it works fine". Just wait till a few months go by and their data
doesn't appear anymore :) Not that software raid doesn't work, it does, and
quite well. But all I'm saying is a better argument might sway me. That one
doesn't.
Well it's your box, and your decision, but I don't see why
RAID drivers are any more suspect than another software driver.
I don't however understand why criticizing it on the number
of likely overlapping I/O transfers is valid. There's far more
complex software in there already.
In fact I think that RAID is a waste of time and money and
complexity; you can get a lot of inexpensive, simple and reliable
performance by using one EIDE per drive (with CDROM a slave on
any) and "big" drive(s) chosen to be right at the beginnign of
the steep-price knee. Split archives and lists onto drives/mount
points, your oldest drive as OS, one of (two?) new, big drives
rsync -ua one to the other for "mirror", etc. Cheap, simple,
fast, easy, changable later, etc.
If you've got a 100Mbit ether, it's unlikely it will exceed
the disk or OS speed.
I'll let others have the last word on this.
2:16 p.m.
>> Tom Jennings Wrote:
>>
>> In fact I think that RAID is a waste of time and money and
>> complexity; you can get a lot of inexpensive, simple and
>> reliable performance by using one EIDE per drive (with
>> CDROM a slave on
>> any) and "big" drive(s) chosen to be right at the beginnign
>> of the steep-price knee. Split archives and lists onto
>> drives/mount points, your oldest drive as OS, one of (two?)
>> new, big drives rsync -ua one to the other for "mirror",
>> etc. Cheap, simple, fast, easy, changable later, etc.
>>
For on-line archive type applications, I would agree that "rsync" type
solutions can be quite effective. You can even use more expensive, smaller,
faster drives as the primary and use really big cheap drives for the online
copies.
HOWEVER, I would NOT use this type of solution for any transitory type data,
or any data which required the secondary to be a 100% consistant copy of the
primary.
The failure/performance points is RAID, have been covered, and I choose
between them based on the exact application [with software raid being the
more common choice]
10:09 p.m.
In fact I think that RAID is a waste of time and money
and
complexity;
Depends what you can lay your hands on. Companies are throwing out
machines of only a couple of years old with some pretty high spec
hardware in, so the money side isn't always an issue. Complexity-wise,
the controller BIOS setup utilities usually take care of the complex
stuff and present it in an easy-to-understand way.
you can get a lot of inexpensive, simple and
reliable
performance by using one EIDE per drive
Where's IDE these days relative to SCSI? For a machine that's processing
a lot of mail traffic (and hence a lot of disk I/O) SCSI controllers
(RAID or otherwise) were always better than IDE - plus you get the
higher reliability, more flexible bus options etc.
(I'd expect for flat-out transfers of large files, there's not a lot in
it)
If you've got a 100Mbit ether, it's unlikely
it will exceed
the disk or OS speed.
Not so convinced about that - remember that's bits, not bytes; ethernet
isn't *that* fast (relative to other things). Then presumably if you're
shunting a lot of small files around (as with a machine hosting a
mailing list) then it'll be 1 or more packets per message with the
resultant packet overhead. It all adds up pretty quick.
As for mirroring to a seperate machine (if that's what you were
intending) then disk performance should easily outstrip network
bandwidth (and could probably upset the underlying mail software whilst
mirroring was taking place) - I'd go for a seperate ethernet link
between machines just for mirroring purposes in that case. (Our broken
1U machine at Bletchley actually has three 100MBit interfaces on the
motherboard, presumably for this sort of reason)
Only Jay knows how much on-line storage he needs, the nature of the data
hosted on the server, and how much network traffic the server needs to
move though.
cheers
Jules
12 Oct
12 Oct
7:31 a.m.
On Tue, 12 Oct 2004, Jules Richardson wrote:
(I think you misread this -- without special preparation,
you'll never get > 25 - 50 Mbits/sec through it; that's 5
megabytes/sec peak.
But even this is a false measure; it's not realistic or
practical to size a system by the very tip of peak performance
requirements. More empirical tests are appropriate: how long does
it ACTUALLY take to explode mail? What portion of that is spent
on-disk? (My guess, from actually working with giant mailers, is
90% of the time is spent on the net tied up in TCP-open waits!)
Where's IDE these days relative to SCSI?
Very, very good. Except for really demanding jobs, which mail
and ftp archive is not, SCSI is a waste of money.
SCSI controllers
(RAID or otherwise) were always better than IDE - plus you get the
higher reliability, more flexible bus options etc.
Times change! Drives are far cheaper; >> reliability may still
exist in SCSI, but it's not been borne out in my experience.
If you've
got a 100Mbit ether, it's unlikely it will exceed
the disk or OS speed.
Not so convinced about that - remember that's bits, not bytes; ethernet
isn't *that* fast (relative to other things). As for mirroring to a seperate machine (if that's
what you were
intending) then disk performance should easily outstrip network
bandwidth
Even a fair EIDE system on a modern machine will keep 100megabit
ether 100% soaked 100% of the time if you're just copying
data over a wire. But rarely is that how files are moved,
and certainly not over the open internet!
(and could probably upset the underlying mail software
whilst
mirroring was taking place) -
I simply don't believe this. This is what OS's *do*. Or maybe
I misread this. Temp files disappear during backups all the
time, it's rarely a problem (occasional "file disappeared!" in
the log).
I'd go for a seperate ethernet link
between machines just for mirroring purposes in that case.
Utter waste of time. It could improve stopwatch times to complete
a mirror; but who cares unless the time is significant? This is
what computers *are for*, to do drudgery. If you've got the
ethernet on board, by all means, but otherwise it's a waste
without an actual need.
Unless you have a tightly-specified problem and constraints,
it's best to solve problems when the occur.
8:37 a.m.
On Tue, 2004-10-12 at 12:31 -0700, Tom Jennings wrote:
yes the drives are cheaper; but I was asking about the performance more
than anything - I pretty much lost touch with IDE 5 years ago apart from
a handful of machines, so I don't know where it's at in terms of
performance under load (in a real scenario, forget marketing hype! :-)
Reliability's a tricky one. Historically I've had both IDE and SCSI
disks go bad in desktop environments (i.e. lots of power cycling and
less of a controlled dust-free environment), but I've only ever seen IDE
disks completely blow up in the servers I've known that happened to have
IDE disks rather than SCSI. Maybe that was just luck of the draw,
though.
(I think you misread this -- without special preparation,
you'll never get > 25 - 50 Mbits/sec through it; that's 5
megabytes/sec peak.
My point was only that if you rsync to a disk on a different machine
over ethernet (as I thought you were suggesting, but I could well be
wrong!) then you do risk saturating the link at the time of the rsync,
which I'd assume *could* lead to mail message transfer problems.
On Tue, 12 Oct 2004, Jules Richardson wrote:
mail can be extremely disk-intensive (depending on message volume)
surely?
Where's IDE these days relative to SCSI?
Very, very good. Except for really demanding jobs, which mail
and ftp archive is not, SCSI is a waste of money. SCSI
controllers
(RAID or otherwise) were always better than IDE - plus you get the
higher reliability, more flexible bus options etc.
Times change! Drives are far cheaper; >> reliability may still
exist in SCSI, but it's not been borne out in my experience. If you've got a 100Mbit ether, it's unlikely
it will exceed
the disk or OS speed.
Not so convinced about that - remember that's bits, not bytes; ethernet
isn't *that* fast (relative to other things). Even a fair EIDE system on a modern machine will keep
100megabit
ether 100% soaked 100% of the time if you're just copying
data over a wire. But rarely is that how files are moved,
and certainly not over the open internet!
I probably did misunderstand your rsync comment then :-)
Unless you have a tightly-specified problem and
constraints,
it's best to solve problems when the occur.
Some problems, sure - but surely things like disk failure are an
anticipated problem that's guaranteed to occur at some point, and if you
*want* a server with near-perfect uptime then that needs planning for?
Again, it depends on the requirements, and in this case only Jay can
decide those...
cheers
Jules
9:08 a.m.
On Tue, 12 Oct 2004, Jules Richardson wrote:
re: IDE
Oh, got it now, I agree 100% -- a big 'data copy' (rsync,
whatever) will certainly bog the line. But it won't cause
mail transfer problems, but mail transfer delays, lower overall
throughput. TCP/IP is quite robust, and SMTP is reeeeeeeaallly
well tested!
Where is it required that a computer have 100% free unfettered
access for each and every process for each and every second? If
backups take 30 minutes of the day, I say BFD (YMMV). If it's
taking 4 hours there may be a problem, but really, CPUs are not
sentient, they don't care if they work hard 100% of the time
(barring heat removal :-)
yes the drives are cheaper; but I was asking about the
performance more
than anything - I pretty much lost touch with IDE 5 years ago apart from
a handful of machines, so I don't know where it's at in terms of
performance under load (in a real scenario, forget marketing hype! :-)
Good. I don't look much at performance specs, but performance
in place. On the whole a good EIDE layout (eg. one drive per
controller) is as good as anything.
Reliability's a tricky one. Historically I've
had both IDE and SCSI
disks go bad in desktop environments (i.e. lots of power cycling and
less of a controlled dust-free environment), but I've only ever seen IDE
disks completely blow up in the servers I've known that happened to have
IDE disks rather than SCSI. Maybe that was just luck of the draw,
though.
I'm guessing, but it might be a version of 'derate for
reliability'; most SCSI drives don't approach the bytes/spindle
that IDE drives do. Maybe it's simply NEW 20gb drives are more
reliable than NEW 160gb drives for various mfgr reasons.
you'll
never get > 25 - 50 Mbits/sec through it; that's 5
megabytes/sec peak.
My point was only that if you rsync to a disk on a different machine
over ethernet (as I thought you were suggesting, but I could well be
wrong!) then you do risk saturating the link at the time of the rsync,
which I'd assume *could* lead to mail message transfer problems. Some problems, sure - but surely things like disk
failure are an
anticipated problem that's guaranteed to occur at some point, and if you
*want* a server with near-perfect uptime then that needs planning for?
Oh I want it all too, I'm just not willing to pay for it :-)
Seriously, between an average well-run PC box and a high-end
RAID server, we're not talking orders of magnitude improvement.
1:40 p.m.
Oh, got it now, I agree 100% -- a big 'data
copy' (rsync, whatever)
will certainly bog the line.
If you do it all at once, at least.
I have "live" mirroring of my disks - all disk writes are mirrored over
the net in real time to images on a big backup drive on another
machine. (Or near-real-time, if the writer is producing data faster
than the mirroring can deal with it - the software goes to some lengths
to handle that case well.) It doesn't cause load problems in normal
use because the network load it imposes is spread out throughout the
day, becoming visible only when doing a data transfer over the net to
disk from a source that can run the network at least half-wide-open.
(Yes, I know it's not a comprehensive backup solution. It doesn't deal
with "oops, I didn't mean to delete that file", or "now what was in
this file last May?", but it's not intended to; it's designed to defend
against "this disk spindle just went casters-up", and it does that very
well. I've had two disk deaths since I started doing it, and it did
its job perfectly each time.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:08 p.m.
>> der Mouse Wrote:
>>
>> I have "live" mirroring of my disks - all disk writes are
>> mirrored over the net in real time to images on a big
>> backup drive on another machine. (Or near-real-time, if
>> the writer is producing data faster than the mirroring can
>> deal with it - the software goes to some lengths to handle
>> that case well.) It doesn't cause load problems in normal
>> use because the network load it imposes is spread out
>> throughout the day, becoming visible only when doing a data
>> transfer over the net to disk from a source that can run
>> the network at least half-wide-open.
Just out of curiousity... Is this done on a file by file basis [i.e. if the
file is changed, the file is copied...], or some other more granular means?
I ask because most of my data operations involve many relatively small
writes to varying sections of very large files.
Thanks for the info...
2:08 p.m.
I have
"live" mirroring of my disks - all disk writes are mirrored
over the net in real time to [backup images elsewhere].
Just out of curiousity...
Is this done on a file by file basis [i.e.
if the file is changed, the file is copied...], or some other more
granular means? I ask because most of my data operations involve many
relatively
small writes to varying sections of very large files.
If it involves writing to few disk blocks, it would mean little data
copied over the net under my scheme.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:23 p.m.
> > Where's IDE these days relative to SCSI?
>
> Very, very good. Except for really demanding jobs, which mail
> and ftp archive is not, SCSI is a waste of money.
I haven't checked
recently... but last time I did SCSI drives had a lot more
bandwidth than IDE drives. Same old problem.
mail can be extremely disk-intensive (depending on
message volume)
surely?
Mail (at least large queues) is very disk intensive.
Jay
8:40 a.m.
New subject: VAXBI SCSI?
I may (and I emphisize _may_) be getting a VAX 6000/610 for the cost of
shipping it. Is there a SCSI adapter available for this machine? I'd
like to avoid running RA series drives if I can avoid it.
tnx!
g.
--
"I'm not crazy, I'm plausibly off-nominal!"
Proud owner of 80-0007
http://www.f15sim.com - The only one of its kind.
8:40 a.m.
New subject: VAXBI SCSI?
On Tue, Oct 12, 2004 at 01:40:03PM -0700, Gene Buckle wrote:
I may (and I emphisize _may_) be getting a VAX
6000/610 for the cost of
shipping it. Is there a SCSI adapter available for this machine? I'd
like to avoid running RA series drives if I can avoid it.
There were VAXBI SCSI cards available at one time, but I have never
used one, and I can't recall the vendor's name. My recollection was
that MSRP was $10K for either MSCP _or_ TMSCP, $20K for the firmware
that did both.
I'd love one, but I think you'd just about have to find a machine that
already had one inside.
I _think_ they were never popular because people typically had a cluster
and HSC storage boxes or locally attached disk on a KDB50 (my 8200 came
(to my employer) used in 1989 for about $12K w/KDB50 and we threw on an
old RA81).
Last thing I did to it was try to get either a DEBNI or DEBNT working.
No dice. It was enough months ago that I forget what was up.
-ethan
--
Ethan Dicks, A-130-S Current South Pole Weather at 12-Oct-2004 20:30 Z
South Pole Station
PSC 468 Box 400 Temp -45 F (-42.8 C) Windchill -81.2 F (-62.9 C)
APO AP 96598 Wind 17.6 kts Grid 027 Barometer 680.2 mb (10619. ft)
Ethan.Dicks(a)amanda.spole.gov http://penguincentral.com/penguincentral.html
9:12 a.m.
New subject: VAXBI SCSI?
There were VAXBI SCSI cards available at one time, but
I have never
used one, and I can't recall the vendor's name. My recollection was
that MSRP was $10K for either MSCP _or_ TMSCP, $20K for the firmware
that did both.
I've since been told it has DSSI and some kind of SCSI adapter, so it
looks like I'll be able to use SCSI drives with it. It only has 384MB of
RAM so if I get it I'll want to bump that up if I can get it cheap. Will
VMS 5.2 work on it? That's the newest version I have (on TK50 tapes I
think).
I _think_ they were never popular because people
typically had a cluster
and HSC storage boxes or locally attached disk on a KDB50 (my 8200 came
(to my employer) used in 1989 for about $12K w/KDB50 and we threw on an
old RA81).
The 8250 I had I bought from Mannesman-Tally here in Kent. $500 and I had
to de-install it myself. It was a fun machine. I had no business putting
it in the upstairs of my house though. Especially with four RA81s.
Last thing I did to it was try to get either a DEBNI
or DEBNT working.
No dice. It was enough months ago that I forget what was up.
This machine does have a DEBNA(?) ethernet card in it, so if I get it, at
least I can put it on the net for others to play with. :)
g.
--
"I'm not crazy, I'm plausibly off-nominal!"
Proud owner of 80-0007
http://www.f15sim.com - The only one of its kind.
9:46 a.m.
New subject: VAXBI SCSI?
On Tue, Oct 12, 2004 at 02:12:41PM -0700, Gene Buckle wrote:
I've since been told it has DSSI and some kind of
SCSI adapter, so it
looks like I'll be able to use SCSI drives with it.
Handy. I have zero experience with DSSI. I did own an R400X(?)
DSSI cab, but I gave it to a fellow list member in town (2 miles
from my house) because I had no controllers that could
talk to
it (it was mostly full of multi-gig 5.25" drives - RF74s?)
I've heard of DSSI<->SCSI adapters. They sound like a good
solution for systems that are DSSI-only.
It only has 384MB of RAM so if I get it I'll want
to bump that up if
I can get it cheap.
*cough* OK... if you say so... I'm happy to have 16MB in my 8200, and
I'd be happier if it weren't on 5 cards! (2MB and 4MB) Unless you
plan to run some monster stuff or a *lot* of simultaneous users, a
VAX (as opposed to an Alpha) VMS system should be happy with a lot
less than what you already have.
We used to run 20-30 simultaneous users (out of 60-70 at the company)
on an 11/750 w/8MB (VMS 5.5-2), and it didn't swap. Pre-6.x versions
of VMS, especially on VAXen, work fine with "small" amounts of memory.
Will VMS 5.2 work on it? That's the newest
version I have (on TK50
tapes I think).
Not sure what the oldest version of VMS you can use is, but if I had
to guess, I'd say there's a chance that you need a slightly newer
version. Not guaranteed, but it's possible. We never had hardware
that new, so this is a fuzzy area for me. My experience is solidly
in the 11/750 and 11/730 era, with some 8200 and 8530 time. I then
didn't do much until Alphas reigned. I kinda missed the 6xxx era.
Similarly, I have lots of 4.0 -> 5.5-2 experience, some 6.x, and a bit
of 7.2 experience, due to where I've worked and what's running in my
basement.
The 8250 I had I bought from Mannesman-Tally here in
Kent. $500 and I had
to de-install it myself. It was a fun machine. I had no business putting
it in the upstairs of my house though. Especially with four RA81s.
Ooph! My 8200/8300 is in the basement, along with one RA81, and a TU80
(which I'd be using if I could get my DWBUA working).
This machine does have a DEBNA(?) ethernet card in it,
so if I get it, at
least I can put it on the net for others to play with. :)
You might want to consider a newer version of VMS, then. I don't have any
experience with TCP/IP on pre-OpenVMS 7.x, but I know VMS 5.x didn't come
with anything except DECnet. There were several options back in the day for
VMS 5.x machines, but at work then, we never went with any of them (we made
SNA and Bisync hardware/software ourselves, so we just used our own products
in a point-to-point HASP network to move stuff around on the machines that
didn't happen to have DDCMP serial cards and DECnet).
-ethan
--
Ethan Dicks, A-130-S Current South Pole Weather at 12-Oct-2004 21:30 Z
South Pole Station
PSC 468 Box 400 Temp -44.6 F (-42.6 C) Windchill -78.3 F (-61.3 C)
APO AP 96598 Wind 14.8 kts Grid 031 Barometer 679.4 mb (10647. ft)
Ethan.Dicks(a)amanda.spole.gov http://penguincentral.com/penguincentral.html
10:21 a.m.
New subject: VAXBI SCSI?
It only has
384MB of RAM so if I get it I'll want to bump that up if
I can get it cheap.
*cough* OK... if you say so... I'm happy to have 16MB in my 8200, and
I'd be happier if it weren't on 5 cards! (2MB and 4MB) Unless you
plan to run some monster stuff or a *lot* of simultaneous users, a
VAX (as opposed to an Alpha) VMS system should be happy with a lot
less than what you already have.
The 8250 I had
I bought from Mannesman-Tally here in Kent. $500 and I had
to de-install it myself. It was a fun machine. I had no business putting
it in the upstairs of my house though. Especially with four RA81s.
Ooph! My 8200/8300 is in the basement, along with one RA81, and a TU80
(which I'd be using if I could get my DWBUA working).
You might want to consider a newer version of VMS,
then. I don't have any
experience with TCP/IP on pre-OpenVMS 7.x, but I know VMS 5.x didn't come
with anything except DECnet. There were several options back in the day for
VMS 5.x machines, but at work then, we never went with any of them (we made
SNA and Bisync hardware/software ourselves, so we just used our own products
in a point-to-point HASP network to move stuff around on the machines that
didn't happen to have DDCMP serial cards and DECnet).
It's been too long since I've looked at those tapes. The version I have
is not "5.2", but "5-5.2". Regardless, I suppose I'm going to
need a new
version of OpenVMS for it. Will the old PAKs I have for v5 work with
newer versions?
g.
--
"I'm not crazy, I'm plausibly off-nominal!"
Proud owner of 80-0007
http://www.f15sim.com - The only one of its kind.
14 Oct
14 Oct
4:52 a.m.
New subject: Rescue a 6000!
The shipping charges from Conneticut were too rich for my blood so I'm
hoping one of you will be able to save this machine.
It's a VAX 6000/610 with dual CPUs. It has 384MB of RAM and 24GB of drive
space via 12 drives. It also comes with VMS documentation. I don't know
how much. Email Bob Donovan at bdonovan -at- ssww.com if you're
interested.
Thanks!
g.
--
"I'm not crazy, I'm plausibly off-nominal!"
Proud owner of 80-0007
http://www.f15sim.com - The only one of its kind.
4:52 a.m.
New subject: Rescue a 6000!
----- Original Message -----
From: "Gene Buckle" <geneb(a)deltasoft.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk(a)classiccmp.org>
Sent: Thursday, October 14, 2004 6:52 PM
Subject: Rescue a 6000!
It's a VAX 6000/610 with dual CPUs.
Oh sh.... I hoped it was a Philips 6000...
Nico
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.774 / Virus Database: 521 - Release Date: 07-10-2004
12 Oct
12 Oct
9:35 a.m.
New subject: VAXBI SCSI?
On Tue, 12 Oct 2004, Gene Buckle wrote:
I may (and I emphisize _may_) be getting a VAX
6000/610 for the cost of
shipping it. Is there a SCSI adapter available for this machine? I'd
like to avoid running RA series drives if I can avoid it.
Other options:
If it has CI you can use a HSJ CI -> SCSI controller
If it has DSSI you can use HSD DSSI -> SCSI controller
I have observed these for reasonable prices on Ebay.
The CI solution you would need a star coupler as well, if you don't have
one, which also can be had for small $ but are a pain to ship as they are
mostly air in a heavy metal cabinet.
9:50 a.m.
New subject: VAXBI SCSI?
I may (and I
emphisize _may_) be getting a VAX 6000/610 for the cost of
shipping it. Is there a SCSI adapter available for this machine? I'd
like to avoid running RA series drives if I can avoid it.
Other options:
If it has CI you can use a HSJ CI -> SCSI controller
If it has DSSI you can use HSD DSSI -> SCSI controller
I have observed these for reasonable prices on Ebay.
The CI solution you would need a star coupler as well, if you don't have
one, which also can be had for small $ but are a pain to ship as they are
mostly air in a heavy metal cabinet.
10 a.m.
New subject: VAXBI SCSI?
Thanks for the info. It turns out that it has the
DSSI ->
SCSI option. I
That probably means an XMI DSSI adapter (KFMSA) and an HSD
controller (or controllers) that do the DSSI<->SCSI part.
don't know what kind of drives are in the second
cabinet though. I'm
wondering if it would be possible to add more cpu boards to
this beast...
You can have up to 6 cpus in there (that would be a
VAX 6000-660): the limitation (other than finding the
CPU boards) will be how many slots are free. That will
probably depend on which memory boards you have. 384MB
suggests 1x256MB + 1x128MB or 3x128MB. My recollection
is that this class of machine benefits from memory
interleave, so 2N memory boards of the same type is
generally better.
You can get up to 1GB in the machine, but to have
support for that you will need OpenVMS V6.0 or later.
Minimum OS support is V5.5 but you should be able to get
hobbyist licences and media from montagar.com easily
enough. (Or maybe someone here can supply the media
as an ISO or whatever). I'd suggest that you lean towards
OpenVMS V7.2 or V7.3 to start with - V5.5 is old enough
that help may be a little harder to come by (in particular,
remembering "gotchas" from that far back can be challenging!).
You mentioned a DEBNI (or DEBNA or DEBNT). I forget the
differences between all these boards (i.e. which were
the worst, which differ only in microcode and which
support a tape) but a DEMNA (XMI ethernet) would be
the ideal (at the expense of an XMI slot though).
Having said that, at 10Mbps, it probably makes little
difference. (Except the DEMNA was probably less buggy
than the others!)
There is much VAX 6000 family information on the
net. "VAX 6000" fed into http://vt100.net/manx/
should provide plenty of reading for a while.
One last point, you can (should you wish to for fun)
probably get older VAX 6000 series boards running
in that chassis. The procedure is described in
the various upgrade manuals (although you would
be going the other way!)
Antonio
--
---------------
Antonio Carlini arcarlini(a)iee.org
10:33 a.m.
New subject: VAXBI SCSI?
There is much VAX 6000 family information on the
net. "VAX 6000" fed into http://vt100.net/manx/
should provide plenty of reading for a while.
Thanks for the info Antonio. That website is amazing. :)
I hope I can get the machine - my problem is my breaking point is about
$150 for shipping and it's currently living in Conneticut. We'll see how
much of a deal they can get me and how bad they want it gone.
Damn, now I'm missing the orange wall I used to have. *sigh*
g.
--
"I'm not crazy, I'm plausibly off-nominal!"
Proud owner of 80-0007
http://www.f15sim.com - The only one of its kind.
10:23 a.m.
New subject: VAXBI SCSI?
On Tue, 12 Oct 2004 13:40:03 -0700 (PDT)
Gene Buckle <geneb(a)deltasoft.com> wrote:
I may (and I emphisize _may_) be getting a VAX
6000/610 for the cost
of shipping it. Is there a SCSI adapter available for this machine?
If it has
DSSI you can use a HSDxy SCSI-to-DSSI hardware RAID adapter to
convert cheap SCSI disks to a (bunch of) logical DSSI disks.
I'd like to avoid running RA series drives if I
can avoid it.
What is wrong with a RA9x? You can mount two of them in the bottom of
a
VAX6k.
There are also CI-to-SCSI HSC solutions...
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
13 Oct
13 Oct
2:05 a.m.
New subject: VAXBI SCSI?
I may (and I
emphisize _may_) be getting a VAX 6000/610 for the cost
of shipping it. Is there a SCSI adapter available for this machine?
If it has
DSSI you can use a HSDxy SCSI-to-DSSI hardware RAID adapter to
convert cheap SCSI disks to a (bunch of) logical DSSI disks.
I'd like to avoid running RA series drives if
I can avoid it.
What is wrong with a RA9x? You can mount two of them in the bottom
of a
VAX6k.
11 Oct
11 Oct
2:02 p.m.
>>
>> Look at what has to happen with software raid. The software
>> has to set up twice as many DMA transfers, handle twice as
>> many interrupts, block waiting on I/O twice as many times,
>> and send double the data across the bus. I'm aghast that
>> many of the classiccmp'ers here aren't revolted by that
>> just on principle. The same mentality got us MS/Windows
>> "Oh, don't worry about the cpu cycles, it's just trivial to
>> add this little pop-up box...". Trivial adds up.
>>
Trivial does add up, but so do other things. The "correct" answer depends on
properly weighing each of the factors. For each application the weights are
going to be different (sometimes radically).
An equally valid argument is that hardware raid increates the number of
transistors involved. This will increase the chance of hardware failure.
While both of the above statements are 100% true, there is no real
meaningful conclusion to draw from them on the entire problem at hand.
11:38 p.m.
On 12/10/2004, at 11:19 AM, Jay West wrote:
Everyone who is talking about "software raid is
ok because I've used
it without trouble"... that's a pretty insufficient argument. Kinda
like someone saying "Oh, you can format double density floppies to
single density and it works great because I did it". B.S. - a little
education and you'd see why it's precarious. I've seen people who
argue about that because they have "proof it works fine". Just wait
till a few months go by and their data doesn't appear anymore :) Not
that software raid doesn't work, it does, and quite well. But all I'm
saying is a better argument might sway me. That one doesn't.
Well this is only one data point :-) but I've been using software RAID
on production servers for at least 15 years (and maybe a little longer)
and I have _never_ lost data due to software failures.
Of course, this software raid is called VMS Volume Shadowing.....
In theory, software RAID1 could be better than hardware RAID as the
operating system has a better knowledge of what's happening (and about
to happen) whereas the hardware just "duplicates blocks". I'd also want
to be absolutely sure that in all circumstances that should the
hardware controller fail that I still get data off (and on) without
needing another RAID controller.
Huw Davies | e-mail: Huw.Davies(a)kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
6:50 a.m.
Curious.
This is an Email service of about
400K/day, or 6 years/Gig. A relatively puny
load for such a server. Why such a need then?
I'm confused.... are you referring to the cpu, or disk space?
First, mailman does take a decent chunk of cpu power, mostly due to the
process of automatically maintaining the archives. Any mailing process is
also rather disk intensive, as sendmail can be set to queue all mail first
before delivery. One doesn't have to set sendmail up this way, but doing so
allows other optimizations to be done such as grouping mails to the same
target domain, etc.
Then remember that the classiccmp server does a lot more than just handle
the mailing list. There's quite a large amount of mirrored data (bitsavers
for example), and some 25 or so classic computer related websites, many of
which are non-trivial. MySQL is also present, as is PHP.
Jay
4:26 p.m.
New subject: HP paper tape punch
http://cgi.govliquidation.com/auction/view?id=462174&convertTo=USD
Also there are now 17 HP1000's
Peter Wallace
11 Oct
11 Oct
12:58 p.m.
New subject: HP paper tape punch
Pretty sweet!
That would go well on a 2114/2115/2116.
Also there are now 17 HP1000's
I'm
officially out of collecting more MX/E's, I have all I want it prinstine
condition. But I am looking at a few of the auctions for the MX/M's. I'm
definitely going to get a pallet or two, just not sure which lot of M's to
bid on.
Jay West
7375
days inactive
7380
days old
43 comments
19 participants
participants (19)
-
a.carlini＠ntlworld.com -
allain＠panix.com -
classiccmp.org＠irrelevant.fsnet.co.uk -
dickset＠amanda.spole.gov -
doc＠mdrconsult.com -
dvcorbin＠optonline.net -
geneb＠deltasoft.com -
huw.davies＠kerberos.davies.net.au -
jkunz＠unixag-kl.fh-kl.de -
julesrichardsonuk＠yahoo.co.uk -
jwest＠classiccmp.org -
mouse＠Rodents.Montreal.QC.CA -
nico＠farumdata.dk -
pat＠computer-refuge.org -
pcw＠mesanet.com -
thompson＠new.rr.com -
tomj＠wps.com -
waltje＠pdp11.nl -
zmerch＠30below.com