Need help with (sort of trivial) stuttering in Mint

So, i need a clue what to change etc. in my Mint 17.1 installation.
Problem:
Most of the time, 2D drawing in Cinnamon works fine, but after boot up, it draws windows fine, and 20 secs in, it starts to stutter (repeatedly opened multiple windows etc.), after approx 1 minute it stops, and continue to work fine. Now, if system is on idle for about 20 minutes, stutter comes back, and also, on seemingly random occasions (while browsing etc.) stuttering starts and stops latter (seems random).

I saw same problem on some video reviews of Linux Mint before, but, on those reviews stutter was constant through whole video (10+ minutes).

I did found connection, with open-source drivers, it seems that it is not present, but there is ocasional stutter in videos (VLC, youtube etc. - non related). With proprietary drivers, videos work exactly as i want to, but, problem is there.

Now connection:
When i start Audacious (player mp3's etc.), and just keep it in taskbar, no stutter occurs, it does not need to play anything. However, if i enable plugin on that same player to move it to sys. tray, it have no effect (stutter comes and goes again).

Since i had similar problem in Windows, that was connected to the timer resolution for CPU (if timer resolution is 768-1000 micro seconds = no stutter, if 15 000 = stutter, but always in Windows, not like in Linux from time to time)., i wonder if same thing is a problem in Linux, and what is the settings, and how to configure Linux kernel to use constant timer with proprietary drivers? Or is it something else?

I know this is probably hardware problem (since on my other PC, everything works fine = Windows, any distro of Linux i tested etc.), but, since Audacious solves it, i wonder if there is a way to actually force Linux to do whatever it does when Audacious is in taskbar, but, obviously without that player. Any help (clue) is appriciated. Thanks.

UPDATE:
Solution is to add lines in /etc/environment:
CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=False (note i use false because high refresh rate).

Are you using Windows graphics drivers (aka "proprietary" drivers) in your linux install?

Audacious uses its own codecs, if that's a clue. You can actually change the settings on cinnamon to not use 2D acceleration.

i would be looking at checking your HDD for smart errors.

@Zoltan is right, do you have the nvidia driver installed?

i would be leaning more towards the HDD issue. since it was happening in windows as well.

Yes, I'm using proprietary drivers for AMD (those included in Mint, I've tested 14.x and those in Mint was better for me). I was actually away from PC from the time i posted (4h), and when i come back, i left Audacious and firefox opened, 2d was stuttery mess, and even Audacious couldn't help it (had to reboot).

How can i disable 2D GPU acceleration in cinnamon?

I assume youa re speaking about OS drive? Or should i check other drives also, Mint is on SSD, and another drive is auro-mounted, thanks for suggestion.

Bump because I have this problem as well. Sometimes everything moves smoothly, but then everything becomes choppy again.

