MORGENSTERN@TCUAVMS.BITNET (11/15/89)
A while back there was some discussion about what a MIP measured, and more recently there have been some queries about SparcStation performance from perspective buyers. I do work on heuristics for combinatiorial optimization, and have been testing heuristics on a 3/60 (running at 3 MIPS I'm told) with 8 Megs and no floating point coprocessor. Recently, we took delivery on a SparcStation I (8 Megs with a floating point coprocessor) that is rated in excess of 10 MIPS (again -- so I'm told). The point of this note is that no uniform speedup was observed going from the 3/60 to the SparcStation. At one extreme, a C program that does intensive floating point work ran 36 times FASTER on the SparcStation (this speedup would be much less if the 3/60 had floating point coprocessor), and at the other extreme, a C program that uses numerous data structures implemented using bitwise ops ran 1.7 times SLOWER on the SparcStation (this program also does some floating point ops, so the slowdown would be worse if the 3/60 had a floating point coprocessor). We've also noticed that the SparcStation becomes quite slow when someone is doing nothing more than editing a file on the console (slow to the point that vi acts like the load average is up around 10 or so when it is actually less than one). This is not observed when several people are logged on via ethernet -- only when the console is being used. We have lots of swap space (32 Megs), a small optimized kernel and the "standard" 327 Meg shoebox.
jeremy@kheops.cmi.no (Jeremy Cook) (11/20/89)
> We've also noticed that the SparcStation becomes quite slow when someone > is doing nothing more than editing a file on the console (slow to the > point that vi acts like the load average is up around 10 or so when it is > actually less than one). This was one of the first things we noticed when we first received a SparcStation. If the console user wasn't using X or Suntools then none of the other users could get any reasonable response out of the machine. We suspected that this has something to do with the device driver for the console display. Could it be that the default device driver is very inefficient but that the time used to access the device does not show up in a 'ps' ? -- Jeremy Cook (jeremy@kheops.cmi.no)
david@sun.com (friend of the Dept. of Techinal Publications) (11/21/89)
In article <3102@brazos.Rice.edu> MORGENSTERN@TCUAVMS.BITNET writes: >We've also noticed that the SparcStation becomes quite slow when someone >is doing nothing more than editing a file on the console (slow to the >point that vi acts like the load average is up around 10 or so when it is >actually less than one). This is not observed when several people are >logged on via ethernet -- only when the console is being used. This happens because the system is spending a lot of time in the boot PROM console terminal emulator with interrupts disabled. The solution is to start up sunview even if you just want to edit a file -- it only takes a second if you use sunview -n. David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@eng.sun.com
elvis@athena.ee.msstate.edu (surfer) (11/28/89)
>> We've also noticed that the SparcStation becomes quite slow when someone >> is doing nothing more than editing a file on the console (slow to the >> point that vi acts like the load average is up around 10 or so when it is >> actually less than one). >This was one of the first things we noticed when we first received a >SparcStation. If the console user wasn't using X or Suntools then none of >the other users could get any reasonable response out of the machine. We >suspected that this has something to do with the device driver for the >console display. Could it be that the default device driver is very >inefficient but that the time used to access the device does not show up >in a 'ps' ? As the sole user of our SS-1GX (8Mb, 2*100 Mb internal drives), I have noticed no performance problems excpet those incurred by having only 8Mb RAM and running OpenWindows or Sunview and doing useful work (sci.viz. code development). I suppose that I am to blame partially for this (any cores dumped tend to run >9Mb). The window systems run great (except for pswm crashing if it gets behind in the input queue), and I feel as if I'm working on my apple II+ when I am forced to return to using my old Sun 3/60. Appearing again: -John West- elvis@athena.ee.msstate.edu MADEM Project **** Research Center for Advanced Scientific Computing Mississippi State University P.O. Drawer EE (601) 325-8234 (voice) Mississippi State, MS 39762 (601) 325-2298 (fax) USA ........the opinions presented here are those of the King..........
hedrick@geneva.RUTGERS.EDU (Charles Hedrick) (12/02/89)
You complained that editing on the console of a Sparcstation is very slow. You didn't say exactly how things were set up, but I think I know what is going on. When you work on the bare console, i.e. not in a window system, Sparcstation 1 screen operations, e.g. scroll, are amazingly slow. I'm not sure why that is. (Maybe the console emulator is written in Forth instead of assembly?) But if you start up a windowing system, things are fine. I suppose they thought that people would always use a window system. The only complaints we have about performance in a window system are on color systems, which are quite slow unless the window system supports the graphics accelerator hardware. Fortunately the Sun-supplied window systems do. My only complaint about the Sparcstation is that the internal hard disks Sun supplies are quite slow. But with external H-P disks, a Sparcstation seems quite snappy. I find that the H-P disks are about a factor of two faster than the internal Sun disks, over a variety of tests. Our 3rd party vendor (Boxhill) says that the internal disks are about 28msec disks, so that's no surprise. We have some disagreement as to whether synchronous SCSI helps. Sun was a bit ambiguous about synch SCSI. Some of the literature on the SS1 implies that it uses synch SCSI but most of the spec's say it does not. According to one of the header files, it is implemented but by default turned off. Apparently bad cables can cause sync SCSI to misbehave badly, so they considered it safer to leave it off pending futher evaluation. (Oddly enough, indications are that it is by default on for 3/80's.) It's easy enough to turn on: adb -k -w /vmunix /dev/mem scsi_options/X ;should show 18 ./W 38 That changes it in the running kernel. Use ? instead of / to make the change permanently to /vmunix. Use ./W 18 to go back to async. Turning on sync SCSI actually slows things down with the external H-P disks. However one of our system staff (one of the few with SS1's on their desks) claims that things start up for him much faster when SCSI is enabled on a machine with the internal Sun disk.
jef@well.sf.ca.us (Jef Poskanzer) (12/08/89)
In the referenced message, jeremy@kheops.cmi.no (Jeremy Cook) wrote: }Could it be that the [console] device driver is very }inefficient but that the time used to access the device does not show up }in a 'ps' ? Yes, the console driver is extremely inefficient (what do you expect from FORTH); yes, the CPU time it eats does not show up in a 'ps'. But the most amusing part is that the the time it eats up "doesn't exist". While the console driver is updating the screen, the system's real time clock is not being updated, and time "stands still". The clock does not catch up later, it stays slow. This makes benchmarking the console's speed an interesting proposition... Anyway, the moral is (a) don't use the console, and (b) if you must use the console, remember to reset your system's clock every day. Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef
Kemp@dockmaster.ncsc.mil (12/08/89)
David DiGiacomo writes: > This happens because the system is spending a lot of time in the boot > PROM console terminal emulator with interrupts disabled. That brings up something that has been bothering me ever since we got our 4/110 - the console is SLOW! Our little 3/60's put text up on the console much faster than the 4/110 which is rated at more than twice the MIPS. Now we have 12.5 MIPS SPARCstation-1's, and their console performance is not one bit better. What did Sun do in that ROM anyway? Write the font blit code in FORTH? And then write the FORTH interpreter in TINY BASIC??? :-) Running SunView isn't always an option; at least I haven't found out how to run it from the miniroot. And waiting for the slow console can be a real drag when you're doing a "tar xv". It even slows down booting. The 3/60 loads a 500K vmunix from sd0 in about 3.2 seconds, but the 4/60 takes nearly 7 seconds to load its 700K vmunix. At first I thought a crummy SCSI driver was to blame, but I now suspect that the little rotating propeller (and the abysmal console performance) is the culprit. This obviously isn't a terribly important issue, but it does irk me that my hot new machine is so much slower than the trusty ol' 3/60. Dave Kemp <Kemp@dockmaster.ncsc.mil>