Date: Mon, 8 Sep 1997 14:29:46 +0930 From: Greg Lehey <grog@lemis.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: FreeBSD Chat <chat@FreeBSD.ORG> Subject: Re: lousy disk perf. under cpu load (was IDE vs SCSI) Message-ID: <19970908142946.45138@lemis.com> In-Reply-To: <XFMail.970907214856.Shimon@i-Connect.Net>; from Simon Shapiro on Sun, Sep 07, 1997 at 09:48:56PM -0700 References: <19970907171110.27847@lemis.com> <XFMail.970907214856.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 07, 1997 at 09:48:56PM -0700, Simon Shapiro wrote: > > Hi Greg Lehey; On 07-Sep-97 you wrote: > > ... > >> Well, I can't remember the performance of the mid-70s, but my >> recollection of the performance in the early 80s on, say, a 3330 clone >> was that these drives had 30 sectors (2 spares) per track, and they >> ran at 3600 rpm. Since they weren't buffered, that gives a maximum >> data transfer to the channel of about 860 kB/s. Average positioning >> was round the 30 to 35 ms mark. > > Check out Priam 14" 60MB drives, I'd guess they'd be pretty close to the others. > check Floppy drives from the early 80's. They were all much faster > than that. I clearly remember my Heathkit H8 seeking at 5-7ms on a > 5.25" floppy. That's the track to track time. My Siemens 8" jobs even did 3 ms. But those were stepper motors, and a 77 track seek took 230 ms. >> At the time, I was working for Tandem. We noticed a puzzling >> behaviour: our new flagship model TXP, whose CPU was about 100% faster >> than the previous NonStop II, read data off these disks at almost >> exactly double the speed of the NonStop II. Why? We finally figured >> out that we were reading 4 kB blocks (the maximum our disk controllers >> would allow), doing some processing, and then issuing the next read. >> Unfortunately, on the NonStop II this took such a long time that the >> head had passed the next block before it issued the read. In other >> words, the "high performance" TXP managed to read a 4 kB block every >> revolution, and the NonStop II needed two revolutions per 4 kB block. > > This is called inteleave factor. Interleaving might have improved the performance of the NonStop II, but it would have worsened the performance for the TXP. > The semantics for 4.2bsd mkfs supported that feature. My CPM 1.1 > IMSAI BIOS supported that on a floppy drive. CP/M's interleaving was broken. He did it by reading non-sequential sector numbers rather than laying them out as the controller could handle them. > We did, on a Z-80 machine of my design 256KB/sec from a single hard > disk. Vax-780 did over 500KB/Sec in that time frame. That's a whole lot slower than the 3330 I was talking about. But they're burst rates. Look at the old (pre-FFS) UNIX file system and check how fast *that* was. > We always knew Tandem was turtle slow. I finally have a witness to > why No, I didn't say why. I just confirmed your prejudices :-) > On the original Tahoe, we complained about 780KB/Sec and striped it to > get more data out of it. > > ... > >> Again, I can't agree in the slightest. I *do* have the technical doc >> for a 2311 drive floating around somewhere in the shed, and they were >> unbelievably primitive. > > I may not remember some of the old numbers, but it is a rather well > established fact that the difference in performance between CPU and > external storage grows rapidly. My point was to exemplify it and > encourage the young (at heart) and energetic to think in new ways. > > ... > >> Sounds like a 1 GB RAM to me. Still cheaper per byte than any disk >> made up to about 5 years ago. > > Not necessarily so. What you refer to is DRAM, which loses its mind > if not read in 2ms. So refresh it. > Not exactly long term storage. ``Permanent'' storage is stil > important. Remember that RAM was born as a compensator to off-line > storage slowness. Well, no, RAM was born as a cheaper alternative to core. So, for that matter, were disks and drums. > Originally there was a store and there were registers. Originally there was no store. > RAM really is a non-entity from architectual point of view. Huh? > It is a headache, that is true. The C language recognizes it as a > viable entity, this is also true. But to the end-product > functionality it is really non-entity. You can use this same argument about computers in general. I don't care what's in that black box, I just want my data from the Web. > You always pass data through it, data is only useful in either > storage or display. And these are really registers. So is RAM. >>> will make more money than BG thought exists. >> >> Not if BG has anything to say in it. > > He is exactly where IBM was before him. To the Tee. Now see what > happened to them. Agreed, but that's not relevant to the argument. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970908142946.45138>