[OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:
> On Sun, 24 Jan 2021 at 17:27, Chris <oidev at bsdos.info> wrote:
>> I have a recent install where I simply login at the
>> console -- no X related stuff. Just the screen.
>> Things just seem broken, For example, a simple ls /dev
>> takes a full 3 to 4 seconds to fill the screen, and each
>> page full is an additional 3 to 4 seconds. This is on a 3
>> core AMD CPU @3Ghz && 8Gb RAM on a x16 pcie Nvidia card.
>> This seems horribly unreasonable. Simple shell scripts
>> that output to the screen take as long or longer to write
>> to the screen. It's like the old days logging into a BBS,
>> or an anonymous ftp site on an 8086 or 80286.
>> 
>> Thanks for any clues! :-)
> 
> Do you happen to know what resolution and colour depth are in use on
> the console on this machine?  As far as I recall, the current
> framebuffer console code doesn't use any acceleration features, it
> just writes each frame to a flat bitmap effectively.  The higher the
> resolution, or the higher the colour depth, the more CPU cycles will
> be spent on copying data into the display.
> 
> I believe you can tell by running something like this:
> 
>     # mdb -ke 'tems::print -d ts_p_dimension ts_pdepth'
>     ts_p_dimension = {
>         ts_p_dimension.width = 0t1280
>         ts_p_dimension.height = 0t768
>     }
>     ts_pdepth = 0t32
All the reports I've seen thus far, indicate 800x600.
You're suggestion confirms it:
ts_p_dimension = {
     ts_p_dimension.width = 0t800
     ts_p_dimension.height = 0t600
}
ts_pdepth = 0t32
> 
>> From these numbers we can determine the rough size of the framebuffer
> data region; e.g.,
> 
>     1280 * 768 * 32 / 8 / 1024 / 1024 = 3.75 MB
> 
> If you had a larger display, say 1920x1080, that could result in
It's running on a 1900x1200
> around twice as many pixels.  All things being equal, it would
> probably take twice as long to draw an update.  I believe the
> framebuffer modes available to you depend at least in part on what
> your UEFI firmware makes available, but I'm not sure off-hand how to
> enumerate them or choose between them.  Someone else may recall, or we
> can look at the boot loader docs and code to find out.
> 
> With that in mind, it might help to know whether, on your system, the
> CPU is the bottleneck.  Your system has a lot of cores, but is at
> least one of them 100% busy (presumably mostly in the kernel) while
> the display is updating?  You could run "mpstat -T d 1" redirected
> into a file in the background to get overall CPU measurements with
> timestamps.  Then, run something that takes 20 seconds to display and
> look at the output to see if a core is busy during that time.
> 
I'm booting via BIOS. While the CPU may be involved. I would have
imagined that the cycles would be on the GPU. Which should be more than
adequate to run high frame rates.

> If there's a CPU that's relatively busy, I would next use DTrace to
> profile the kernel.  You can get a flamegraph of the same 20 seconds
> of busy work:
> 
>     https://github.com/brendangregg/FlameGraph#dtrace
> 
> Profiling data like that should let us know where the kernel is
> spending its time, and may give pointers for optimisations or fixes we
> could make.
Thank you *very* much for taking the time to reply!
I'll dump some mpstat data to file, and see what (if anything) pops up,
and report what it contains.

Thanks again.

--Chris
> 
> Cheers.

-- 
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX