naim@uswat.uswest.com (Naim Abdullah) (12/28/90)
Just saw this note on comp.os.mach and thought that people here would be
interested. If the price of this product is comparable to the prices of
the commercial system V offerings from Interactive, SCO, Dell etc., then
this is very good news indeed.
If anybody finds out anymore about this product, please post your
information.
waiting in anticipation,
Naim
=========================================================================
From: bob@MorningStar.Com (Bob Sutterfield)
Newsgroups: comp.os.mach,mst.general
Subject: binary Mach distribution for 386
Message-ID: <BOB.90Dec26172306@volitans.MorningStar.Com>
Date: 26 Dec 90 22:23:13 GMT
Sender: usenet@MorningStar.COM (USENET Administrator)
Reply-To: bob@MorningStar.Com (Bob Sutterfield)
Organization: Morning Star Technologies
Lines: 12
I received a postcard in the mail today from MtXinu, announcing that
in late January, they'll begin shipping a binary distribution of Mach
for AT-bus 386 machines. This will include the 4.3BSD emulator, but
no ATT or BSD source license will be required to acquire the binary
distribution. Distribution options will include (a) the base system,
(b) networking, (c) X, and (d) on-line documents. They'll have more
literature available in mid-Janary, including required and supported
devices, etc. What's more, they'll have special show prices at
Uniforum in Dallas, Jan 22-24.
I have no connection with MtXinu, except as an excited anticipant.
Hmmm, what's the going rate on a 386 laptop?
=========================================================================kittlitz@granite.cr.bull.com (Edward N. Kittlitz) (01/04/91)
In article <13963@uswat.UUCP> naim@uswat.uswest.com (Naim Abdullah) writes: >Just saw this note on comp.os.mach and thought that people here would be >interested. >>I received a postcard in the mail today from MtXinu, announcing that >>in late January, they'll begin shipping a binary distribution of Mach >>for AT-bus 386 machines. I received the same card and made a brief enquiry. I was told that there is no SCSI support (yet?). Also, there is apparently no binary compatability support (ABI?) for System V.3. (after all, I believe we are talking about BSD emulation). If this is correct, you won't have the same flexibility in buying binary-only applications, most of which are V.3 SCO/ISC. ----- E. N. Kittlitz kittlitz@world.std.com / kittlitz@granite.cr.bull.com Contracting at Bull, but not alleging any representation of their philosophy.
shore@mtxinu.COM (Melinda Shore) (01/05/91)
In article <1991Jan4.140341.11874@granite.cr.bull.com> kittlitz@granite.cr.bull.com (Edward N. Kittlitz) writes: >I received the same card and made a brief enquiry. I was told that there >is no SCSI support (yet?). Also, there is apparently no binary compatability >support (ABI?) for System V.3. (after all, I believe >we are talking about BSD emulation). If this is correct, you won't >have the same flexibility in buying binary-only applications, most >of which are V.3 SCO/ISC. All of the above is true. Our customers have traditionally been engineering/software types - technically sophisticated and interested in the technology itself. We envision our potential customer base for the Mach binary product to be very much the same - software development houses who want to start getting involved with Mach and OSF/1 early, people who want interesting technology for their home machines, users who specifically want a BSD system interface, and so on. We are not in competition with SCO, ISC, or the other vendors of small Unix systems - what we're selling is completely different, and not really suitable for use as a black box to stick a database or word processor on. The executable format is almost identical to BSD a.out, and we haven't considered adding ABI support. That's not to say we never will, but if we do it won't be for a very, very long time. -- Software longa, hardware brevis Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
src@scuzzy.in-berlin.de (Heiko Blume) (01/05/91)
kittlitz@granite.cr.bull.com (Edward N. Kittlitz) writes: >Also, there is apparently no binary compatability >support (ABI?) for System V.3. nothing stops us from emulating that too. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
shore@mtxinu.COM (Melinda Shore) (01/06/91)
In article <1991Jan05.021138.17495@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >kittlitz@granite.cr.bull.com (Edward N. Kittlitz) writes: >>Also, there is apparently no binary compatability >>support (ABI?) for System V.3. > >nothing stops us from emulating that too. This distribution is based on Mach 2.5, which has a monolithic kernel. Filtering before execution might be a possibility, but Mach doesn't support execution out of multiple 386 segments. -- Software longa, hardware brevis Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
src@scuzzy.in-berlin.de (Heiko Blume) (01/07/91)
shore@mtxinu.COM (Melinda Shore) writes: >In article <1991Jan05.021138.17495@scuzzy.in-berlin.de> I wrote: >>kittlitz@granite.cr.bull.com (Edward N. Kittlitz) writes: >>>Also, there is apparently no binary compatability >>>support (ABI?) for System V.3. >> >>nothing stops us from emulating that too. >This distribution is based on Mach 2.5, which has a monolithic kernel. >Filtering before execution might be a possibility, but Mach doesn't >support execution out of multiple 386 segments. what a pitty, will Mach 3.0 have the main "kernel" components (except the message passing et al) in seperate processes? i always considered this one of the main advantages. btw: the uni i'm at has a message passing system called AX, that 'knows' ms-dos, qnx and sorta sys v. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
shore@mtxinu.COM (Melinda Shore) (01/09/91)
In article <1991Jan07.152536.28530@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >what a pitty, will Mach 3.0 have the main "kernel" components (except >the message passing et al) in seperate processes? Yes, version 3.0 is the first "kernelized" version. It's running with a BSD single server, but really isn't ready for commercial release, especially not into the 386 market. >i always considered >this one of the main advantages. I don't. The idea is nice, but it's generally pretty slow to run on top of a micro-kernel (Chorus is an exception). You pay in the form of more context switching and more data movement. A lot of the performance problems have been worked out of 3.0, but there's still some work to be done. The *real* advantage of Mach is the abstractions that it provides the programmer. -- Software longa, hardware brevis Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
src@scuzzy.in-berlin.de (Heiko Blume) (01/11/91)
shore@mtxinu.COM (Melinda Shore) writes: >In article <1991Jan07.152536.28530@scuzzy.in-berlin.de> I wrote: >>i always considered >>this [the micro-kernel] one of the main advantages. >I don't. The idea is nice, but it's generally pretty slow to run on >top of a micro-kernel (Chorus is an exception). You pay in the form >of more context switching and more data movement. A lot of the >performance problems have been worked out of 3.0, but there's still >some work to be done. The *real* advantage of Mach is the abstractions >that it provides the programmer. well, it's certainly much slower if you always have to relink that damn huge monolithic kernel and reboot if you changed something in the serial driver :-) i think all those intelligent peripherals, like scsi host adapters, multiport and ethernet cards, with their own processors and RAM can help a lot with these performance problems. Given the possibilty to write and test drivers without relinking the kernel etc., i expect/hope to see quite nice mach 3.0 machines pretty soon. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
shore@mtxinu.COM (Melinda Shore) (01/12/91)
In article <1991Jan11.200913.15652@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >That's actually less surprising in the 386 world. Context switches on the >386 (assuming a full switch--a TSS change via call gate) are relatively >expensive, and interrupts are even worse because of the MM of dealing with >the PICs. Open question (I suspect): Is Mach 3.0 a bad match to the 386 >(based on context-switch frequency and cost)? Whether or not it's a bad match is somewhat moot - much of the 3.0 development is being done on 386 machines, and Rick has a Toshiba laptop he seems always to have with him that's running 3.0. One advantage, I think, of this is that it encourages the folks at CMU to pay particular attention to performance issues. >When does OSF plan to move to the 3.0 kernel? This is probably best left to the OSF to answer (their direction shifts frequently, especially within the RI), but I haven't seen any of them lurking in these parts. The last official story I heard was that they are not committed to moving to a 3.0 kernel, and are looking at other interesting operating systems as well to be used as a possible kernel for OSF/2. They are, however, putting significant effort into 3.0 development, and are driving some of the design decisions. In fact, they're sponsoring a 3.0 design review meeting next month. -- Software longa, hardware brevis Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
lance@motcsd.csd.mot.com (lance.norskog) (01/13/91)
rcd@ico.isc.com (Dick Dunn) writes: >shore@mtxinu.COM (Melinda Shore) writes: >> ...Also, you'd be surprised at how much >> context switching can affect performance... >That's actually less surprising in the 386 world. Context switches on the >386 (assuming a full switch--a TSS change via call gate) are relatively >expensive, and interrupts are even worse because of the MM of dealing with >the PICs. Open question (I suspect): Is Mach 3.0 a bad match to the 386 >(based on context-switch frequency and cost)? Well, there a few problems with standard UNIX on the 386 that might go away with Mach: 1) UNIX re-uses the same kernel addresses for different processes. This forces UNIX to toss the page table cache during context switches, >when an operating system shouldn't have to<. I don't believe the standard figure of 98% page table cache hits for these systems. Are there any hard studies of real code executing? 2) UNIX still uses the PDP-11 interrupt hierarchy model. The 386 PIC code implements a faithful and extremely expensive emulation of this model. Philips (Dutch) wrote a window manager for terminals as a Streams multiplexor. They found that 20% of the CPU time, measured by a logic analyser, was spent in the interrupt management code. It would be quite easy to replace the hardware interrupt hierarchy with a software-based scheme where the only interrupt management is done with the enable/disable op codes. 3) Use 4K blocks and fiddle page tables instead of copying data around. The RAM situation that forced 1K blocks is over. (If Intel still sold the DRAM chips they invented, it would have been 4K blocks from the beginning.) Note to Benny: Any 386 UNIX port that uses the above tricks will leave the current crop in the dust. Lance
src@scuzzy.in-berlin.de (Heiko Blume) (01/16/91)
shore@mtxinu.COM (Melinda Shore) writes: >In article <1991Jan10.163048.20613@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >>i think all those intelligent peripherals, like scsi host adapters, multiport >>and ethernet cards, with their own processors and RAM can help a lot with >>these performance problems. >For example, when E&S >was bringing Mach up on their ill-fated supercomputer, they found >that they were only getting 500K throughput on a 10 megabit ethernet. >The problem turned out to be that the folks at CMU had replaced >the software interrupt mechanism for moving packets into the protocol >layer with a kernel thread. The network code, of course, was >pre-tahoe BSD, so they should have been seeing about 1.5 megabits. >You all can do the arithmetic. that's why i mentioned the intelligent peripherals. it's necessary to offload the network code to the interface anyway. for example, with host based tcp/ip over 100Mbit FDDI you get about 20Mbit/s max throughput. if you use the FDDI- and TCP/IP-chips you get about 70Mbit/s. i think that clearly shows the way to go. >And, >if you want to see Mach 3.0 any time in the near future, I would >suggest looking into getting an AT&T source license. just a little bit too expensive... -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
vjs@calcite.UUCP (Vernon Schryver) (01/18/91)
In article <1991Jan15.182524.14868@scuzzy.in-berlin.de>, src@scuzzy.in-berlin.de (Heiko Blume) writes: > ... > that's why i mentioned the intelligent peripherals. it's necessary > to offload the network code to the interface anyway. for example, with host > based tcp/ip over 100Mbit FDDI you get about 20Mbit/s max throughput. > if you use the FDDI- and TCP/IP-chips you get about 70Mbit/s. > i think that clearly shows the way to go. I've kept my daytime employer convinced of several contrary statements. One is that my code does much more than 20Mbit/sec TCP/IP/FDDI while doing no more than the link layer on the board, and that this is not an accident. Another is that the fact that smarter ethernet boards are slower on this series of systems is not due to our group's stupidity. There was an FDDI board vendor claimed 80Mbit/sec at InterOP 89. More recent, real benchmarks offered to try to sell us the same board were closer to 15 Mbit. The highest honest TCP/IP/FDDI numbers I have heard in the halls around X3T9.5 meetings and via industry gossip of "secret" projects are ~40Mbit/sec. (Please infer nothing about my forthcoming efforts.) I will be in your debt if you point out announcements of numbers larger than 30Mbit. 80Mbit is easy if you continual blast the same packets. TCP/IP delivered to application processes is harder. I do not know of any "TCP/IP chips", although I know about PEI and XTP. To what are you referring? Vernon Schryver, vjs@calcite.uucp