Re: NT mirroring question
Daniel L. Schwartz(expresso[at]snip.net)
Wed, 06 Oct 1999 15:03:25 -0400
WinMac Digest #432 - Wednesday, October 6, 1999
Re: [WinMac] Re: dual processors on NT Servers
by "John C. Welch" <jwelch@aer.com>
Re: Re: dual processors on NT Servers
by "Daniel L. Schwartz" <expresso@snip.net>
Re: [WinMac] Re: Re: dual processors on NT Servers
by "Welch, John C." <jwelch@aer.com>
Re: [WinMac] ETHERNET SPEED
by "Curtis Wilcox" <cwcx@mail.rochester.edu>
NT Stability, was Re: dual processors on NT Servers
by "John Hanks" <jbh@biology.usu.edu>
NT mirroring question
by "Welch, John C." <jwelch@aer.com>
Re: NT mirroring question
by "Daniel L. Schwartz" <expresso@snip.net>
Subject: Re: [WinMac] Re: dual processors on NT Servers
From: "John C. Welch" <jwelch@aer.com>
Date: Tue, 05 Oct 1999 23:43:35 -0400
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Comments inline.
NOTE: Despite what it may look like, this is a Microsoft flame, and not a
Dan Flame. Having actually met Dan at MacWorld, I can attest that we both
enjoy high-spirited arguments, which are NOT the same as personal attacks.
> Yes, NT is, and always has been. a fully symmetrical multiprocessor
> operating system. Unlike MacOS & NetWare, which are pretty much
> asymmetrical, NT's thread scheduler will gladly dispatch tasks to the
> available CPU's by which one has the lightest load.
>
> BTW, along these same lines, this was one of the reasons that NT blew
> linux out of the water in the controversial NT-linux shootout in early
> summer: The testbed was a 4 CPU Dell box with 4GB of RAM. When the second
> round of tests were performed - With RedHat & Microsoft engineers each
> optimizing their respective systems - it was discovered that linux didn't
> have a multithreaded TCP/IP stack!
>
unfortunately NT's thread scheduler is a joke, so one thread...i.e. a 2 page
word document, can eat 99% of the CPU, which doesn't happen on Unix. NT's
scaling also goes in the terlet past 4 processors, whereas Unix and AS/400s
scale happily to many more processors, support *real* clustering, and have
uptimes of up to 5 years on average for the 400s. But hey, NT beat Linux, so
that's all that matters.
> ------
>
> Just imagine the (hypothetical) men's room conversation at the lab:
>
> "Let's see, we don't have a multithreaded IP stack. Let's throw this into
> the kernel and recompile..."
>
> "What about regression testing for quality & compatibility before putting
> this out there?"
>
> "Ha Ha! This is Linux - As long as it works on this machine, fine.
> Everyone else'll have to edit the kernel to suit their own "needs:" This is
> "open source" at it's finest!"
As opposed to the NT convo: "Gee, we can fix the umpteen bazillion security
and reliability bugs...NAH...instead, let's tie everything into a pseudo -
hierarchal(sp?) directory that is buzzword compliant, but won't be really
functional for at LEAST 3 service pack..." MS operating systems at THEIR
finest.
>
> ------
>
> Going back to the original NT question, applications don't need to know
> anything about the hardware: They are "cradled" by the HAL (Hardware
> Abstraction Layer) of NT, and NT will "break up" the application into its'
> DLL (Dynamic Link Library) threads and distribute the threads amongst the
> CPU's.
If the HAL is so good at *cradling* apps, how come it couldn't abstract the
processor, and why so much assembly optimizations for Intel, and not MIPS,
Alpha, or PowerPC?
>
> [Note that there *is* an exception: old 16 bit apps, which are run in
> NTVDM (NT Virtual DOS Machine, an x86 emulator): Normally, NTVDM's run in
> their own separate processes; but there are a few cases where the
> "DefaultSeparateNTVDM" key has to be set to "No" in order for multiple
> legacy apps to communicate between each other. In this case, NTVDM.EXE will
> also run on only a single CPU. The obvious answer is to get rid of as much
> of the 16 bit crap as possible: On a well-oiled NT Server this shouldn't be
> too difficult]
Why do I have to start gutting NT to make it well oiled. By the time that's
done, I'LL need to be well oiled. Rebel Beer anyone? I never do this with
Solaris...gee, good thing NT's SO much easier than Unix.
>
> A good source of NT reference material is Sean Daily's "Optimizing Windows
> NT" (IDG Books, ISBN 0-7645-3110-7): It's about $39 or so from the online
> book stores (amazon, etc...).
Ah...the ever present third party book...someday, maybe MICROSOFT will be
the best source of NT documentation. Don't hold your breath. For a company
that wants to beat IBM in the enterprise, MS really has NO clue whatsoever.
>
> Hope this helps!
> Dan
>
> At 01:45 PM 10/5/99 -0400, you wrote:
>>
>> With all the talk about servers these past few days I thought I'd ask a
>> question that I've been thinking about for some time now. Just how much
>> advantage is there using dual processors on an NT Server? Does the NT
>> operating system really take advantage of the two processors? Is that
>> extra processing power then available to just any program or they have
>> to be specifically written to use two processors? I've got a dual
>> 300Mhz Dell PowerEdge 4200 running NT Server with 256MB of RAM.
>>
>> ______________________________________________________________________
>> Tom Roth Wake Forest University School of Medicine
>> tomroth@wfubmc.edu Dept of Biomedical Communications
>> http://www.wfubmc.edu/biomed/ Medical Center Blvd
>> Tel 336.716.4493 Winston-Salem, NC 27157-1011
>> ______________________________________________________________________
Subject: Re: Re: dual processors on NT Servers
From: "Daniel L. Schwartz" <expresso@snip.net>
Date: Wed, 06 Oct 1999 00:09:56 -0400
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Uh oh... here we go!
At 11:43 PM 10/5/99 -0400, John wrote:
>Comments inline.
>
>NOTE: Despite what it may look like, this is a Microsoft flame, and not a
>Dan Flame. Having actually met Dan at MacWorld, I can attest that we both
>enjoy high-spirited arguments, which are NOT the same as personal attacks.
Agreed... But it also looks like an intel flame (see below).
>> Yes, NT is, and always has been. a fully symmetrical multiprocessor
>> operating system. Unlike MacOS & NetWare, which are pretty much
>> asymmetrical, NT's thread scheduler will gladly dispatch tasks to the
>> available CPU's by which one has the lightest load.
>>=20
>> BTW, along these same lines, this was one of the reasons that NT blew
>> linux out of the water in the controversial NT-linux shootout in early
>> summer: The testbed was a 4 CPU Dell box with 4GB of RAM. When the second
>> round of tests were performed - With RedHat & Microsoft engineers each
>> optimizing their respective systems - it was discovered that linux didn't
>> have a multithreaded TCP/IP stack!
>>=20
>
>unfortunately NT's thread scheduler is a joke, so one thread...i.e. a 2=
page
>word document, can eat 99% of the CPU, which doesn't happen on Unix. NT's
>scaling also goes in the terlet past 4 processors, whereas Unix and AS/400s
>scale happily to many more processors, support *real* clustering, and have
>uptimes of up to 5 years on average for the 400s. But hey, NT beat Linux,=
so
>that's all that matters.
Actually, over on the AlphaNT list we've been talking about this very
issue with the 8 way xeon (rip-off) servers coming out. BTW, everyone but
Compaq is having all kinds of hell with their 8 way designs using intel
boards. Only Q designed their own boards; and theirs work.
>> ------
>>=20
>> Just imagine the (hypothetical) men's room conversation at the lab:
>>=20
>> "Let's see, we don't have a multithreaded IP stack. Let's throw this into
>> the kernel and recompile..."
>>=20
>> "What about regression testing for quality & compatibility before putting
>> this out there?"
>>=20
>> "Ha Ha! This is Linux - As long as it works on this machine, fine.
>> Everyone else'll have to edit the kernel to suit their own "needs:" This=
is
>> "open source" at it's finest!"
>
>As opposed to the NT convo: "Gee, we can fix the umpteen bazillion security
>and reliability bugs...NAH...instead, let's tie everything into a pseudo -
>hierarchal(sp?) directory that is buzzword compliant, but won't be really
>functional for at LEAST 3 service pack..." MS operating systems at THEIR
>finest.
Well, it took 4 service packs for 3.51 (7 if you count NT 3.5), 3 SP's for
NT4, and with 65 million (and growing) lines of source code any guesses for
NT5/W2k?!
Besides, security in NT is fantastic: It's is fully C2 compliant... As
long as you don't hook it up to a network! :)
=20
>> ------
>>=20
>> Going back to the original NT question, applications don't need to know
>> anything about the hardware: They are "cradled" by the HAL (Hardware
>> Abstraction Layer) of NT, and NT will "break up" the application into=
its'
>> DLL (Dynamic Link Library) threads and distribute the threads amongst the
>> CPU's.
>
>If the HAL is so good at *cradling* apps, how come it couldn't abstract the
>processor, and why so much assembly optimizations for Intel, and not MIPS,
>Alpha, or PowerPC?
Exactly my point: This is (sorta) an *INTEL* problem, not an NT problem.
But, NT was also ported to i860 and i960. It's that x86 legacy crap that
requires all of that hand coding... And don't you think Linus has spent
more than a few sleepless nights using an x86 assembler?
>>=20
>> [Note that there *is* an exception: old 16 bit apps, which are run in
>> NTVDM (NT Virtual DOS Machine, an x86 emulator): Normally, NTVDM's run in
>> their own separate processes; but there are a few cases where the
>> "DefaultSeparateNTVDM" key has to be set to "No" in order for multiple
>> legacy apps to communicate between each other. In this case, NTVDM.EXE=
will
>> also run on only a single CPU. The obvious answer is to get rid of as=
much
>> of the 16 bit crap as possible: On a well-oiled NT Server this shouldn't=
be
>> too difficult]
>
>Why do I have to start gutting NT to make it well oiled. By the time that's
>done, I'LL need to be well oiled. Rebel Beer anyone? I never do this with
>Solaris...gee, good thing NT's SO much easier than Unix.
Aw, come on... All it takes is applying a few .REG files to tweak a few
keys, and all is fine.
=20
>> A good source of NT reference material is Sean Daily's "Optimizing=
Windows
>> NT" (IDG Books, ISBN 0-7645-3110-7): It's about $39 or so from the online
>> book stores (amazon, etc...).
>
>Ah...the ever present third party book...someday, maybe MICROSOFT will be
>the best source of NT documentation. Don't hold your breath. For a company
>that wants to beat IBM in the enterprise, MS really has NO clue whatsoever.
Novell is even worse. But in any case, do indeed thumb through this book
at your local Borders or Barnes & Noble...
Cheers!
Dan
-----------------------------------------------------------------
THERE ARE NO ATTACHMENTS TO THIS MESSAGE, SO IF ONE
APPEARS WITH IT, DO NOT OPEN OR DOWNLOAD IT!
<mailto:expresso@snip.net>=20
Webmaster for <http://www.Faulknerstudios.com>,
<http://www.BrakeAndGo.com>
This message is =A9Copyright 1999 by Daniel L. Schwartz, and
may not be reproduced except in its entirety.
-----------------------------------------------------------------
Subject: Re: [WinMac] Re: Re: dual processors on NT Servers
From: "Welch, John C." <jwelch@aer.com>
Date: Wed, 06 Oct 1999 10:37:15 -0400
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
lol...A good Intel flame would need 3 typists and a T-3!
> From: "Daniel L. Schwartz" <expresso@snip.net>
> Reply-To: "The Windows-MacOS cooperation list"<winmac@xerxes.frit.utexas.edu>
> Date: Wed, 06 Oct 1999 00:09:56 -0400
> To: "The Windows-MacOS cooperation list" <winmac@xerxes.frit.utexas.edu>
> Subject: [WinMac] Re: Re: dual processors on NT Servers
>
>
> Uh oh... here we go!
>
> At 11:43 PM 10/5/99 -0400, John wrote:
>> Comments inline.
>>
>> NOTE: Despite what it may look like, this is a Microsoft flame, and not a
>> Dan Flame. Having actually met Dan at MacWorld, I can attest that we both
>> enjoy high-spirited arguments, which are NOT the same as personal attacks.
>
> Agreed... But it also looks like an intel flame (see below).
>
>>> Yes, NT is, and always has been. a fully symmetrical multiprocessor
>>> operating system. Unlike MacOS & NetWare, which are pretty much
>>> asymmetrical, NT's thread scheduler will gladly dispatch tasks to the
>>> available CPU's by which one has the lightest load.
>>>
>>> BTW, along these same lines, this was one of the reasons that NT blew
>>> linux out of the water in the controversial NT-linux shootout in early
>>> summer: The testbed was a 4 CPU Dell box with 4GB of RAM. When the second
>>> round of tests were performed - With RedHat & Microsoft engineers each
>>> optimizing their respective systems - it was discovered that linux didn't
>>> have a multithreaded TCP/IP stack!
>>>
>>
>> unfortunately NT's thread scheduler is a joke, so one thread...i.e. a 2 page
>> word document, can eat 99% of the CPU, which doesn't happen on Unix. NT's
>> scaling also goes in the terlet past 4 processors, whereas Unix and AS/400s
>> scale happily to many more processors, support *real* clustering, and have
>> uptimes of up to 5 years on average for the 400s. But hey, NT beat Linux, so
>> that's all that matters.
>
> Actually, over on the AlphaNT list we've been talking about this very
> issue with the 8 way xeon (rip-off) servers coming out. BTW, everyone but
> Compaq is having all kinds of hell with their 8 way designs using intel
> boards. Only Q designed their own boards; and theirs work.
Isn't it cool that Intel is working it's heiny off to be the sole source of
x86 design specs...with SUCH high quality, why go anywhere else?
>
>
>>> ------
>>>
>>> Just imagine the (hypothetical) men's room conversation at the lab:
>>>
>>> "Let's see, we don't have a multithreaded IP stack. Let's throw this into
>>> the kernel and recompile..."
>>>
>>> "What about regression testing for quality & compatibility before putting
>>> this out there?"
>>>
>>> "Ha Ha! This is Linux - As long as it works on this machine, fine.
>>> Everyone else'll have to edit the kernel to suit their own "needs:" This is
>>> "open source" at it's finest!"
>>
>> As opposed to the NT convo: "Gee, we can fix the umpteen bazillion security
>> and reliability bugs...NAH...instead, let's tie everything into a pseudo -
>> hierarchal(sp?) directory that is buzzword compliant, but won't be really
>> functional for at LEAST 3 service pack..." MS operating systems at THEIR
>> finest.
>
> Well, it took 4 service packs for 3.51 (7 if you count NT 3.5), 3 SP's for
> NT4, and with 65 million (and growing) lines of source code any guesses for
> NT5/W2k?!
>
> Besides, security in NT is fantastic: It's is fully C2 compliant... As
> long as you don't hook it up to a network! :)
>
>>> ------
>>>
>>> Going back to the original NT question, applications don't need to know
>>> anything about the hardware: They are "cradled" by the HAL (Hardware
>>> Abstraction Layer) of NT, and NT will "break up" the application into its'
>>> DLL (Dynamic Link Library) threads and distribute the threads amongst the
>>> CPU's.
>>
>> If the HAL is so good at *cradling* apps, how come it couldn't abstract the
>> processor, and why so much assembly optimizations for Intel, and not MIPS,
>> Alpha, or PowerPC?
>
> Exactly my point: This is (sorta) an *INTEL* problem, not an NT problem.
> But, NT was also ported to i860 and i960. It's that x86 legacy crap that
> requires all of that hand coding... And don't you think Linus has spent
> more than a few sleepless nights using an x86 assembler?
>
Isn't it cool that Intel is still compatible with 8088 assembly code? Geez,
I like my thermometer, but I take it out occasionally!
>>>
>>> [Note that there *is* an exception: old 16 bit apps, which are run in
>>> NTVDM (NT Virtual DOS Machine, an x86 emulator): Normally, NTVDM's run in
>>> their own separate processes; but there are a few cases where the
>>> "DefaultSeparateNTVDM" key has to be set to "No" in order for multiple
>>> legacy apps to communicate between each other. In this case, NTVDM.EXE will
>>> also run on only a single CPU. The obvious answer is to get rid of as much
>>> of the 16 bit crap as possible: On a well-oiled NT Server this shouldn't be
>>> too difficult]
>>
>> Why do I have to start gutting NT to make it well oiled. By the time that's
>> done, I'LL need to be well oiled. Rebel Beer anyone? I never do this with
>> Solaris...gee, good thing NT's SO much easier than Unix.
>
> Aw, come on... All it takes is applying a few .REG files to tweak a few
> keys, and all is fine.
Nah, homey don't play that. If Microsoft can't be bothered to do it right,
why should I? I also don't go in and gut shipped OS extensions on my Macs
routinely. The only time I've violated this was for our webstar box, which
has no AppleTalk or AppleShare extensions running. Security concerns more
than functionality.
>
>>> A good source of NT reference material is Sean Daily's "Optimizing Windows
>>> NT" (IDG Books, ISBN 0-7645-3110-7): It's about $39 or so from the online
>>> book stores (amazon, etc...).
>>
>> Ah...the ever present third party book...someday, maybe MICROSOFT will be
>> the best source of NT documentation. Don't hold your breath. For a company
>> that wants to beat IBM in the enterprise, MS really has NO clue whatsoever.
>
> Novell is even worse. But in any case, do indeed thumb through this book
> at your local Borders or Barnes & Noble...
>
> Cheers!
> Dan
>
>
> -----------------------------------------------------------------
>
> THERE ARE NO ATTACHMENTS TO THIS MESSAGE, SO IF ONE
> APPEARS WITH IT, DO NOT OPEN OR DOWNLOAD IT!
>
> <mailto:expresso@snip.net>
>
> Webmaster for <http://www.Faulknerstudios.com>,
> <http://www.BrakeAndGo.com>
>
> This message is ©Copyright 1999 by Daniel L. Schwartz, and
> may not be reproduced except in its entirety.
>
> -----------------------------------------------------------------
>
> * Windows-MacOS Cooperation List *
>
Subject: Re: [WinMac] ETHERNET SPEED
From: Curtis Wilcox <cwcx@mail.rochester.edu>
Date: Wed, 06 Oct 1999 11:38:26 -0400
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; formatowed
At 04:24 PM 10/05/1999 -0700, Bruce Johnson wrote:
>They're 10baseT, meaning 10 megabit ethernet. Apple did not put 10/100
>interfaces on until (iirc) the B&W G3's. certainly no non-G3 Mac has
>anything but 10BaseT unless you added it on specifically.
Imacs had 10/100s before B&W G3s. I think the "Lombard" PowerBooks released
last spring were the first PowerBooks with 10/100.
</trivia>
--
Curtis Wilcox cwcx@ats.rochester.edu
Desktop Systems Consultant 716/274-1160
Eastman School of Music Pager: x12-3290
Subject: NT Stability, was Re: dual processors on NT Servers
From: John Hanks <jbh@biology.usu.edu>
Date: Wed, 6 Oct 1999 10:40:40 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
With respect to NT stability, frankly I wonder what I am doing wrong. I
continually read posts here and elswhere complaining about NT stability but
my servers and workstations are rock solid. One server has crashed once in
three years and that was during a Netscape install. Several times I have had
hard drives die that were part of the C: drive mirror (what, doesn't
everybody mirror the C drive on their server?) and the machine kept right on
running. Aside from some minor pre-sp2 problems with exchange which caused
exchange to crash but not NT, I would put our systems stability up against
any os and machine. I have NT workstations in student access labs that
routinely go a month or more before being turned off or rebooted (almost
always for no reason). Am I just lucky?
jbh
John Hanks
System Administrator
USU Dept. of Biology
Logan, UT
Subject: NT mirroring question
From: "Welch, John C." <jwelch@aer.com>
Date: Wed, 06 Oct 1999 14:01:28 -0400
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Here's one...
Compaq 1600 rackmount, 591MB RAM 450 PII
boot drive is mirrored, each drive in the mirror is on it's own SCSI card.
Drive 0 is on the motherboard interface
Drive 1 is on a SCSI - III card
all SCSI cards are supplied by Compaq
boot drives are the only devices on their respective buses
Drive 0 dies
get new drive in, rebuild the mirror, ALL data added since the initial drive
failure is *gone*
ideas
also for Dan...do you have a copy of the utomp.exe utility? we added a
processor to the terminal server box, and need to get NT to see it. Can't
find it on the resource kit CD or Microsoft's site
thanks,
john
Subject: Re: NT mirroring question
From: "Daniel L. Schwartz" <expresso@snip.net>
Date: Wed, 06 Oct 1999 15:03:25 -0400
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
It's UPTOMP.EXE, not UTOMP.EXE. It's just a new HAL, and it is indeed on
the ResKit CD.
BTW, you *can* install the multiprocessor HAL on a single CPU system: It
will slow it down about 5% when running in single CPU mode, but it *will*
work fine nonetheless.
As for your mirror question, I don't know: I've never seen one like this.
Cheers!
Dan
At 02:01 PM 10/6/99 -0400, you wrote:
>Here's one...
>
>Compaq 1600 rackmount, 591MB RAM 450 PII
>
>boot drive is mirrored, each drive in the mirror is on it's own SCSI card.
>Drive 0 is on the motherboard interface
>Drive 1 is on a SCSI - III card
>
>all SCSI cards are supplied by Compaq
>
>boot drives are the only devices on their respective buses
>
>Drive 0 dies
>
>get new drive in, rebuild the mirror, ALL data added since the initial drive
>failure is *gone*
>
>
>ideas
>
>also for Dan...do you have a copy of the utomp.exe utility? we added a
>processor to the terminal server box, and need to get NT to see it. Can't
>find it on the resource kit CD or Microsoft's site
>
>
>thanks,
>
>john
End of WinMac Digest
* Windows-MacOS Cooperation List *
This archive was generated by hypermail 2.0b2
on Wed Oct 06 1999 - 17:07:11 PDT
|