Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Sep 1996 17:48:55 +0000 ()
From:      David Nugent <davidn@sdev.blaze.net.au>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        craigs@os.com, jab@rock.anchorage.net, freebsd-hardware@FreeBSD.org, hackers@FreeBSD.org
Subject:   Re: Slow Etherlink
Message-ID:  <Pine.BSF.3.95.960918173504.2777P-100000@sdev.blaze.net.au>
In-Reply-To: <199609170456.OAA10729@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 Sep 1996, Bruce Evans wrote:

>>One thing I will say about Linux is that it has superior screen display 
>>performance.  So, if what you are complaining about is screen redraw 
>>speed, Linux is much faster than FreeBSD.
>
>Really?  Linux was 6-12 times slower last time I worked on speeding up
>syscons.


I can only agree to this. I recently switched from RedHat Linux
(running kernel 2.0.10) to FreeBSD on exactly the same hardware,
and without having benchmarks at all I'd rate syscons quite noticably
faster than Linux's console. When the scree scrolls, for example, I
often missed screens of output in the blink of an eye (I'd rarely even
see them scroll by!), whereas on Linux I'd have the opportunity
to hit ^S to stop the display. Well, at least I learned to use
more, more (and more - sic! :-)).


One problem I do have with the syscons driver, however, is the
cursor. I'm not one who things much of the blocky cursor, especially
since porting Crisp as an editor with it's neat ability to change
the cursor size over virtual/real spaces - it needs to have the
hardware cursor enabled (e.g. vidcontrol -c destructive) so the
cursor size can change. The problem is, the screen updates are
affected by enabling that, such that when typing at the shell
prompt, you often don't see characters that are typed until you
hit enter.

Is this a known problem? I'm running 2.2-CURRENT if that is
relevent, although I noticed the same when I ran 2.1.5-RELEASE as
well. Right now I just have the editor enable the destructive
cursor while editing, and switch it back off when exiting via the
appropriate ANSI sequences. Unfortunately, while that's fine
while within that vt (Crisp itself seems unaffected by this 'bug'
- it seems only to happen with cooked stdio enabled, or maybe if
termios echo enabled since it occurs with tcsh as well;  I
haven't really experimented all that much) - but the destructive
cursor is system wide, so switching to another vt while editing
brings the destructive cursor with it. 


David Nugent, Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-791-9547 Data/BBS +61-3-792-3507 3:632/348@fidonet
davidn@blaze.net.au http://www.blaze.net.au/~davidn




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.960918173504.2777P-100000>