@wkpsfbx
Also, things i tried so far:

  1. Boot from USB with all controllers (lan, audio, sata) disabled = same problem even with open source driver.
  2. I've tried to disable DRI (and DRI2), hardware acceleration and some other things via xorg.conf, if commands are under "modules" they are ignored, if commands (eather disable or "true/false") are under device, cinnamon crash on login, and put me to terminal login (then have to nano xorg to remove line, and then it works).
  3. I spoke to soon, problem is present with open source driver also, hint: When firefox is opened, and download (iso of another distro) is active, constant stutter is there (not sure if it is always, didn't had time to test).
  4. I've tried with all USB devices disabled = same result, HPET disabled = same result (i prefer to have HPET disabled).
  5. Tried to disable 2 cores on CPU, use only one module of RAM, and multiple other UEFI/BIOS settings (including viltage change, ide instead of AHCI, HPC, power saving features = disabled etc. literaly every possible setting) = same result.
  6. Tried to put GPU in another PCIe slot = same result.
  7. Last thing that i will try today is to change PSU, i doubt it will work, but will test and report here.

I have no idea what to try next. Any idea is welcome. I am very positive it is hardware problem. Can i ask you if you use AMD machine and what is the model of your motherboard if that is the case? Since on my C2D everything works fine, but on AMD that is the problem, and it is probably motherboard (or even CPU itself).

@Zoltan, do you know how to make commands for DRI and HW accel to work under xorg if possible?

PS: I found thread on Mint forum considering same problem = unsolved, by some guy named Mike something (I forgot the last name/complete nickname).

I don't use Mint, but I suspect you're having the following problems if you don't have HW accel with the KMS driver:

  1. you haven't blacklisted Catalyst, or you're on the wrong radeon (check glxinfo for what the system is using for what)

  2. You haven't manually updated. Mint will by default only update the bare necessities, it will not update all of the packages, and it doesn't start out as a bleeding edge distro, so you'll have to do manual updates to get a representative system. It's one of the biggest problems with Mint, I don't know why they're not changing it. The problem with Mint is that since most of the user base only does the automatic updates, there is not enough testing feedback for the full updated systems as they should be running, and therefore Mint isn't the most bug free of distros, but if you want to have the best chance of everything working as it should, update everything that is updateable, including - very important - the kernel itself. You really don't want to run on an "oldish" kernel. Either you're running on a really old long term support kernel, and you're using all of the patches and proprietary bling, or you're running on a bleeding edge kernel that has all of the latest updates and functionality. In any case, only use Catalyst if you really have to, like if you really need the few functions or extra fps that Catalyst offers over radeonsi. Catalyst is end-of-line for linux, it's not developed further, as AMD is switching to AMDGPU as proprietary KMS driver on linux, and is focusing completely on the development thereof, and on the development of radeonsi. AMD is just not paying a whole lot of attention to porting the Windows driver to linux much longer.

If you're 100% sure that you're running ONLY on the open source driver, and you're still experiencing stuttering, and dmesg is not informative on what is happening, and you've not been experimenting with your scheduler or have been tweaking some holy grail kernel settings proposed by some guy on a forum (ya know, Ubuntu and Mint fora... sigh...), the first stop is to run top/htop and take a look at what the system is doing at any given time. If that doesn't help you, run powertop to see what part of the system is using power, that is often also indicative. Often stuttering in systems is caused by crooked power management settings. Powertop will make recommendations for efficient power management, but you have to let it learn for at least 20 minutes or so, or the recommendations may have adverse effects, for instance with USB devices being shut down where they shouldn't be. Also run the storage diagnostics in disks. Sometimes stuttering is caused by storage problems.

There are a few things that can screw a system up, that are often overlooked: Google Chrome for instance being the number 1, because it makes ample use of background processes and interferes with a lot of parts on the system. Just don't ever use Chrome on Linux, use Chromium, use the pepper hack to get flash support if you really have to, use Firefox, but just don't use Chrome lolz, it is only maintained by a dude from Google for Ubuntu, but nothing else, whereas Chromium is maintained by the maintainers of the different distros, and is much more stable on most distros. Google is infamous for not playing nice with code. Their code is a mess, they don't even try to respect the open source principle of using existing packages developed by others, they just hack them and provide their own version with their crap to make it work willy-nilly, and that often leads to all kinds of problems.

For firefox, the problem might be that your system doesn't play well with the latest version. If you're having Firefox performance issues, switch to the extended support version of Firefox. It's much more stable on intermediate systems (not bleeding edge and not really old) than the latest version, and just as secure (in fact, more secure, it's the enterprise version basically).

I think you have been trying out too many things. That's not criticism, everybody has that, it's when you look over something and don't give up on solving it, and it happens to all of us. Just don't waste too much time on it. If you're on Arch or Gentoo, you have to do a lot of diagnostics and problem solving, but not if you're on Mint. It may very well be that your install was compromised in some way or another, because of a crooked package or something. There is no way to know without full system diagnostics, and most of the time, it isn't worth it. You can however easily reinstall without losing your data or applications, by installing without formatting the /home partition. Maybe try a standard install without Catalyst, see if that solves the problem. It's only 5 minutes work, and can save a lot of time. I would probably just do that to be honest. Part of the problem with Mint is that nobody's listening, just like with Ubuntu, if it's a fundamental problem, you'll just never know, and all you have to go on is the ramblings of other people on their forum, people that are equally in the dark. At least on Ubuntu there are alternative community fora that may offer useful information, like askubuntu for instance, but for Mint there is nothing like that.

I'm sorry I can't really help you, I don't have enough info, and it's even hard to help out on a distro one doesn't know when full system debug info is available.

