[6170] in RedHat Linux List
Re: SMP systems, XING streaming video
daemon@ATHENA.MIT.EDU (Stephen Zedalis)
Tue Nov 26 06:54:24 1996
Date: Tue, 26 Nov 1996 06:52:58 -0500 (EST)
From: Stephen Zedalis <tintype@zedalis.com>
To: Joe Block <jpb@miamisci.org>
cc: redhat-list@redhat.com
In-Reply-To: <v03007804aec011f63a71@[192.168.1.69]>
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
On Mon, 25 Nov 1996, Joe Block wrote:
> We have a prospective contract at work that will require us to set up a
> dual Pentium Pro system. We're at the hardware spec stage, and I'd like to
> know how those of you using dual processor motherboards feel about them.
> We're currently thinking of going with an Asus or a Venus, but if anyone
> has any horror stories, that isn't etched in stone.
> The machine will be used to serve XING streaming video, and any suggestions
> or warnings about that will be appreciated as well.
I wouldn't put all my eggs in one basket on this. Ie. Make sure that you
have enough horsepower with one CPU. The jury is still out on SMP.
First, even though it has been included in the stable kernels, SMP support
is still in an alpha experimental stage. In fact, it definitely does not
do well in some environments. In its current implementation, only one
CPU (cpu 0) handles all kernel code and all hardware interrupts. So, if
you have an i/o intensive server the second CPU will not improve
performance much. Better to get one really fast CPU than 2 slower ones.
In fact, in testing with our mail and news servers, there are other
problems that crop up. You can start missing timer interrupts and the
system clock slows down under heavy load. Max error rates for us was as
much as 40 min/day. This is not easily fixable since the error is load
dependent and thus varies throughout the day. If you had something that
was computationally expensive and not i/o intensive, and the code was
written for several user mode processes or threads, then the second CPU
will help. There will eventually be fixes I'm sure to the timer problems
etc. But, it will not likely improve i/o performance. I don't think it
is the fault of the developers, but limitations with the hardware and
current OS architecture.
Your application does not appear to be CPU dependent, and primarily i/o
bound. I would invest heavily in things to improve the i/o. Ie. Ultra
Fast/Wide SCSI, 100 Mbps full-duplex ethernet, T-3 or multiple T-1
bandwidth. Lots of RAM and RAM cache. And don't try to do everything
with one server. Use one server to process video from each camera, do
video compression etc., and use another as the main server, doing nothing
but feeding streams. Ie. no mail, news, credit card processing, etc.
Expensive, I know, but that is what I think you need to do this right.
If you feel the need for speed on the CPU, consider the more modern RISC
processors.
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
________________________________________________________________________
http://www.redhat.com/RedHat-FAQ http://www.redhat.com/RedHat-Errata
http://www.redhat.com/RedHat-Tips http://www.redhat.com/mailing-lists
------------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe redhat-list-request@redhat.com < /dev/null
