On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:
On Sun, 24 Jan 2021 at 17:27, Chris <oi...@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
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
