karl@ddsw1.MCS.COM (Karl Denninger) (09/05/89)
In article <71@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >In article <1989Sep4.024559.13279@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes: >> > ...[a loud rebuttal]... > >I got Mr. Denninger's dander up. Be careful or thick skinned when not >complimenting what people sell. He is obviously wrong and inconsistent on >several technical issues, but such technicalities are not germane to what >he is saying. How about listing those examples I asked for? One Unix Operating System, commercially available for the 80386, that has these wonderful changes in it you espouse? One Unix for the '386 that doesn't bypass the buffer cache for raw I/O requests? A better solution for the 386 systems of TODAY, available NOW -- than the DPT boards for greatly increasing I/O performance? Tell us about this wonderful "fixed" Unix. Where can I buy it? If it doesn't exist, then all you are doing is playing devils' advocate and not furthering the exchange of information here. How about discussing what I am talking about rather than a personal attack? Or is "ad hominen" the order of the day here in this nice technical group too? Yeah, you got my dander up. You're out here spouting off at the fingers about some utopian operating system which we can't buy. Some enhancement to the kernel that we can't make. The rest of us in this newsgroup operate in the real world, not a utopia with kernel source access. As for incorrect on technical issues, which ones? The assertion that there is no better way to handle drive failure than mirroring? The assertion that given the _current Unix systems available for ISA 80386 machines_ the DPT board is your best shot at excellent I/O performance? The assertion that the idea of "commit to stable storage" is a crock given the inherent failure possibilities in all fixed storage using today's technology? I'd like to hear your refutation of these points. >As I agreed in the article which got him excited, the DPT controller sounds >good for small, slow computers such as this 20MHz, 8MB clone, for those of >us without the money, time, talent, or source to fix the SV kernel. Ah, now here comes the qualification. The truth of the matter is that I, or anyone else, don't give a whit about what one can do with the source to System VR(x). Do you have a spare $65,000 laying around for a source license, and a lot more for that binary redistribution license? I thought not. Neither do 99.9% of the people out there who are reading this newsgroup, or who buy and use these systems. Lots of us have the talent to fix the kernel. Not many of us have the time, source, or money. Even fewer can support that change with a large customer base, and thus we have to, out of necessity, turn to those companies (SCO/ISC/Bell) for our Unix(es). If you can do it better, buy a source license, binary redistribution rights, and blow the rest of the market out of the water. Until you do that, you've got little room to complain or nit-pick about real-world solutions to real-world problems. >This >part of my life qualifies, so I would happily accept one for an extended >evaulation. However, the simple professional honesty required in another >part of my life compels me to say the DPT controller is architecturally >wrong. That AT&T et al currently make it useful and desirable is irrelevant. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >There is no reason to lie to customers and say it is more than a neat and >cheap kludge around design flaws in some versions of SVR3, or to claim >those flaws are part of "UNIX." Design flaws? Look, if you don't like Unix, then go run VMS. (1/2 :-) Even better, if you like to espouse such drivel, why don't you hire yourself out to AT&T, SCO, ISC, et.al. Why haven't you do this two + years ago? The simple professional honesty in my working life requires that I recommend use and sell that which works, now. A person who comes to us (or anyone else) needing a solution isn't going to accept, nor should they, a "well, it might be fixed in a few years, but right now it sucks. Since you can't afford the $200k solution, you just have to wait." When you can hold out your "fix" for the "design flaws", for sale (or free), and in addition can support the monster you create, then and only then can you complain about the DPT (or other caching controllers) being a kludge and unsuitable for "real computing". Until then we'll use what works, thank you very much. From your comment above it's obvious you've never used one of the DPT boards. So this entire discussion is academic; you don't have any experience with the product. How can you flame something you've never even seen or tried?! >In 1989, "fast" uniprocessor workstations are >=20 times a VAX 780, 3-5 times >faster than 386 clones. True, they use 88K's, SPARK's, or MIPS-R3000's >instead of 386's and cost more than $2,500 (but <$25,000). You can buy >multiprocessor workstations well over 100 VUPS (1VUP=1VAX 780). Ok, I'll bite. How much for that 100 VUPS workstation with your "fixed" version of Unix? Is this, again, an academic discussion? (You haven't seen the 80486 systems yet, have you? ISA bus, 30-50 VUPS, available before Christmas 89, base cost under $12k. But I digress...) If they're not ISA 80386 systems, then there is no point to discussing them here. Take it to comp.arch where it belongs. This group is for discussion of machines that are ISA based and use a '386 processor (and have the additional quality of costing a few thousand, not $25k). Some of us bought them because we need or want to run (horror of horrors) MSDOS through VP/IX or Simultask while we're using our Unix. Try _that_ trick on your Sparcstation. Comp.unix.i386 is also for discussion of REAL Unix operating systems available for these machines, not dreams that someone has in their head, or something for a minicomputer that isn't available. > At least >one such SVR3 until recently mapped raw disk I/O to cooked. (Disagreement >on that point from a PC VAR are boring to a hack paid to work in that kernel.) Until recently, eh? Why did they change it back? Hmmmm.... You know, someone just struck me as obvious. If you buffer raw writes, then you also need that UPS. You see, many DBMS systems work with raw I/O.... there goes your full buffer cache when the lights go out or the system panics. Hmmm.... Even the UPS doesn't help when you panic, does it? Oh well. Rather clever of that DPT board -- how it doesn't use the same memory space as the kernel, so a corrupt data area in the kernel can't crash the buffers.......and it's smart enough to write out it's cache even after the main processor halts. Now _that_ would be a good trick for your "fixed" kernel to pull off. I daresay that the DPT solution (off-board cache processor) is superior than your idea for the reason of greater data security alone. Unix systems do panic, you know. Not often (we hope anyway), but it does happen. >That we are now stuck with no more than half-dozen VUPS is no reason to get >religous. This is comp.unix.i386, not biz.att or biz.MacroComputerSolutions. >People here snear at the silliness of DOS extended memory. Let's not >permanently wed an analogous kludge for what are hopefully temporary O/S bugs. > >Vernon Schryver >vjs@calcite.uucp or ...!{sgi,pyramid}!calcite!vjs You bet it's not biz.*, but it's also not bash.att or bash.mcs. You've done nothing other than proselytize about systems that aren't under discussion and imaginary operating systems we can't purchase. Until either of those items change, your points are irrelavent in relation to the topic of this group and the merits (or lack thereof) regarding the DPT boards. You know, something amazing was just revealed to me ("grep" time). Guess what "calcite" is, and what "Rayolite Systems" has as their Usenet machine. Why, a '386 system running Microport SV/386! So much for those systems (hardware and software) you would like to claim are "far superior", eh? Why aren't you using one of them? Heh, you're even listed as the administrator of this "incompetent" Unix product. (chuckle). Followups redirected to alt.flame where they belong. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
vjs@calcite.UUCP (Vernon Schryver) (09/06/89)
UNIX machines much faster than current 386 products can now be purchased from
DEC, Sun, Silicon Graphics, MIPS, Data General, and probably others.
The first two have machines less than $10,000. These machines are all at
least 10 times a VAX 780 (i.e. 10VUPS), and so about 2-4 times a fast 386
clone. For less than $30,000 you can buy a complete 20-VUPS machine. Less than
$200,000 buys a 160-VUPS multiprocessor with GB of disk. DEC's run
ULTRIX, which is 4.2BSD based+SV compatible, and therefore of better flavor
than SV. (Or worse, depending on taste.) Sun makes much of the similarity
between SunOS4.0 and SVR4. The remainder have straight or compatible
SVR3. The file systems on the DEC, Sun, SGI, and MIPS machines are many
times (perhaps 10) as fast as the old 512-byte SV file system. SGI's
"Extent File System" uses variable size blocks (currently up to 16KB), and
so is possibly much faster than the BSD-FFS on the other 3. Sun, SGI, and
probably others support "mapped files" which allow applications to
effectively bypass the buffer cache, without giving up the advantages of
kernel buffering.
These prices, for at least three companies, include "real" graphics, rather
than imitations like VGA. (Before flaming: VGA is wonderful because it
costs only about $1,000, but it is not in the same universe.) Ethernet is
also included with most, and at least some run user-TCP >800KByte/sec.
Most of these machines have some low extra cost facility for running DOS
3.x at (they say) AT speed, such as the Ensignia product.
All of these companies have UNIX source, and are not affraid to try to do
better than AT&T's file system, buffer cache, regions, etc. Some, including
my day time employer, have been successful.
After buying tape, 2nd hard disk, 2 UNIX's, RAM, TB+, and so on, I have
about $10,000 in this 386 clone. That may be less than the price of a
useful SPARK Station or DEC 2100 (you need a disk), but not much less.
During the day, I use a <censored>, and find it incomparably faster than
this 386. Someday maybe I'll be rich and able to replace it.
Anyone buying a machine today should talk to more than the nearest PC VAR.
Sorry, but I don't have useful sales office addresses for more than two of
these vendors, and you should talk to them all, and others such as NEXT.
Vernon Schryver vjs@calcite.uucp or ...{pyramid,sgi}!calcite!vjsplocher%sally@Sun.COM (John Plocher) (09/06/89)
In article <1989Sep5.052934.20655@ddsw1.MCS.COM> Karl Denninger writes: >them because we need or want to run (horror of horrors) MSDOS through VP/IX >or Simultask while we're using our Unix. Try _that_ trick on your >Sparcstation. :-) OK ... it works. Wonder of wonders, you don't need a 386 to run DOS programs slowly :-) Just a fast processor and some emulator software :-) Alt.flame, here I come .... -John Plocher
peter@ficc.uu.net (Peter da Silva) (09/06/89)
In article <1989Sep5.052934.20655@ddsw1.MCS.COM>, karl@ddsw1.MCS.COM (Karl Denninger) writes: > Yeah, you got my dander up. You're out here spouting off at the fingers > about some utopian operating system which we can't buy. Some enhancement to > the kernel that we can't make. The rest of us in this newsgroup operate in > the real world, not a utopia with kernel source access. Let me tell you a little story. There is a company called Commodore that manufactures a computer called the Amiga. Now there was a design flaw, or if you like... a bug, in version 1.2 of the operating system that gave a large advantage to a particular hardware caching policy. Another company, called ASDG, designed a disk controller called the SDP to take advantage of this. Unfortunately for ASDG, Commodore fixed the design flaw in version 1.3 of the operating system before ASDG could get the SDP out the door. The SDP vanished... You're luckier... AT&T is somewhat slower about coming up with updates than Commodore, and has neglected to fix this particular flaw. But you're still in the position of the folks who build extended memory systems for DOS. The product will remain in use, but folks will still gripe about its necessity. You might as well get used to it. > Comp.unix.i386 is also for discussion of REAL Unix operating systems > available for these machines, not dreams that someone has in their head, > or something for a minicomputer that isn't available. I proposed this group and ran the vote, and don't recall making any sort of exception for wishful thinking and pipe dreams. After all, why should this group be the sole exception? I definitely agree with you that this discussion has gotten a bit rancorous... -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "The Distribution: field on the header has been modified so as not to 'U` violate Information Export laws." -- eugene miya, NASA Ames Research Center.
steve@simon.UUCP (Steven E. Piette) (09/09/89)
In article <1989Sep5.052934.20655@ddsw1.MCS.COM>, (Karl Denninger) writes: > In article <71@calcite.UUCP>, (Vernon Schryver) writes: > >In article <1989Sep4.024559.13279@ddsw1.MCS.COM>, (Karl Denninger) writes: > >In 1989, "fast" uniprocessor workstations are >=20 times a VAX 780, 3-5 times > >faster than 386 clones. True, they use 88K's, SPARK's, or MIPS-R3000's > >instead of 386's and cost more than $2,500 (but <$25,000). You can buy > >multiprocessor workstations well over 100 VUPS (1VUP=1VAX 780). > > If they're not ISA 80386 systems, then there is no point to discussing them > here. Take it to comp.arch where it belongs. This group is for discussion > of machines that are ISA based and use a '386 processor (and have the > additional quality of costing a few thousand, not $25k). Some of us bought > them because we need or want to run (horror of horrors) MSDOS through VP/IX > or Simultask while we're using our Unix. Try _that_ trick on your > Sparcstation. > I agree with Karl that this is not the place to go into most of this dicussion, but since Karl makes the point to this group that one CAN'T run MSDOS on a SparcStation, it's only fair to point out his ERROR in the group as well. You can run MSDOS applications on any SparcStation!. The product is called DOS Windows and provides MSDOS emulation in as many windows as you can stand ;-) Unlike the 386i (RoadRunner) machine that actually RUNS VP/IX as a standard part of the OS, The SparcStation's DOS Windows product emulates both the '86 and the rest of an ISA system in software. On a SS1 (~$12,000 12.5 Vups) DOS Windows delivers about AT class performance. While its not a speed demon it does allow people to avoid having two systems at their desk which is why most of us want VP/ix right. (Besides it will run much faster on one of BIT's 50Mhz SPARC's :-)). Back to the original discussion, As soon as I can I must get a DPT. My WD1007 was a big improvement over the WD1003 but it's still not fast enough..... -- Steven E. Piette Applied Computer Technology Inc. UUCP: {smarthost}!simon!steve 1750 Riverwood Drive INET: steve@simon.CHI.IL.US or spiette@SUN.COM Algonquin, IL 60102 -------------------------------------------------------------------------------
fr@icdi10.UUCP (Fred Rump from home) (09/12/89)
In article <73@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: > [bunch of nonsense deleted] >All of these companies have UNIX source, and are not affraid to try to do >better than AT&T's file system, buffer cache, regions, etc. Some, including >my day time employer, have been successful. Ok, shall we guess and blame Silicone Graphics for you? Just for the hell of it, how many users would you hang onto one of those wonderful workstations you describe? Are we still in the same general neighborhood? >After buying tape, 2nd hard disk, 2 UNIX's, RAM, TB+, and so on, I have >about $10,000 in this 386 clone. That may be less than the price of a >useful SPARK Station or DEC 2100 (you need a disk), but not much less. >During the day, I use a <censored>, and find it incomparably faster than >this 386. Someday maybe I'll be rich and able to replace it. You sure got hosed by somebody. No wonder you hate your box. For that kind of money we could put you into a neighborhood of real i/o. None of that fancy graphics stuff, of course. We don't normally need it. But lots of raw speed that would compete effectively with any of the boxes you mentioned. >Anyone buying a machine today should talk to more than the nearest PC VAR. >Sorry, but I don't have useful sales office addresses for more than two of >these vendors, and you should talk to them all, and others such as NEXT. You seem to be completely ignorant of what the majority of the VARs that read this group sell. UNIX/Xenix = multi-user. We need lots of i/o. Ergo a DPT. The only RISC machine I know of that will also run lots of terminals is the MIPS 2000. It starts at around $50G's. Not quite the neighborhood we were talking about, right? >Vernon Schryver vjs@calcite.uucp or ...{pyramid,sgi}!calcite!vjs Fred Rump -- This is my house. My castle will get started right after I finish with news. 26 Warren St. uucp: ...{bpa dsinc uunet}!cdin-1!icdi10!fr Beverly, NJ 08010 domain: fred@cdin-1.uu.net or icdi10!fr@cdin-1.uu.net 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller