🚀 go-pugleaf

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
---------------------------------------------------------------------------