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

[Chris]

On 2021-01-24 18:53, Chris wrote:
> 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.
Alright. Here's the output from mpstat (see attached).
Any thoughts on the output?

Thanks!

--Chris
>> 
> 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: MPSTAT
URL: <http://openindiana.org/pipermail/openindiana-discuss/attachments/20210124/dab2b8f9/attachment-0001.ksh>