mlewis@unocss.UUCP (Marcus S. Lewis) (10/10/89)
From article <1161@svx.SV.DG.COM>, by gary@dgcad.SV.DG.COM (Gary Bridgewater): > In article <2016@unocss.UUCP> mlewis@unocss.UUCP (Marcus S. Lewis) writes: >>From article <1156@svx.SV.DG.COM>, by gary@dgcad.SV.DG.COM (Gary Bridgewater): >>> blah, blah, blah >>I manage an MV/20 and for kicks the other day (while the system was >>loaded) I moved a rather large (600K+) file around the system disk. And >>the numbers are appallingly low, roughly 80KB/sec throughput from a >>directory on the system disk to @NULL. This is on a system with about >>90 people logged in, on Argus disks. This does NOT compare well with >>standalone PC disk throughput as reported in comp.arch. But then, this >>is an apples-and-oranges comparison, right? > > right. But how did you move it? move/buff=32768 or cop/imtr=32768 speed that > up. The cli was optimized for small memory aos systems. Sigh. This is why > DUMP_II and LOAD_II (and DUMP_III/LOAD_III) act like they came from another > planet when compared to dump and load. Well, the 80K/sec was AS FAST AS IT WOULD GO. I used, variously, dump/load dump_ii/load_ii and copy, with several buffer sizes. The 80K/sec reflected 8 seconds to move the 600K file nowhere. The numbers for actually moving the file around were much worse - and I am a firm believer in mangling file element sizes. Four blocks/element took near 40 seconds, 1000 blocks/ element cut that by >1/2. Even with this "low performance", we are CPU bound, and I would like to see what an Aviion would do in our applications. But DG has been a bit slow in providing Aviion development systems to our systems vendor. We are using M/DG (Mumps) in a financial application. We had a contractor come in to write us a synchronous driver for our on-line stock trading system and he was appalled at what we were doing. We have a mod 1 with 24 MB and can use almost all of our 154 asynch ports. Mumps is a CPU hog. We are walking a tight line on Disk I/O (need another spindle - bad!), and have enough, but not too much memory. We hit 100% CPU utilization roughly 16 hours a day. This sore spot (for me) partly comes about becasue we have a "unix" box running a peripheral stock market application and I get a lot of grief from the guy who runs it about slow hardware that costs an arm and a leg. Gotta go - I haven't even had my first cup of coffee yet. Marc -- --------------------------------------------------------------------------- Na khuya mne ehto gavno? | Internet: cs057@zeus.unl.edu preferred machine->| UUCP: uunet!btni!unocss!mlewis ---------------------------------------------------------------------------