Date: 24 Feb 89 08:16:25 EST (Fri) From: "Wm E. Davidsen" Subject: 80386 mailing list, vol 4 #11 To: 386users@TWG.COM 80386 User's mailing list vol 4 #11 Feb 24, 1989 In this issue: 68020 vs 80386 [ 2 msgs ] Optimal Unix Vendor Question... Intel 302 machine: speed Analog and Digitial Schematic Design Software 386 Caches for the 386 mailing list Dos and unix, hypertext, disk controllers Re: Merge386 - Mixing DOS and UNIX (on serial lines ...) Re: Using a Hayes-type modem with System V/386 Re: Request for help on Intel microarchitectures Re: Gateway 2000 386 VGA Experience Co-Processor Board Info The addresses for the list are now: 386users@TWG.COM - for contributions to the list or ...!uunet!TWG.COM!386users 386users-request@TWG.COM - for administrivia or ...!uunet!TWG.COM!386users-request P L E A S E N O T E If you want to get on or off the list, or change your address, please mail to the 386users-request address, or the message will be delayed by having to hand forward it (for your convenience, not mine). ---------------------------------------------------------------------- From: steinmetz!uunet!sir-alan!mikes Subject: 68020 vs 80386 Date: Thu Feb 16 00:14:10 1989 AGW Cameron in one of the last Micro/System Journal magazines gave results of running a largish FORTRAN simulation (stellar interiors) on a SUN 3/260, Compaq 386/20 with Weitek FPU, and SUN 4/280. The speed was in that order; the 386/20 was faster than the SUN 3/260 and 80% of the speed of the SUN 4/280. This is obviously highly dependent upon compiler quality; the FORTRAN on the 386/20 was SVS FORTRAN 77 using a DOS extender. I am about to run some simple benchmarks on a 386 20MHz system and a SUN 4/100 (Byte UNIX benchmarks); the 386 system has a 387, not a Weitek FPU and I would expect the SUN 4/110 to outperform the 386/387 combination by a greater margin than the 386/Weitek combo. But, on the other hand, maybe not, if the scuttlebutt from SUNSpots can be belived... Michael L. Squires uucp: {necntc,cwjcc,hoptoad}!ncoast!peng!sir-alan!mikes Department of Political Science ..!{pitt,uunet!convex,uunet}!sir-alan!mikes Allegheny College BITNET: mikes%sir-alan@pitt.UUCP (VAX) Meadville, PA 16335 MIKES AT SIR-ALAN!PITT.UUCP (IBM) Office: 814 332 3347 Internet: sir-alan!mikes@vax.cs.pittsburgh.edu Home: 814 337 5528 Data: 814 {337-3159,337-0348} login of "ubbs" for BBS ------------------------------ Date: Mon, 13 Feb 89 02:38:01 EST From: Stefan Mochnacki Subject: Re: 80386 vs. 68030 (386 vs 020) mike@stolaf.UUCP (Mike Haertel) writes: >to use various 386 and '020 machines and, taking differences of clock >speed, etc. into account I had the impression that the '020 machines >were faster. I was using the same compiler (gcc) on both architectures. Comparing real machines, the 386 is faster (although the real 68020 machines have a slower clock). Here's a comparison I have made (approx. 350 lines of code): Benchmark_used: TESTER.FOR, an accurate double Simpson's Rule integration of Roche lobes of binary stars. Identical code compiled on all machines listed below, with full optimization on. It is a fairly small programme, with heavy use of floating point. "time" utility used. An iteration with half the number of steps was used to see whether compute times scale proportionately (I/O overhead test). All within about 10%: muVAX worst). Computer O/S Compile+link (sec.) Execution(sec) (user or CPU) (user or CPU) Compaq I (5 MHz 88/87) PC-DOS 3.2/ MS-F77 v4.0) 273 76 IBM PS/2-30(8 MHz 86/87) PC-DOS 3.3/ 40 (?) MS-F77 v4.0) DEC microVAX II mu-VMS 4.7 18 10.3 Sun 3/110 (68881) SunOS 3.5 42 8.6 Sun 3/180 (FPA) SunOS 3.4 42 5.2 Sun 386i RR150-FC8 SunOS 4.0.1 40 6.9 (20 MHz 386 + 387) Sun 386i RR250-FC4 " " 25 6.0 (25 MHz 386 + 387 + cache) Sun 4/260 SunOS 3.2 16 3.1 << This shows that Roadrunner RR250 with Weitek FPA should be similar to Sun 4/260, on THIS benchmark ... >> The poor Weitek FPA (Sun 3 & 4) figures are probably due to my benchmark doing a lot of square roots. Stefan W. Mochnacki INTERNET - stefan@helios.physics.toronto.edu Astronomy, U. Toronto UUCP - {uunet,pyramid}!utai!helios!stefan +1 (416) 884-9562 BITNET - mochnacki@utorphys.bitnet ------------------------------ Date: Tue, 14 Feb 1989 18:19:37 EST From: Micky Liu Subject: Optimal Unix Vendor Question... I have a couple of generic 386 boxes that I am in the process of installing Unix on. I am currently using Interactive's 386/ix, R 2.0 and it appears to be okay except for some small things... I was wondering if there were some other flavors available for 386 machines that were better in any way, i.e. support, etc. I know that Interactive was the major porter for all of the standard 386 Unixes, but having worked quite a bit with bigger Unixes, this 386 stuff is quite disappointing... I am also looking for TCP/IP and NFS packages to work with my 386 box... Interactive says they will ship in mid-March, but I don't really trust that date yet... Are there third-party vendors that sell those products? Thanx in advance! Micky Liu arpa: micky@cunixc.cc.columbia.edu uucp: ...!rutgers!columbia!eastend!m-liu bitnet: malua@cuvmc ------------------------------ Subject: Intel 302 machine: speed Date: 10 Feb 89 10:17:39 PST (Fri) From: "Keith Ericson at TekLabs (resident factious factotum)" > > Subject: Re: Intel iSBC386/16 > Date: 30 Nov 88 07:53:54 GMT (Wed) > From: steinmetz!uunet!slxsys.specialix.co.uk!jpp (John Pettitt) > > > > Date: Sun, 16 Oct 88 14:35:38 -0400 > > From: ken@gatech.edu (Ken Seefried iii) > > Subject: Intel iSBC386/16 > > > > I was wondering if there were many people that are running either the > > Microport or Interactive port on an Intel iSBC386 motherboard. Is this an > > acceptable hardware platform? > > > > Any comments? > > > > [ It works... Intel makes chips, not motherboards. This is one of the slower > > boards out there, and its price doesn't match its performance. Get a clone. > > --vix ] > > Thats true of the 301 board (the 16 Mhz version) but the 302 is a another > matter. The 302 is a 25 Mhz board with a performance about twice that > of the 16 Mhz. > > Well, maybe.... Intel has decided that COMAPTIBILITY is more important than performance and has therefore implemented an 8 MHz bus speed in it's 302 box. In our timing tests - we were concentrating on speed of video display updates - we found the 302 to be "a slug" (relative to what we had expected, that is). While the local field office swears up & down that the bus is running 8 MHz it appears to be running at 6 MHz. We're in the process of having the board swapped (or something) to see if they (Intel) can get us a machine that performs in accordance to the advertising and pricing. Given a choice between an Intel 302 with UNIX from Interactive or Microport or an Everex Step/25 with ENIX I think I'd prefer the Everex. (I have Enix on order. That'll be the subject of a later note.) kEITH Keith Ericson at TekLabs (resident factious factotum) Tektronix, PO 500, MS 58-383 Beaverton OR 97077 (503)627-6042 UUCP: uunet!tektronix!tekgvs!keithe ARPA: keithe%tekgvs.LABS.TEK.COM@RELAY.CS.NET CSNet: keithe@tekgvs.LABS.TEK.COM ------------------------------ From: steinmetz!uunet!esdvax.arpa!narayan Date: 14 Feb 89 22:56:00 EST Subject: Analog and Digitial Schematic Design Software E L E C T R O N I C M A I L (DDN Host Address: ESDVAX.ARPA) Date: 14-Feb-1989 10:56pm From: Capt Krishna Narayan Username: NARAYAN Dept: HQ ESD/SRR Hanscom AFB Tel No: (617) 271-5067 TO: _MAILER! ( _DDN[386USERS@TWG.COM] ) Subject: Analog and Digitial Schematic Design Software I have recently purchased a 386 system and am very interested in learning about available S/W to accomplish schematic design/layout. So far all I have been able to find is something called "Tango Schematic" from a company called Accel Technologies in San Diego. I know there must be lots of packages around. Could someone provide me with recommendations and sources for purchase? ~kn ------------------------------ Date: Fri, 10 Feb 89 08:22:58 PDT From: steinmetz!uunet!relay.cs.net!kds@mipos2.intel.com Subject: 386 Caches for the 386 mailing list I believe the reasons that you find 64k direct mapped caches on 386 systems is that the technology available in high-speed static RAMs (16k x 4) matches this size of cache. The reason you see 32k two-way set associative caches on 386 systems is that this matches the size and configuration of the cache that is supported by the Intel 385 cache controller. With regards to how the caches support writes from peripheral devices, the 385 supports "snooping," wherein anytime a write happens anytime in the system aside from the 386, the address is looked up in the tag array, and if that location is resident in the cache, it is invalidated. This forces any subsequent 386 access to that memory location to go to the latest entry in main memory. I'm not sure about all the discrete implementations (i.e., 64k direct mapped caches), but one technique that I have seen requires that all writes in the system go through the cache in parallel with main memory. While this works, it requires more cache bandwidth than in the 385 case, which means that the 386 is denied access to its cache more often, which can hurt overall system performance. Of course, which choice is "best" depends on the load on the machine. Overall, both techniques seem to provide roughly equivalent performance. As to whether caches provide a performance boost to zero wait state systems, well, again, it depends on the load. If you have a large amount of DMA-type I/O going on, then the cache can operate in parallel with main memory in providing the 386 memory access while the rest of the memory system is tied up doing the I/O access. In addition, the cache will insulate the 386 from lapses in memory access during DRAM refreshes. But, again, in general, I don't believe that it would make that much of a difference in a PC. But the question is really academic. With 386s (and microprocessors) getting faster and faster, it is getting to be difficult to make large memory arrays that can keep up with the processor. Ken Shoemaker ------------------------------ From: steinmetz!uunet!relay.cs.net!jeremy@jeremy.prime.com Date: Mon, 13 Feb 89 8:41:53 EST Subject: Dos and unix, hypertext, disk controllers I am interested in running multiple dos sessions on a 386 box and one or two unix sessions to tie them together. Among the available products are: 1. xenix + vp/ix 1.1 2. microport unix + locus dosmerge 3. interactive's 386/ix + vp/ix I will also need tcp/ip software(smtp would be nice to have with this), and nfs. Have I left anyone elses product out? (enix doesn't have any ms-dos session capability) I want to be able to use some pc hardware, such as a fax board and a voice board, while using a dos window under unix. Does anyone have some comments about this (past or present experience, or theoretical)? Does anyone have any experience and or suggestions about which vendor's os is "better" (e.g. gives me a better chance of doing most of what I want to do)? Also, we are looking at high performance disk controllers. Does anyone have any experience with the wd controller which include floppy, scsi and esdi capabilities on one board? Any comments about scsi vs. esdi? I am also looking for hypertext capabilities under unix and/or pc-dos. Are there any products or source code out there? Thanks. -- Jeremy Nussbaum jeremy@jeremy.prime.com, ...!harvard!prmcad!jeremy Prime Computer ------------------------------ Date: Mon, 13 Feb 89 02:39:31 EST From: Stefan Mochnacki Subject: Re: Merge386 - Mixing DOS and UNIX (on serial lines ...) Adam Lewis writes: > recently wrote about problems he was having >using the serial port from inside Merge/386 under Microport SysV/386. >Merge/386 is not alone in this behavior. The VP/ix based SunView >DOS Windows system has similar problems on Sun's 386i boxes. This .... I heard a funny story a while ago, and I hope it's dead wrong. The story was that Microsoft required Sun to disable use of DOS over serial ports, but remote use from other workstations was OK. Over the network, using PC-NFS one can run DOS jobs not requiring any screen mapping (e.g.compilers). Does Microsoft not want multi-user use of MS-DOS using terminals ? bill@cosi.UUCP (Bill Michaelson) writes: >I'm running the Merge386 product under Microport UNIX. I think it's a good >product generally, ... Yes, there are commercially-available versions of VP/ix and DOSMerge which DO have screen mapping, and after all there are DOS --> terminal or DOS --> DOS programmes such as PC-Anywhere which have screen mapping. Does anyone have the real dope on this issue ? (Something to do with Microsoft's licensing of the "re-director" ?) Stefan W. Mochnacki INTERNET - stefan@helios.physics.toronto.edu Astronomy, U. Toronto UUCP - {uunet,pyramid}!utai!helios!stefan +1 (416) 884-9562 BITNET - mochnacki@utorphys.bitnet ------------------------------ Date: Sat, 11 Feb 89 12:33:46 EST Subject: Re: 80386 mailing list, vol 4 #1 Reply-To: uunet!ut.toronto.edu!lee%anduk.co.uk From: Liam Barefoot > From: tom@dvnspc1.UUCP (Tom Albrecht) > Subject: Using a Hayes-type modem with System V/386 > Date: 22 Nov 88 22:18:56 GMT > > We are having trouble hooking up a Hayes-compatible modem to a 386-based > system running System V.3. In order to get Unix to send the dial codes to > the modem, carrier detect must be forced high from the modem (i.e. AT&C0). > With this setting we are unable to actually detect when the modem looses > carrier from the remote system. 'sh' ends up staying around and 'getty' never > gets respawned for the line. > > Any suggestions as to how we can talk to the modem and detect remote carrier? > > Thanks! If you have BSD source available, use V7 or BSD uucp. In Europe there's something called ukuucp which is a derivative, and which also works. We get the advantage of a factor of four savings in cost, too. Here's why it works... If you open a port (e.g. from a C program), your process will hang until Carrier Detect is asserted by the device, as you discovered. But if you open the port with the O_NDELAY flag, your process will not hang, and CD is ignored on open. Unfortunately, there is a common SysV bug present in V.2.4 on a Honeywell Bull machine here and also on 386/ix 1.0.6, for example. This bug is that after the last process that was using the port closes the associated fd (directly with "close" or indirectly via "exit"), the Unix system is supposed to drop DTR --- but often doesn't, or does so only after a few seconds. So although you can get uucp working OK, the phone bills are a little high as you don't always ring off! I use the enclosed program to call uucico from cron, but it still doesn't quite work properly with uugetty, because as soon as uucp has opened the line, uugetty seems to be able to do so, too -- which is a bug. Sigh. If you use a Hayes modem, though, and if you uucp supports L.disconnect (as does ukuucp, for example), you can put the modem disconnect sequence in your L.disconnect file. But all this is a little ugly! If anyone has an elegant fix (we don't have 386/ix source), I'd love to hear about it! As to the cost... ukuucp and BSD uucp support `f' protocol as well as `g'. With `f', you get per-file error checking, adequate over a good link. We use our modem only to go to an X.25 PAD, so there are few errors, which is fine. Then, there is much less packet overhead, so it goes faster. Now, `g' proto sends acknowledgement packets back to the sender. So we pay for sending the data packet *and* for receiving the ack. packet! The charge for X.25 is per packet + transmission time, not per byte. So with `g' proto we halve our costs because of no ack packets, and we get a near doubling of throughput. So we don't use 386/ix uucp! fio (the part of uucp that does `f' proto) is available as public domain source, and there are public domain uucp clones. Hope that helps. Lee. /* fakeuucico.c */ #include #include #include #include int caughtsig = 0; /* hack to get uucp working --- Lee Barefoot, Unixsys (UK) Ltd, 1988 */ int catcher() { caughtsig++; /* You might want to delete this if you're running from cron */ fprintf(stderr, "**** caught alarm\n"); } main(argc, argv) int argc; char *argv[]; { int fd; (void) signal(SIGHUP, SIG_IGN); (void) signal(SIGCLD, SIG_IGN); switch (fork()) { case -1: fprintf(stderr, "%s: can't fork\n", argv[0]); exit(1); case 0: /* child */ argv[0] = "uucico"; execv("/usr/lib/uucp/uucico", &argv[0]); fprintf(stderr, "fakeuucico: Can't exec /usr/lib/uucp/uucico\n"); exit(2); default: /* wait for uucico, uuxqt & uux to finish: */ (void) wait((int *) 0); /** fprintf(stderr, "**** fakeuucico about to kick line\n"); **/ break; } fprintf(stderr, "fakeuucp: about to try to clear the line\n"); for (;;) { extern int errno; (void) signal(SIGALRM, catcher); (void) alarm((unsigned) 3); errno = 0; /* CHANGE ME */ fd = open("/dev/tty16", O_RDONLY, 0); /** fprintf("**** got %d, e %d\n", fd, errno); **/ if (errno == EINTR && caughtsig < 2) { /* alarm went off */ break; } caughtsig = 0; sleep (1); (void) close(fd); } exit(0); } -- Lee Barefoot, Unixsys UK Ltd, uu.warwick.ac.uk!anduk.co.uk!lee The Genesis Centre, Birchwood, {ai.toronto.edu,utzoo!utai}!anduk!lee Warrington, ENGLAND, WA3 7BH Tel. +44 925 828181, Fax 827834 ------------------------------ Subject: Re: Request for help on Intel microarchitectures Date: Wed, 15 Feb 89 23:55:20 PST From: cire|eric In Volume 4, #4, Bill Beebe responds to Any Tanenbaum's request for information on Intel's Microarchitecture for the 80x86 family. In the world of PCs and "micro" computers it is interesting the confusion when folks talk micro-computers and micro-architecture. The later is also often refered to as micro-coded architecture. I'll try to explain the difference. Anyone who has programmed a micro-computer in assembly language is familar with the machine at a pretty low level. However in micro-coded machines there is yet another level even deeper. Think of a simpler faster machine that is used to implement the instructions that we are used to programing when at the assembly level. This is the micro-machine. Essentially, the micro-machine when executing the microinstructions is interpreting the assembly code. Most modern CISC architectures (most microcomputer chips fall into that category) are implemented as micro-coded machines. How they are actually organized internally is refered to as their micro-architecture. When looking at a micro-coded machine from the outside, this level is refered to as the macro-machine. The interesting features of the macro-machine are the instruction set, how instructions and data are referenced, and similar things. It is the micro-architecture and the micro-program that determines many of these characteristics not to mention being fundatmental to the perforamance of the machine. The manual set that Bill so kindly offered to send Andy describes the macro-world of the Intel micros. However what Andy was asking for was the micro-world. In fact I would be very surprised if Andy didn't already have the Intel manuals that Bill was talking about. Andy is the guy who is responsible for MINIX. The original implementation was done for an IBM PC (8088). I suspect that what Andy is asking for is probably Intel proprietary. However, I'll ask around and see what I can come up with. I have a friend who has a friend (:-)) that works in Intel at Aloha, OR. I don't know what they are doing up there these days but that's where they did the 432. Too bad it was so slow. >From Andy's original: >>I called up Intel's headquarters ... >>I then asked for the Engineering department/division, and was told there >>was none. Some folks have been saying this for years! :-) So Intel has finally admitted it. Interesting. -c cire|eric Eric B. Decker Menlo Park, California email: cire@cisco.com I speak for myself. Other people's mouths won't fit on my face and would probably look weird anyway. ------------------------------ From: dlp@gistdev.UUCP Subject: Re: Gateway 2000 386 VGA Experience Date: 13 Feb 89 23:58:00 GMT => Written 3:27 pm Feb 10, 1989 by linus.UUCP!lever = >/* ---------- "Gateway 2000 386 VGA Experience" ---------- */ => I need some help from the net. I have been contemplating the purchase => of a computer for some time now and have seen ads for the Gateway 2000 => computers in many of the magazines. I read the review of affordable => 386s in the October issue of BYTE that put Gateway on top despite some => shortcomings (I have read subsequently that they have corrected the 16 => MHz part problem though). Their prices seem outstanding and the => quality and performance are probably not far behind but before I can => shell out $4,000.00 for anything I need to hear from someone who => already has. I have a '386 VGA from Gateway 2000, and now that we've ironed out a few problems, I'm happy with it. I got the 20MHz with 4M of 100ns SRAM, 80M Seagate, a Paradise Plus 16 VGA card and Samsung multisync monitor, 101-key so-called 'enhanced' keyset with switchable ctrl/capslock key. Total cost was $4592 including shipping (and the 4m memory). I've heard they now ship NEC multisync monitors instead. The problems were: 1. The keyset they sent originally failed diagnostics after about two hours of use, leaving the whole system unusable until it was replaced. UPS took three weeks to ship the replacement keyset 200 miles, and the second keyset Gateway sent (via next-day air) was not the switchable type, so I ended up paying shipping to return 3 keysets to them. (Not much money, and they are paying for all phone calls, so we're even.) 2. They sent it with a short monitor cable, so I am constrained to place the tower back by the wall and the monitor at the edge of the desk, not in the convenient locations they should be. Gateway wants another $10 plus shipping for a monitor extension cable that I expected to be part of any reasonable tower configuration. I'll probably buy it locally just to spite them. 3. Gateway originally sent a Vega VGA card (an 8-bitter) installed, along with the documentation for both the Vega and the Paradise cards. When I complained about not getting the card I ordered, they sent the Paradise 16 and said I could try them both and send back the one I didn't want. (Two guesses which one I returned.) 4. I had to low-level format and mark the bad sectors on the hard disk for myself, which eliminated intermittent "hard disk failure" errors I got the first day. I have had no disk problems since. Other than that, I've been very pleased with the whole system. I used it at the office for 6 weeks and finally took it home. The Samsung monitor performs flawlessly, the disk is fast and quiet, it looks good, runs fast, (not going to quote any numbers, since "your mileage may vary" anyway), and does everything I want it to do. * * * * * * * * Dirk Pellett (217) 352-1165 INTERNET: dlp%gistdev@uxc.cso.uiuc.edu UUCP: {uunet,pur-ee,convex}!uiucuxc!gistdev!dlp ------------------------------ From: peter@csd4.milw.wisc.edu (Peter J Diaz de Leon) Subject: Co-Processor Board Info Date: 15 Feb 89 18:58:26 GMT I friend of mine which does not have net access asked me to find out if it is possible to purchase a 80387 card of some sort that will plug into his 80287 socket. He owns a machine called a PC Value 80386. Please e-mail me. If there is enough interest I will summarize to the net. Thanks Peter ============================================================================== ARPA: peter@csd4.milw.wisc.edu USMAIL: Peter J. Diaz de Leon peter@uwm-cs.milw.wisc.edu 7411 W. Warnimont Ave. Milwaukee, WI. 53220 UUCP: {harvard|rutgers|ucbvax}uwvax!uwmcsd1!uwm-evax!peter ICBM: 43 4 58 N / 87 55 52 W ============================================================================== ------------------------------ End of 80386 M/L ****************