Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: Kronos vs. Hardframe Message-ID: <8750@cbmvax.UUCP> Date: 29 Nov 89 09:49:21 GMT References: <3481@convex.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 102 in article <3481@convex.UUCP>, swarren@eugene.uucp (Steve Warren) says: > Keywords: Kronos, Hardframe, controller > "...For example, when tested with the latest optimized Micropolis high- > performance hard drive, the KRONOS controller read in and wrote back out > 10 one-megabyte data segments in just under 20 seconds for an astounding > 1009K/sec data transfer rate." That's certainly possible. If the data's sitting there all ready in a RAM buffer, and they're reading/writing with a decent routine, they can get an effective maximum transfer rate of close to 1/2 the expansion bus speed, about 1.7 megabytes/second. Actually it'll come out less than that with a 68000, because no matter how you optimize your transfer loop, you're going to have to fetch instructions occasionally. Asynchronous SCSI runs at a max of around 1.5 megabytes/second, so they can in theory keep up. I didn't see them claiming this transfer was through the file system up there either. I don't recall the exact numbers, but I think they came in around 1.3-1.4 megs/second with plain device drivers; the 1.1 megs/second or whatever they get with the Wren VI these days is through the filesystem. They tells you two things, though C. Ltd only wants you to hear one of them. They want you to hear that their drive will keep up with DMA devices, and if they haven't made any mistakes, it will come close. What they aren't telling you is that, in order to do that, the Kronos will have to take every available bus cycle during transfers. The DMA device will only need 1/2 the available bus cycles to achieve the same speed. Which means your programs move during disk activity, since the disk transfer is only going at around 1/2 the speed of the Amiga. If it supports synchronous SCSI, the DMA device could possibly run transfers twice as fast, using pretty much all available cycles (synchronous SCSI maxes out at around 4-5 megs/second). It still sounds like the seeking speeds of the drive will be the limiting factor. > You asked for the disk-perf results; this is part of what they published. It's interesting, but our disk folks don't like DiskPerf; they claim it's not granular enough at high speed. For any controller, DMA or non-DMA, once you're at high speeds, the software overhead is going to make a difference. > But here is some of the misleading stuff: So this brochure contains lies, damn lies, AND benchmarks! Sounds like a classic -- I'll have to pick one up if they're at WOC. > The problem I think they are referring to did not result from DMA, it > was a design flaw that could have been made on any controller. The > controller it affected happened to be a DMA drive. Now manufacturers > are going around trying to scare people away from DMA. This is silly. Exactly. The 2090 doesn't properly handle overruns on its FIFO, and the 2090 is a DMA driven controller, therefore all DMA controllers must have the same problem. Sounds like someone either flunked Logic 101 or passed Marketing 101. > C.Ltd may indeed have developed a nice way of avoiding custom chip > conflicts, but whatever it is, it is not because it is non-DMA. The > same techniques could be used for a DMA controller. The ways to avoid custom chip conflicts are well known. You pretty much have your choice of buffering up a whole block from the SCSI device, the way GVP does it, or filling a FIFO and telling SCSI to stop sending before you're filled. They certainly appear to have done things right, but I sincerely doubt they've come up with any new magic. I'll bet if the GVP controller's software were changed from compiled C to carefully hand optimized assembler, it would be roughly as fast as the Kronos. There could be a minor hardware design win in one or the other, but I'm sure C.Ltd's big win here is the software. > If they really have such a fast controller, why don't just say, "This > here wiz-bang controller is so well-designed, it beats the DMA > controllers at their own game," or some such nonsense. Most people don't even come close to understanding the rather simple set of problems a controller has to solve. So hype works real well. > There *are* some really excellent features claimed in their literature ... > So, with all the features, I wish they didn't feel the need to obfuscate > things. Yeah, they did a fair job with their original 8 bit controller. They were playing around with other SCSI devices like their laser printer, scanner, SCSI-net, and a few other things long before most anyone else had built SCSI devices. I agree -- there's no need to mislead folks if you really have something unique to offer. Sure, some may take the bait, but if I read a some promotion that I felt was making an ernest attempt to mislead me, I'd have a bad feeling about the company, regardless of the actual merits of the device they're hawking. I guess the hard disk controller market is getting pretty full these days, though. I wish someone would design something interesting for a change... > Cheers, > --Steve -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough