NU013809@NDSUVM1.BITNET (Greg Wettstein) (09/26/89)
I am in the process of updating a terminal emulator that we use extensively
in house under VPIX. As long as I am going to have the async. drivers taken
apart I was thinking about adding support for the 16550A.
I have been looking around for a source for a couple of these chips but have
not been successful. I know that about 8 months ago someone on the net was
advertising single quantities from a large stockpile they had purchased but
I have not heard anything about this since. If anyone has any information
about sources or has a couple they would like to part with please contact me
either through mail or via the net. I would also be interested in locating
any and all information on the technical aspects of programming this device.
From my understanding of the subject it is possible for application software
to 'sense' the presence of a 16550A and enable the FIFO's. I gather from his
documentation that Chuck Forsberg of Omen does this with this DSZ and YAM
packages.
So if anybody has source or technical information on the 16550A I would be
eager to hear from you. When I get 16550A support into the emulator I will
advise the net if I see any performance changes running under DOS/VPIX.
Once again thank you to everyone for offering an attentive ear(eye).
As always,
Dr. Greg Wettstein
NU013809@NDSUVM1johnl@n3dmc.UU.NET (John Limpert) (09/28/89)
In article <2834NU013809@NDSUVM1> NU013809@NDSUVM1.BITNET (Greg Wettstein) writes: >I have been looking around for a source for a couple of these chips but have >not been successful. You can buy them from JAMECO Electronics in small quantities. JAMECO advertises in many computer and electronic magazines. -- John A. Limpert I'm the NRA! Internet: johnl@n3dmc.UU.NET UUCP: uunet!n3dmc!johnl
cliffhanger@cup.portal.com (Cliff C Heyer) (10/02/89)
Karl Denninger Writes... >In article <22542@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >>Hopefully the Mylex will give 386 land the >>*first* board that gives 900KB/sec disk I/O >>like the Amiga (at Amiga prices hopefully) > >That's funny... > >The WD1007/WA2 has been clocked here at 950KB/second (ESDI 10 Mhz). I >understand that the WD1008 (15Mhz ESDI) has been clocked at over >1300KB/second, although I haven't seen that one myself. The DPT boards >have been clocked at that rate (950KB/sec) on cache misses. On cache >hits the DPT board is off the top of scale on our tests; that is in >excess of 4MB/sec! Michael Umansky Writes... >In my 25Mhz Micronics with 8Mhz AT bus and Adaptec AHA-1542A SCSI controller >and CDC WREN III SCSI drive I get about 900 KB/sec. The Mylex controller >should deliver at least a magnitude more to be cost effective. Cliff Heyer Responds... I became interested in speed when I was asked to evaluate porting VAX applications to IBM PC/compatible micros. During my analysis & testing, I found the MIPS more than adequate in PC land, but disk I/O was the problem. The VAX ranges from 600KB/sec to 1.3MB/sec tops sustained I/O *per job*. Many PCs I tested got in the range of 200KB/sec (ST-506 ...). Then I found to my surprise that SCSI & ESDI disks on many machines was still 200-300KB/sec! This was confirmed by checking BYTE benchmarks that list 1MB throughput times. SUN was the only machine in BYTE that showed a respectable 800KB/sec time. It has become evident to me that in spite of 15MHz ESDI chips, sync SCSI, etc. certain machines still go as slow as their ST-506 counterparts. Also, unlike the old mainframe days when computer were rated in actual disk I/O in KB/sec, todays micros are sold with NO ratings, except the "chip throughput" ratings which are meaningless because they do not show what the actual throughput is. So I have no way to know if the machine I want to buy has 900KB/sec I/O, except from USENET. The sales people won't tell you anything. It seems that disk I/O is a big secret, all they want you to think about is MIPS. You are provided with NO information with which to make an informed configuration decision. As soon as you do some disk benchmarks you have to sign a non disclosure agreement. As a result, I have developed a somewhat cynical view that these companies have a vested interest to saturate the market with slow I/O hardware, knowing that you will grow and later have to buy more hardware to get the 900KB/sec. Why sell you a better mousetrap if people are happy buying the old one? I'm hoping that if I am wrong, someone will be able to give me a convincing argument otherwise. Cliffhanger@cup.portal.com PS did any of you "shop" for 900KB/sec? If so, how did you establish this speed actually was possible before you bought?
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/04/89)
In article <22709@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes: | I'm hoping that if I am wrong, someone will be able to give me a convincing | argument otherwise. How about a few facts? A) typical ESDI drives (looking a a recent spec sheet) turn 3600 rpm, have 32 sectors of 512 bytes. 32*512*60/1024 = 960kb max from ESDI, no allowance for latency, step time, etc. B) I measured the ballpark i/o of several machines by doing a dd of the raw device to /dev/null. Crude, but it shows about 600kb for my ESDI system, the same for my RLL system, about 500kb for a microvax 3500 (Ultrix) and about 700 for a Convex C220. C) Looking at the loading on a small number of Suns, 386s, and one MicroVAX, I conclude that most processes which are not doing terminal i/o are CPU bound, and that "wait for i/o" is only 20% of the total clock time to run. I had to check this with several tools, so results are not perfect. From this set of reasonably useful numbers I would suggest that you could look for a less demanding solution in any of the following areas: is your application really transfer rate bound? Do the figures you quoted for other machines reflect actual performance, benchmark performance, or hardware limits? Are you asking for something which isn't being marketed? The only thing you implied with which I disagree is the implication that people will grom out of 386 type systems in the i/o end. I really don't believe that's typical of the usage I've seen. Adding memory to avoid page/swap and provide buffering seems to keep the i/o going long after the CPU cycles are gone. This obviously depends on usage, but I think the loads I see are typical (a mail gateway, development machine, and general office automation). Good luck in finding something which will run your application. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
karl@ddsw1.MCS.COM (Karl Denninger) (10/04/89)
In article <22709@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >Karl Denninger Writes... >>That's funny... >> >>The WD1007/WA2 has been clocked here at 950KB/second (ESDI 10 Mhz). I >>understand that the WD1008 (15Mhz ESDI) has been clocked at over >>1300KB/second, although I haven't seen that one myself. The DPT boards >>have been clocked at that rate (950KB/sec) on cache misses. On cache >>hits the DPT board is off the top of scale on our tests; that is in >>excess of 4MB/sec! > >Michael Umansky Writes... >>In my 25Mhz Micronics with 8Mhz AT bus and Adaptec AHA-1542A SCSI controller >>and CDC WREN III SCSI drive I get about 900 KB/sec. The Mylex controller >>should deliver at least a magnitude more to be cost effective. > >Cliff Heyer Responds... >I became interested in speed when I was asked to evaluate porting VAX applications >to IBM PC/compatible micros. During my analysis & testing, I found the MIPS more >than adequate in PC land, but disk I/O was the problem. > >The VAX ranges from 600KB/sec to 1.3MB/sec tops sustained I/O *per job*. Many >PCs I tested got in the range of 200KB/sec (ST-506 ...). Then I found to my >surprise that SCSI & ESDI disks on many machines was still 200-300KB/sec! >This was confirmed by checking BYTE benchmarks that list 1MB throughput times. >SUN was the only machine in BYTE that showed a respectable 800KB/sec time. Huh? 1.3MB/second per job, eh? With what interface? And to how many jobs? We install, service, upgrade and work on VAX systems all the time, and I've >never< seen one which can sustain 1.3MB/sec (bytes now, not bits) across more than one or two jobs! Now, there are exceptions I'm sure. A big Vaxcluster with multiple spindles and controllers, perhaps. The typical 3xxx (or MVII) series machine with ESDI or SCSI interfaces and a couple of drives? No way! Wanna buy a 4 million dollar system? Sure, I can provide what you want, to many jobs. It'll cost you about what most companies earn in a year! >It has become evident to me that in spite of 15MHz ESDI chips, sync SCSI, etc. >certain machines still go as slow as their ST-506 counterparts. Also, unlike >the old mainframe days when computer were rated in actual disk I/O in KB/sec, >todays micros are sold with NO ratings, except the "chip throughput" ratings >which are meaningless because they do not show what the actual throughput >is. I don't know where you're coming from, or where you get your hardware, but there is no way that I can agree with this. Sure, some OPERATING SYSTEMS can't keep up. That's true of VMS too, you know. 386/ix, in particular, is supposed to be a real screamer (we don't use it here for completely different reasons related to support). SCO isn't quite as fast as the hardware; I'd admit that I have a darn hard time getting better than 400KB/sec out of Xenix through the raw I/O interface. That is something that needs to be taken up with the software vendor. Every one of our RLL-based machines can do in the area of 700KB/sec raw I/O. Every one of our ESDI-based machines can do in the area of 900KB/sec. What is lost in the OS is another story, but that's something we don't have control over! If we sell a 386 system with an RLL interface, you can bet we'll guarantee that the raw I/O rate, measured with something like CORETEST (gotta define the benchmark in order to be meaningful), is from 630-700KB/sec. ESDI drives are faster, we normally measure throughputs in the area of 900KB/sec. Every machine IS checked for transfer rate before it leaves the building. No, you can't do this with cheap and slow hardware. You certainly CAN with fast and a little more expensive components. >So I have no way to know if the machine I want to buy has 900KB/sec I/O, >except from USENET. The sales people won't tell you anything. It seems that >disk I/O is a big secret, all they want you to think about is MIPS. You are >provided with NO information with which to make an informed configuration >decision. As soon as you do some disk benchmarks you have to sign a non >disclosure agreement. As a result, I have developed a somewhat cynical view that >these companies have a vested interest to saturate the market with slow I/O >hardware, knowing that you will grow and later have to buy more hardware >to get the 900KB/sec. Why sell you a better mousetrap if people are happy buying >the old one? Why not buy from someone who does bother to check these things, and can tell you exactly what you're getting? Are you expecting to get this kind of service (yes, it IS a service) from the "cheep" mail-order places? You got to be kidding! Buy from a place that knows what they're doing, a VAR (which is exactly where you would have to go to get a SUN or DEC, unless you buy from the manufacturer at full list!), and you will be able to get that information. In writing if you require it. Your vendor(s) won't do that? Switch vendors. We're out here (and I'm sure we're not the only ones). >I'm hoping that if I am wrong, someone will be able to give me a convincing >argument otherwise. You just got one. >Cliffhanger@cup.portal.com > >PS did any of you "shop" for 900KB/sec? If so, how did you establish this >speed actually was possible before you bought? -- 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"
larry@nstar.UUCP (Larry Snyder) (10/05/89)
> Sure, some OPERATING SYSTEMS can't keep up. That's true of VMS too, you > know. 386/ix, in particular, is supposed to be a real screamer (we don't > use it here for completely different reasons related to support). SCO isn't Have you done any benchmarks with SCO Unix 3.2? > quite as fast as the hardware; I'd admit that I have a darn hard time > getting better than 400KB/sec out of Xenix through the raw I/O interface. > That is something that needs to be taken up with the software vendor. What utility are you using to benchmark disk I/O under Xenix? > Every one of our RLL-based machines can do in the area of 700KB/sec raw I/O. Using which WD controller? > If we sell a 386 system with an RLL interface, you can bet we'll guarantee > that the raw I/O rate, measured with something like CORETEST (gotta define > the benchmark in order to be meaningful), is from 630-700KB/sec. ESDI Every 2372 I've seen bench outs between 650-690KB/sec. Why the WD over the 2372? -- Larry Snyder uucp:iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Site 4 high speed lines (PEP/HST/V96/V.42) Notre Dame, IN USA 219-287-9020
keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (10/06/89)
In article <22709@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >Michael Umansky Writes... >>In my 25Mhz Micronics with 8Mhz AT bus and Adaptec AHA-1542A SCSI controller >>and CDC WREN III SCSI drive I get about 900 KB/sec. The Mylex controller >>should deliver at least a magnitude more to be cost effective. > >Cliff Heyer Responds... >I became interested in speed when I was asked to evaluate porting VAX applications >to IBM PC/compatible micros. During my analysis & testing, I found the MIPS more >than adequate in PC land, but disk I/O was the problem. > >The VAX ranges from 600KB/sec to 1.3MB/sec tops sustained I/O *per job*. Many >PCs I tested got in the range of 200KB/sec (ST-506 ...). Then I found to my >surprise that SCSI & ESDI disks on many machines was still 200-300KB/sec! Around here we use the CORE27 as our reference test; it seems to be pretty accurate on the machines we can measure with other schemes and we hope it extrapolates to the faster drives. Anyway, using CORE27 to test an Everex STEP/25, a WD 7000ASC and a CDC WREN IV (? 300 Mbytes) I got 1.04 Mbytes/sec. That was some time ago, however, and I've abandon that configuration. I'm currently trying to get an Adaptec 1542A connected to a CDC WREN VI (? 600 Megabyte) into my STEP/25. But I have to wait for some PAL upgrades for the STEP/25 because it doesn't "work and play well" with the 1542A's bus-master DMA scheme... In the meantime I've installed the 1542A and CDC drive into an Intel 301 to get the drive configured and my files loaded onto it while I await the PALs. Using CORE27 on the Intel 301, Adaptec 1542A and CDC combination I get 1.4+ Megabytes per second reported. When (if?) I get it working in the STEP/25 I'll let you know how things go (the Intel 301 is a 16 MHZ processor and 8 MHz bus; the STEP/25 is set up for 8.33 MHZ bus). This is with no caching program loaded. kEITHe
keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (10/06/89)
In article <765@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: > >B) I measured the ballpark i/o of several machines by doing a dd of the >raw device to /dev/null. Crude, but it shows about 600kb for my ESDI >system, the same for my RLL system, about 500kb for a microvax 3500 >(Ultrix) and about 700 for a Convex C220. Bill - Have you tried dd'ing _to_ the drive to see what it's write rate is? We've found there to be an AMAZING (ly disappointing) difference betwixt read & rite rates! kEITHe Help Stamp Out Fascist News Posting Software ! ! !
dougp@ico.ISC.COM (Doug Pintar) (10/06/89)
I am running a Compaq 386/20 with 300MB ESDI drive and WD-1007WA2 controller. Under 386/ix 2.0.1, I've written a small program that just does writes from a buffer to a file. Using 121856-byte buffers for the RAW disk (7 tracks @ 34 sectors/trk, largest number of physical tracks you can fit in a single controller read request), I get WRITE rates of 828KB/sec. Using 'dd' from the RAW disk to /dev/null with the same size buffers I get READ rates of 810KB/sec. Using 1KB buffers to write to a file in the filesystem, I get WRITE rates of between 262KB/sec and 338KB/sec, depending on fragmentation of the free blocks (this is for an 8MB file). Using 'dd' from a file to /dev/null with 1KB buffers, I get READ rates of 368KB/sec to 413KB/sec, again depending on fragmentation. I've got a lot of memory, so I'm using 1500 filesystem buffers (NBUF in configuration) and 512 hash slots for those buffers (NHBUF in configuration). NOTE: The WD-1007WA2 is an interrupt-per- sector, PROGRAMMED I/O device. Using an Adaptec 2320 ESDI controller on the same machine, I get slightly higher rates. The 2320 has no track read-ahead cache, but it is faster at getting commands started. The cache is pretty meaningless on large transfers, and even through the filesystem, 386/ix tries to move a track or two at a time. I once tried reading and writing to BOTH controllers simultaneously, (RAW devices, big buffers) and got aggregate throughput of around 1.2MB/sec. At this point, the CPU gets swamped transferring data and processing interrupts. Roy Neese at Adaptec once claimed multi-drive aggregate throughput for an AHA-1542 SCSI Adapter of 2.2MB/sec. Since this device uses first-party DMA and imposes very little host overhead, I'd believe it. I've never had the opportunity to use it with multiple, fast drives, but I see no reason that the 386/ix driver for the board should hold it up. The real problem with disk transfer on AT-bus (and MCA as well, for that crowd) is NOT bus bandwidth but lousy controller design. PIO controllers are cycle hogs, and most DMA controllers DON'T SUPPORT SCATTER/GATHER! This makes transfers to/from physically-discontiguous memory pages very inefficient. To my knowledge, ONLY the Adaptec 1542 (and its MCA equivalent) supports scatter/gather (up to 16 addresses and counts can be passed). Performance of the 386/ix HPDD for that adapter MORE THAN TRIPLED when I enabled code to utilize this capability. DLP
karl@ddsw1.MCS.COM (Karl Denninger) (10/07/89)
In article <111044@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >> Sure, some OPERATING SYSTEMS can't keep up. That's true of VMS too, you >> know. 386/ix, in particular, is supposed to be a real screamer (we don't >> use it here for completely different reasons related to support). SCO isn't > >Have you done any benchmarks with SCO Unix 3.2? Not yet. We haven't loaded it on our machine here as of yet, since we don't have a copy for ourselves. >> quite as fast as the hardware; I'd admit that I have a darn hard time >> getting better than 400KB/sec out of Xenix through the raw I/O interface. >> That is something that needs to be taken up with the software vendor. > >What utility are you using to benchmark disk I/O under Xenix? "dd" to/from a raw and cooked (block) partition. About as accurate as you can get for sequential I/O. Random I/O is of course going to be worse, as you need to also seek the heads in that case. The sequential checks have been made over several megs of data to make sure we're averaging out any possible inconsistancies from run to run, and are done on a quiet system (single-user mode when possible). >> Every one of our RLL-based machines can do in the area of 700KB/sec raw I/O. > >Using which WD controller? WD1006V/SR2. No problem at all. We consistantly hit 650-700KB/sec. If you don't then your controller or machine is broken (ie: too many wait states on the bus!) or was incorrectly formatted. Some of our newer motherboards have been showing up with around 630KB/sec. I got upset with this number; it's too low. Investigation showed that these boards had a Phoenix BIOS in them without the settable I/O wait states (aha!). A BIOS swap (for AMI) and re-configuration fixed 'em. 630KB/sec isn't bad! 680 is better though :-) >> If we sell a 386 system with an RLL interface, you can bet we'll guarantee >> that the raw I/O rate, measured with something like CORETEST (gotta define >> the benchmark in order to be meaningful), is from 630-700KB/sec. ESDI > >Every 2372 I've seen bench outs between 650-690KB/sec. Why the WD over the >2372? With XENIX? The ACB2372 we have here right now does ~100KB/sec with SCO Xenix. That's terrible, and is one reason we use the WD1006 series over the Adaptec. The WD series also has better ECC capability demonstrated on the bench, it can recover data from marginal drives that the Adaptec will error out on. As an example, we have one ST4144 right here in the shop that shows ~30 errors with our diagnostic software using the WD1006, and some 200 (!) errors on the >same< drive using a 2372. This is a shop drive; I'd never put that thing in a box for a customer, but it does demonstrate the superior data recovery abilities of the WD card. Adaptec claims to have the best data separation capability; they're full of hot air. Our actual field tests don't bear out their claims. You know which board I'm going to trust my data to given a choice, don't you? There is little difference under MSDOS in speed. Under Xenix the performance is worlds apart. The data recovery bonus is icing on the cake. -- 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"
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/11/89)
In article <6075@tekgvs.LABS.TEK.COM>, keithe@tekgvs.LABS.TEK.COM (Keith Ericson) writes: | | Have you tried dd'ing _to_ the drive to see what it's write | rate is? We've found there to be an AMAZING (ly disappointing) | difference betwixt read & rite rates! No, and unless someone gives me a machine which needs the disk reloaded I won't. Doing a dd to the raw device assures that the data are contiguous, but writing to a raw device is a good way to leave a very dead filesystem. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
jiii@visdc.UUCP (John E Van Deusen III) (10/11/89)
In article <982@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: > ... writing to a raw device is a good way to leave a very dead > filesystem. It is a good idea never to write over the VFIB information stored in block 0 of a hard disk. It might require invoking some very obscure utility to get it back; something more obscure than mkfs, possibly involving a lengthy and totally destructive disk format. When you make a file system you specify a parameter BLOCKS that is the desired size of the file system. If the amount specified is less than the space actually available on the device, then the extra space can be used for raw I/O. Of course, there is no requirement to have any file system on the device at all, thus making the entire device, except for block zero, available. All this requires that the program doing raw I/O is smart enough to offset any useful information stored on the the device. Anything like myprog > /dev/smd0.0 is, as Mr. Davidsen says, certain doom. That said, I will bet that at least one person reading this has a special file in /dev, associated with a file system, that is writable (readable) by everyone! -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
spencer@necis.UUCP (John Spencer) (10/12/89)
In article <16173@vail.ICO.ISC.COM> dougp@ico.ISC.COM (Doug Pintar) writes: >The real problem with disk transfer on AT-bus (and MCA as well, for that >crowd) is NOT bus bandwidth but lousy controller design. PIO controllers >are cycle hogs, and most DMA controllers DON'T SUPPORT SCATTER/GATHER! This >makes transfers to/from physically-discontiguous memory pages very inefficient. Could someone tell me where I can get more information on understanding PIO controllers -vs- DMA controllers supporting and not supporting scatter/gather. Any information would be extremely helpful.