On Fri, 2015-08-14 at 07:51 -0400, Bill Maltby (C4B) wrote:
> <snip>
> Ksnapshot region selection still lagging and jerky.
>
> So it would be easy to think some of this A.M.'s updates had a
> beneficial effect in one regard, CPU, usage, but not in the clunky
> behavior of region selection with Ksnapshot (could be a mouse driver
> issue introduced with the 6.7 update?).
>
> But drawing any conclusion would be premature until I've run a normal
> day and see if FF keeps increasing in CPU usage like it normally does,
> the java applets, once I've several running, do the same, etc., and see
> how Xorg CPU usage and region selection with Ksnapshot behave.
Xorg CPU usage did increase, as before, under certain conditions of my
test, and held up very high at times when I would not have expected that
(like when the things that may have caused it are left idle with no
activity for hours on end).
Ksnapshot region selection had only minor, if any, improvement. This is
subjective, so hard to be certain.
>
> I'll wrap up this thread this evening and thanks for your help Gordon!
>
> Bill
To spare the list, most of whom likely have little interest,
http://pastebin.com/6Gtf99fh contains the gory details of my attempt to
find causation. Undertaking it over the weekend when certain possible
causes weren't available was not optimal but I don't want to take too
much away from my real-life needs to overcome deficiencies introduced by
new ... "features".
But I would like my 6-core AMD Linux home-built box to perform better
than, or at least as well as, my *old* (2009?) 2-core HP AMD Windows 7
(now Windows 10) box. Yeah, it has more memory, 12GB vs. 8GB, and only
runs a single user, but that's not enough to make much difference
because it runs a really hoggish *huge* Java app all day while my Linux
box just runs some spreadsheets and browser activities.
Never thought I'd see the day when an *IX box couldn't keep up with that
other stuff.
One possible good may come from it - a possible clue to where to look
next to fix the telinit 3/5 X screw up referenced in the big report
posted in the CentOS mantis system back in ... Dec? Since RH doesn't
have it I assume the same thing that caused run-level change to stop
working correctly when X is active will cause it to not get fixed.
On to the topic du jour ...
First, a couple minor corrections.
I erroneously provided CPU info from one of my other boxes in the OP.
Actual CPU is
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 10
model name : AMD Phenom(tm) II X6 1035T Processor
stepping : 0
cpu MHz : 800.000
cache size : 512 KB
...
cpu cores : 6
...
I also said "openoffice" when it's actually "libreoffice".
My preliminary conclusion is there's something in java and/or
libreoffice that begins causing load on the X server once activity
begins. The full effects of the java applet in FF could not be
determined during the attempt to duplicate due to the lack of a data
feed Saturday and Sunday.
There's apparently something somewhere that holds the X server load high
even when the causative items are just sitting idle for extended
periods.
The Ksnapshot region selection is still clunky (tested again after this
latest closing of the all spreadsheets and libreoffice) with noticeable
lag to cursor movement and jerky progression of the window borders, as
compared to CentOS pre-6.7 update.
I doubt I have enough expertise to do anything more that could be
worthwhile, but hope that maybe someone who has the interest and
expertise might stumble upon, or pursue, a solution.
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
