| 1 |
> Thanks for your suggestion! |
| 2 |
> I've built linux with timer freq 1000Hz and also set CPUFreq scaling |
| 3 |
> governor to performance. And beryl |
| 4 |
> continues to lag.. I don't think it's a CPU freq issue. |
| 5 |
|
| 6 |
|
| 7 |
from what you've said it seems that it has some things related to the |
| 8 |
processor switch to on. even if it's on performace, the processor would wait |
| 9 |
a little time to start processing the commands. this should be less than |
| 10 |
1nanosec so impercetible to human mind, but it seems that on your sytem |
| 11 |
there's a bottleneck somewhere. maybe you've set the tickless option in |
| 12 |
kernel for powersaving mode, or your disk is spinning too much. install some |
| 13 |
monitor daemon (like kima on kde) or other that are around and see what |
| 14 |
happens when you trigger your update: see if your processor is actually at |
| 15 |
full speed and what's its load when it starts to work on beryl. |
| 16 |
|
| 17 |
Also I'm running a dual core SMP system where I think a 1000Hz timer won't |
| 18 |
> be beneficial. |
| 19 |
|
| 20 |
|
| 21 |
it's not true, from what i've heard around. |
| 22 |
|
| 23 |
I tried setting higher GPU clocks for 2D mode using the nvidia-settings |
| 24 |
> utility and beryl is now more responsive, |
| 25 |
> but not enough. Maybe the transition between 2D to 3D mode is somewhat |
| 26 |
> slow causing this laginess for a while. |
| 27 |
|
| 28 |
|
| 29 |
then maybe you have some wrong settings in xorg.conf. try looking around in |
| 30 |
some forums to see if there are some specific nvidia settings. on phoronix |
| 31 |
there's an nvidia dedicated forum so take a look there too. you may find |
| 32 |
something useful. |
| 33 |
|
| 34 |
> |
| 35 |
> Nice.. Just waiting to help stabilize it :D |
| 36 |
|
| 37 |
|
| 38 |
i've learned that ati-drivers and nvidia ones are better to install when |
| 39 |
they reach the ~ branch since, especially for ati ones, that are released |
| 40 |
every month and don't make it in time in the stable branch until there are |
| 41 |
new bugfixes and performance tunes. this should apply also. the nvidia one |
| 42 |
in the stable is 14 releases behind the released one (about one year and a |
| 43 |
half), and there have been a lot of fixes and the 8000 series have had a lot |
| 44 |
of performance improvements. |
| 45 |
i'd recommend you to add x11-drivers/nvidia-drivers ~x86 or |
| 46 |
x11-drivers/nvidia-drivers ~amd64 and update the drivers. and this is not a |
| 47 |
simple recommendation but it's more a do the upgrade since it will only make |
| 48 |
your linux experience better. |
| 49 |
and last thing: the tilde branch don't mean that a package won't work or |
| 50 |
would break your system. it simply means that if the package don't work then |
| 51 |
you don't have to complain about it with gentoo devs since they'll tell you |
| 52 |
that the package is not stable and you weren't forced to use it. for example |
| 53 |
upgrading to the latest kernel is not bad and many users (like bcm43xx one |
| 54 |
have always some fixes and some performance gains); the same goes for |
| 55 |
compiz/beryl, which i recommend to install from the xeffects overlay (look |
| 56 |
into the forum or in www.gentoo-xeffects.org on how to add the overlay to |
| 57 |
portage), will most likely not hit the stable branch as they're not |
| 58 |
mantained directly by gentoo devs. the packages that are really bad are the |
| 59 |
one hardmasked and that ones it's not recommended to install unless you |
| 60 |
really know what you're doing. |
| 61 |
but i repeat, for tilde this doesn't apply. |
| 62 |
|
| 63 |
-- |
| 64 |
dott. ing. beso |
Archives