Just do a PCI config space hex dump between working/non-working devices to track down the driver source register offsets.

Well that's what I would do, mainly because your issue is almost certainly related to your soundcard ;)

Well, that is a lot of useful info, thanks. However, i did found out what the problem is. I've tried different PSU = same problem, but I also tried different GPU (nvidia, but i think it doesn't matter), and, different story.

With nvidia GPU in system, and with both open source and proprietary drivers, this is the situation:

  1. Testing methofology was, open Nemo, open VirtualBox window, open "all settings" from right click on taskbar.
  2. Result on AMD card = When it works good, it works very good, when it starts to stutter, everything is affected and it is prolongued for X amount of time with almost or constant stutter, untill it randomly stops, and latter randomly starts again.
  3. Result with nvidia card = From the start, Nemo behaviour = it stutters 1-3 times out of 10 openings, almost always unrelated, and when it stutter, it is less visible (but still present), so for example 1st open = good, 2nd = stutter, 3rd = good, 4th = good etc. (it correct itself imidiately). VirtualBox window = never stutter, "all settings" from taskbar = never stutter.

So, it is acceptable behaviour with nvidia, same as it is on another (intel) machine (it is GPU from that PC).

Now, I did not blacklisted Catalyst, can you elaborate on that one? Also, it is much better for me to use proprietary drivers, since i do not have to run scripts for custom resolutions and experience multiple bugs with full-screen aplications and some other reasons also, but, as i said in 3rd post, i was wrong, stutter is there with open source drivers also (I spoke too soon).

So, if you don't mind go in details of how to blacklist (since i do not know what that even means) Catalyst and what is the gain of that etc.?

I suspect that it is connected with power management (as you suggested), and first thing that might be the clue is ATI PowerPlay (or whatever name might be), or some Linux related problem with Power mnmgt. I would prefer to avoid using Powertop and similar things untill we rule out GPU driver problem or even GPU itself (might be not problem with AMD, but the GPU itself = bad power mngmnt. etc.). Let's see first that blacklist thing, if you can go into details?

PS: Problem cannot be with SATA controllers, audio, lan etc., since I've already tried without them (booting from USB).

EDIT: I've set nomodeset, and blacklisted drivers = same result (note drivers was already blacklisted by default in fglrx.conf).

@thirdmortal
Well, it seems that it is GPU after all, but thanks for the input :).

I use Nvidia GTX 770. I might be doing a test with my integrated Intel HD 4000 soon though.

I might be wrong, but I think that I've seen a difference in stuttering with different drivers. the nvidia-340 was fairly unbearable, so I downgraded to 331, and now it seems that it's a bit better.

Also something I tried that I didn't notice in your list: turning off vsync.

Well, i forgot about that, in proprietary drivers V-SYNC is off by default, and i did forced it via Catalyst. In open source however, i did managed to turn it off, but i have no clue now how i did (since xorg configuration seems to ignore it).

I think there is a clue, I've tried "radeon.dpm=0" in grub config, and it works (it means to disable power management for GPU). After that, there is no more stuttering in VBox and "all settings", and nemo works fine most of the time, but obvious problem is consumption and heat (not atm), and it is not full solution, since stutter will evenntually come back for nemo and some other windows, and also go away...

I'm completely lost about what's going on, since it seems that it is connected with power management, for instance, when stutter (while opening nemo and vbox without "radeon.dpm=0") kicks in, if i catch GPU via terminal, clocks are in lowest 2D mode, while when it doesn't stutter, clocks ur up (in 3D mode). So, apart from potential problem with power management on GPU or who knows where, there might be a problem with nemo/cinnamon itself for power management. I will investigate this problem on other PC, and see if i can replicate it,

Try to force 3D clocks on GPU, and if you can, post the results (idk how to do it with nvidia, I assume you can do it with similar command in grub "nvidia.dpm=0" or something like that with open source drivers).

