Unbelievable: it's 1995 and Sun's console speed is still pathetic
D. J. Bernstein
If you work with an old SPARC you're probably painfully aware of how
slowly it draws characters on the console. Surely Sun knows that its
console is the first thing that a new user sees; surely Sun realizes
that it looks bad for characters to be drawn at 300 baud. I naturally
assumed that this efficiency problem was fixed years ago.
I was wrong. The SPARC 5 console is incredibly slow. It draws, at best,
a few hundred characters per second; it takes nearly a second to scroll
the screen.
(The speed seems about right for one context switch per pixel. But there
are no context switches here---as always, the console driver doesn't let
the system do anything else while each pixel moves slowly into place.)
Even worse, after Sun's X server exits, the console driver gets even
slower. Before each scroll it twiddles its thumbs for a second or two.
I've seen this problem before---on a Sun 3!---but none of the old
solutions seem to work. (Except, of course, rebooting.)
---Dan
Charles Stephens
DB> I just brought up a brand-new SPARCstation 5, my first new Sun in
DB> years. If you work with an old SPARC you're probably painfully
DB> aware of how slowly it draws characters on the console. Surely
DB> Sun knows that its console is the first thing that a new user
DB> sees; surely Sun realizes that it looks bad for characters to be
DB> drawn at 300 baud. I naturally assumed that this efficiency
DB> problem was fixed years ago.
DB> I was wrong. The SPARC 5 console is incredibly slow. It draws, at
DB> best, a few hundred characters per second; it takes nearly a
DB> second to scroll the screen.
DB> (The speed seems about right for one context switch per
DB> pixel. But there are no context switches here---as always, the
DB> console driver doesn't let the system do anything else while each
DB> pixel moves slowly into place.)
DB> Even worse, after Sun's X server exits, the console driver gets
DB> even slower. Before each scroll it twiddles its thumbs for a
DB> second or two. I've seen this problem before---on a Sun 3!---but
DB> none of the old solutions seem to work. (Except, of course,
DB> rebooting.)
This is a bug (yes, it is!). You should install the latest TCX frame
buffer patch and the problem goes away!
cfs
Steve_Kilbane
> Sun knows that its console is the first thing that a new user
I don't think Sun is too worried. They do all their demos on
machines running a window system (wouldn't you?), and
they expect their users to use them in their fashion. Unfortunately
this leaves out in the cold the poor sysadmin trying to repair a
machine that's damaged enough that it can't start a window
system.
As I understand it, the speed of the console is because of the old
FORTH implementations, and that the character set for the
display is being fetched, a line at a time, from the eeprom, which
is a damn sight slower than normal.
steve
--
<Steve_...@cegelecproj.co.uk>
ISPs are responsible for maintaining the Information Superhighway. They
are not responsible for how you drive. #include <std_disclaimer.h>
Reg H. Beardsley
keeps things from scrolling so fast even an Evelyn Woods graduate can't
read it. After all, the console is not meant to be the regular system
interface...
--
------------------------------------------------------------------------
Reginald H. Beardsley r...@acm.org
Consultant/Programmer
------------------------------------------------------------------------
Lewis E. Wolfgang
>Some people might consider the slow console speed a design feature. It
>keeps things from scrolling so fast even an Evelyn Woods graduate can't
>read it. After all, the console is not meant to be the regular system
>interface...
As memory serves, the console is served by a rom-resident driver written
in Forth. (Forth is a simple stack oriented language well suited to running
in rom) Once you start the windowing GUI, other ram-resident drivers,
optimized for the installed frame buffer are used.
Thus Reg is correct, the console was not designed for normal interactive use.
If you want that, get a Wyse 50 CRT terminal, it's lots cheaper.
If you think it's slow now, you should have seen how it was with a 25 Mhz
Motorola 68020 based system!!!
Regards,
Lew Wolfgang
Paul Eggert
>If you think it's slow now, you should have seen how it was with a 25 Mhz
>Motorola 68020 based system!!!
My impression is that the Sparcstation 5 SX (85 MHz) console
is slower than the venerable workstation you're referring to.
It's _really_ slow. It'd be interesting to race them.
Andrew J Cosgriff
CS> This is a bug (yes, it is!). You should install the latest TCX frame
CS> buffer patch and the problem goes away!
There's a forth patch in one of the FAQs too - works kewl, and you don't need
a TCX either.
--
- Andrew J. Cosgriff - and...@unico.com.au - "send file help" as subject
SysAdmin / Support Dude, UNICO Computer Systems PGP & MIME ok and preferred
Killing Madonna Frees Desperate Minds
Charles
: As I understand it, the speed of the console is because of the old
: FORTH implementations, and that the character set for the
: display is being fetched, a line at a time, from the eeprom, which
: is a damn sight slower than normal.
And this my friend, I can tell you, is much preferable than having to type
boot -f dksc(0,5,7)ARCSsash dksc(0,5,8)stand/fx.ARCS to bring an SGI up
into it's god awful system disk partitioning program.
This was posted a while back, I've never tried it.
From: ab...@perth.DIALix.oz.au (Arena Technology)
Subject: Re: Console is like molasses in January
mle...@hudson.cs.unb.ca (OMG) writes:
>In article <3h8au2$m...@news0.cybernetics.net> ro...@netmar.com writes:
>>
>>But in console mode (i.e. no windowing system running) the text display occurs
>>somewhere around 300-400 cps. This is not my idea of speedy.
>Yep, this is normal.
>I havn't thought about this for a while, but seem to recall that the
>screen writing is done via code in an EEPROM which is a tad sluggish.
Sure is... and here's the solution.
In <fYK...@quack.sac.ca.us> mra...@quack.sac.ca.us (Nick Sayer) wrote:
The problem is twofold. First, the console is written
in FORTH, second, it's running in the ROM (which has a bunch
of wait-states per read). There's no solution to the
former, but for the latter, you can do this:
#! /bin/sh
eeprom 'nvramrc=probe-all install-console
ramforth
: cache-page dup pgmap@ cacheable swap pgmap! ;
up@ cache-page
here origin do i cache-page pagesize +loop
banner'
eeprom 'use-nvramrc?=true'
exit 0
Reboot after doing the above. Your console will be much, much faster
and you'll lose 200K of RAM. Just do it once. The effect is
(semi-)permanent. You can turn it off by either using L1-N to wipe
the nvram during boot or you can say 'eeprom use-nvramrc?=false'
if the OS is up to just disable it for the next reboot (don't forget
to 'true' it to re-enable it).
--
Adrian Booth, Arena Technology, 7 Glenrowan Place, Willetton WA 6155 Oz
Phone: (09) 354 4936 | Fax: (09) 354 4115 | Email: ar...@dialix.oz.au
The autumn leaves are falling like rain.
Although my neighbors are all barbarians
and you, you are a thousand miles away;
there are always two cups at my table. - T'ang Dynasty
--
Harnad describes the status of Usenet aptly:
a communication medium with revolutionary intellectual
potential being used mostly as a global graffiti board.
[Harnad 1991]
Andrew J Cosgriff
"CS" == Charles Stephens <c...@cssun.mathcs.emory.edu> writes:
CS> This is a bug (yes, it is!). You should install the latest TCX frame
CS> buffer patch and the problem goes away!
AJC> There's a forth patch in one of the FAQs too - works kewl, and you don't
AJC> need a TCX either.
My mistake - I didn't get it from a FAQ but from the news.
Here's the article for interested punters :
--cut--
>Yep, this is normal.
--end--
Enjoy,
Andrew.
--
- Andrew J. Cosgriff - and...@unico.com.au - "send file help" as subject
SysAdmin / Support Dude, UNICO Computer Systems PGP & MIME ok and preferred
"I spilled spot remover on my dog. He's gone now..." (Steve Wright)
Anthony D'Atri
>think Sun has much of an excuse on this one.
I've found it difficult to do anything screen-oriented on HP consoles outside
of X. Faster they may be, but I'd rather have it slower and able to
support an editor.
Steinar Haug
> >Motorola 68020 based system!!!
>
> My impression is that the Sparcstation 5 SX (85 MHz) console
> is slower than the venerable workstation you're referring to.
> It's _really_ slow. It'd be interesting to race them.
Not sure about the SS-5 SX, but the old Sun-3 models did *not* have
Forth-based console output, and were noticeably faster than the SS-1
for instance.
Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steina...@runit.sintef.no
Mike Fischbein
: > >If you think it's slow now, you should have seen how it was with a 25 Mhz
: > >Motorola 68020 based system!!!
: >
: > My impression is that the Sparcstation 5 SX (85 MHz) console
: > is slower than the venerable workstation you're referring to.
: > It's _really_ slow. It'd be interesting to race them.
: Not sure about the SS-5 SX, but the old Sun-3 models did *not* have
: Forth-based console output, and were noticeably faster than the SS-1
: for instance.
It really has nothing to do with Forth (which provides
a processor-neutral way of initializing SBus cards),
but with the way the character bitmaps for the console
device are stored. Can you count the context switches
per character? I knew you could. :-)
But hey, if you don't like X, at least run Sunview...
mike
--
Mike Fischbein mfis...@fir.fbc.com CS First Boston
Any opinions expressed are mine only, and not necessarily
those of any other entity. They may not even be mine.
Pete A. Zaitcev
>As I understand it, the speed of the console is because of the old
>FORTH implementations, and that the character set for the
>display is being fetched, a line at a time, from the eeprom, which
>is a damn sight slower than normal.
I attempted to implement a raster console for Linux/SPARC and it seems
to be not so simple. I easely achieved good speed for character renditions.
But scrolling is very slow still. Main loop which consumes 90% of time is
as follows (for CG3):
unsigned *p1_0, *p2_0;
while (ix + 4 < w) {
*p1++ = *p2++;
ix += 4;
}
.LL142:
add %o3,4,%o1
cmp %o1,%i4
bge .LL151
cmp %o3,%i4
.LL146:
mov %o1,%o3
add %o3,4,%o1
ld [%o5],%o0
cmp %o1,%i4
st %o0,[%o4]
add %o5,4,%o5
bl .LL146
add %o4,4,%o4
cmp %o3,%i4
.LL151:
Any ideas? I know about a hardware acceleration but it is a last resort.
Pete
Guy Harris
>Can you count the context switches per character?
You mean there's one or more per character, rather than a fraction of
one per character? If so, then either
1) I'm misremembering the way the "workstation console" driver
worked (from when I STREAMSified it for SunOS 4.0)
or
2) they changed the way it works
as I remember it making a "display multiple characters" call to the PROM
monitor whenever possible, and the PROM monitor doesn't, as far as I
know, do context switches when displaying characters (displaying them is
quite likely to be 100% "CPU-bound", where "CPU-bound" includes
"memory-bound").
That also, of course, means it's dependent on how fast the PROM monitor
can draw characters; presumably the people saying it has something to do
with Forth are arguing that the Forth code that draws the characters in
OPEN PROM monitors is slower than the C code that draws them in the
older monitors.
Guy Harris
>I first noticed the horrible scrolling on a 4/470 with
>a frame buffer,
...and, as far as I know, *without* an OPEN PROM monitor, so it can't
be blamed on an interpreted-Forth frame buffer driver in the case of the
4/470.
Doug Hughes
Why not use the one already written by Jeff Poskanzer?
From the README:
libraster - simple low-level raster graphics library
version of 12oct93
This is simple raster graphics package. It's basically a redesigned
and reimplemented edition of Sun's old pixrect library. It does
rectangle operations (bit-blits), points, lines, text (using vfont
files), stencils, tiling, image file i/o (using Sun rasterfiles), etc.
There is also a subsidiary library that provides an API very similar to
pixrect. You can use this to keep your pixrect-based programs going
under Solaris 2.x, where Sun has decided to get rid of pixrect.
All system-dependent sections are in the file raster_sys.c, marked with
the string "SYS". The main system-dependent part is getting the
address of the frame buffer. It assumes a frame buffer either one bit
or eight bits deep, that can be byte-addressed but prefers to be
longword-addressed. Currently it has been implemented on Suns, and it
should work on most combinations of Sun frame buffers and operating
systems. If you port to a non-Sun system let me know, I'm very
interested! It should be fairly straightforward.
Files in this distribution:
README this
Makefile guess
raster.h header file for the raster package
raster.3 man page for the library
raster_batch.c batch-op routines
raster_dfont.c default font
raster_dump.c C struct write routines
raster_file.c rasterfile read/write routines
raster_font.c vfont read routines
raster_getput.c get/put pixel routines
raster_line.c line routines
raster_misc.c structure allocation and miscellany
raster_op.c raster-op routines
raster_repl.c tiling routine
raster_spline.c spline routines
raster_sten.c stencil routines
raster_sys.c system-dependent routines
raster_text.c text routines
gallant19.h include file for default font
test/* various test and utility routines
libpixrect/* clone of Sun's libpixrect
screendump/* clone of Sun's screendump
screenload/* clone of Sun's screenload
spf3/* pretty spline-based patterns
squig/* squiggly tubular patterns
rconsole/* dumb terminal emulator (not ported to Solaris 2.x yet)
To install:
Unpack the files.
Edit the Makefile, and follow the directions for configuring.
(Note: the Makefiles in the subdirectories also have config stuff,
but you don't have to bother with that. Only do the top-level one,
and it will pass the defines through to the rest.)
Make.
Make install, if you like.
Comments to:
j...@netcom.com
j...@well.sf.ca.us
search for libraster/pixrect in archie.
This probably won't help you with Linux though.. :(
--
____________________________________________________________________________
Doug Hughes Engineering Network Services
System/Net Admin Auburn University
do...@eng.auburn.edu
Casper H.S. Dik - Network Security Engineer
>In article <43mqm3$8...@jupiter.sdd.cegelecproj.co.uk>, Steve_...@cegelecproj.co.uk (Steve_Kilbane) writes:
>>As I understand it, the speed of the console is because of the old
>>FORTH implementations, and that the character set for the
>>display is being fetched, a line at a time, from the eeprom, which
>>is a damn sight slower than normal.
>I attempted to implement a raster console for Linux/SPARC and it seems
>to be not so simple. I easely achieved good speed for character renditions.
>But scrolling is very slow still. Main loop which consumes 90% of time is
>as follows (for CG3):
> unsigned *p1_0, *p2_0;
> while (ix + 4 < w) {
> *p1++ = *p2++;
> ix += 4;
> }
typically, code like *p++ = *q++ is slow on SPARC.
p[i] = q[i]
and incrementing i is faster.
Why not use bcopy()/memcpy(). Those should be optimized for the
hardware you use.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Pete A. Zaitcev
>Why not use the one already written by Jeff Poskanzer?
This is a great library which is used in NetBSD's raster console.
Jeff wrote a very good bitblit routine. The routine is a heart of
the library.
I declined it for Linux because of two reasons:
-- I am unaware of its legal status. Linux is GPL, Jeff's bitblt
is not.
-- I am sure I can beat Jeff because his program is too general.
Of course it is better to have a good general solution than a bunch
of ad-hoc solutions. But here we have a particular important case:
console terminal.
-- NetBSD console uses wrong rendering algorithm (char at a time).
They generate a character than use Jeff's bitblit in order to move
it on screen. This causes several loads on every store (remember that
a frame buffer is uncached).
Pete
Vaughan R. Pratt
>In article <DFo7M...@mail.auburn.edu>, do...@eng.auburn.edu (Doug Hughes) writes:
>
>
>Jeff wrote a very good bitblit routine. The routine is a heart of
>the library.
Good lord. It just dawned on me that when Mitch Bradley rewrote the
PROM monitor in Forth, sometime around 1986, he must have tossed out
the native (well, C but I was thinking assembler when I wrote it)
bitblit code I'd written for the monitor in April 1982. That was very
tightly coded, just like the bitblit code I wrote for the new pixrect
package a year later (good thing *that* wasn't translated into
Forth!!!). I'd forgotten about the monitor code. That big font in the
PROM monitor, I did that in April 1982 too, started out doing it by
hand on graph paper until I realized I'd finish a lot sooner if I wrote
a font editor first (pretty trivial editor, involved about three hours
work but it saved several days of messing with graph paper). I called
the font Gallant because it sounded like a font name.
--
Vaughan Pratt http://boole.stanford.edu/boole.html
FTP: boole.stanford.edu:/pub/ABSTRACTS
My mind and my body keep playing tricks on each other.
When I tell them to cut it out, they just say "Who are you?"
Sheldon Young
>Even worse, after Sun's X server exits, the console driver gets even
>slower. Before each scroll it twiddles its thumbs for a second or two.
>I've seen this problem before---on a Sun 3!---but none of the old
>solutions seem to work. (Except, of course, rebooting.)
We have this problem with your SS5 with a TGX (S24, A24, and it's
other aliases). Our SS5 with the normal GX does not have this
problem.