It just means that you're on a kernel older than 3.17 I think. There was a warning issued against using such old kernels on modern systems for power management purposes, but I don't remember which company issued it to be honest, because my oldest kernel currently in use is 3.19, so it didn't concern me.
Maybe google it or something if you want the DPM, but not the stutter.
I'm sorry but I really forgot where I read it. As far as I remember, on nVidia, DPM for nouveau will be partly integrated for the latest chips in kernel 4.0, and is partly integrated for older chips, with the last card with full integration being the 9800GTX/240GT card I think, on AMD, everything should work with kernel 3.18 in terms of DPM, with partial integration from 3.17, and improvements on 3.18 and 3.19, with more improvements and the new driver framework on 4.0, and on Intel, most DPM functions work from 3.17, except on Haswell, Broadwell, Skylake, etc... which will only be fully integrated on 4.0.

Well, before I've tried other versions of kernel (las via mint updater 3.16.x-x) and it didn't change anything, but, I've tried 3.19.something on your suggestion, and it is still the same (except that driver compatibility is broken or it doesn't work well with mint and p. drivers). However that suggestion might be good for wkpsfbx (newer hardware).

But, I'm very positive that it is either GPU (or combination of things = incompatibility) hardware problem, not specific to AMD/Intel/nVidia, or software bug connected with cinnamon and/or some other programs in Mint. But i suspect it is the first one, since similar problem is in windows also (eg: firefox get laggy and "bugged" from time to time, even with one tab opened, and simple scrolling becomes very unresponsive).

Obviously it is better without DPM, but limited to open source drivers (since i can't figure out how to disable DPM on p. drivers), but, it is not solution anyway. I've tried also some beta drivers, and some older drivers in combination with different kernels, and successfully screw*d Mint installation to the point i had to re-install :).

Goodwork;

There was a hint in one of the posts earlier.
Someone mentioned something about a sound device? lol

Welcome to linux ;)

Well, it have nothing to do with soundcard to my knwledge, snce same behaviour happens with card disabled :).

With kernel 3.16 it is better, but not perfect, it is problem with power management (or hardware related), i dont think i would solve this problem untill complete change of hardware.

PS: Since i had (bad) habbit to turn off HW acceleration in firefox (from Windows), i did not even think about it, done it automatically, so firefox had to behave as cinnamon suggest (for power mngmnt), now, i have it on, and it output same behaviour as audacious give to env.,

Ah okay, I have seen driver conflicts quite often in Mint, some of which cause anomolous annoyances like GPU stuttering. Hence my PCI config space hex dump comment - to be sure it's unrelated.

I have an update for this problem. While problem with occasional stutter is probably related with power management (GPU most likely, since it works fine when it si disabled), the problem of stuttery mess after idle time of "X" hours is there on another computer also. When it starts to stutter, if i bring system to sleep mode, even after resume it stutters, untill restart.

What i do different then most of the instalations, i can't think of much, but this is for sure different then majority of users:
1. I put static IP on network, DNS etc. included.
2. I have custom resolutions and refresh rates on both machines.

This is bug with Cinnamon it seems? I would report a bug, but i need to specify it.
@Zoltan Update, read please,

have you tried gnome or vanilla ubuntu to see if the same thing happens?

since you have mentioned that you did have something similar in windows to this i would be checking to make sure your bios is up to date.

it is also super rare but there can be bios/firmware updates for the vid card as well. it may be worthwhile checking this out as well before going down the rabbit hole.

Oh, i feel like an idiot now.
@Zoltan @wkpsfbx
Problem is solved (on both machines). I thought I've tried this, but apparently, i did not. Anyway, solution is to add lines in /etc/environment:
CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=False (note i use false because high refresh rate).

Obviously, it is connected with power management, it seems CLUTTER_PAINT have effect on it, and because GPU keeps it in memory, opening of new window does not raise GPU clocks and voltages and forces usage of RAM instead of VRAM, and who knows what else. Obviously, after lock screen and idle time for a few hours (or less), everything is stored somewhere in RAM (that's why sleep mode does not have effect, and computer continue to stutter).

Now everything works perfectly on both machines, and even better on AMD GPU. My fault i did not tried this before (even tho i still think i did, maybe I've done something wrong first time), but, misconception comes because people think that is tearing, but in fact, it is not tearing but stuttering (you can find this solution connected with tearing, that's where i found it on some forum).

1 Like

Well, that made my window movement significantly smoother as well. I don't want to celebrate too early, since it has occasionally worked before. But looks promising.

I also set vblank to true and it solved my screen tearing. So that's two fixes with the price of one :)