Constant microfreezes causing choppy performance

korax_nyx · 2020-12-14 12:15:31

Hi, I recently installed Bunsenlabs Lithium and I can not figure this problem by myself. I googled several solutions (listed below) but I did not have any success.

Recently I purchased a Chuwi Herobox, Mini PC with Celeron n4100, 8 gigs of ram, a decent SSD and an Intel HD 600 integrated graphic card. I know it's not a workhorse, but I only need it for writing and light web browsing.

The machine came with Windows 10 and everything worked smoothly. I removed Windows and installed Bunsenlabs, everything but the WiFi works well, but my main problem is this:

Every 10-15 seconds, the system freezes for like a second and then returns to normal, so the performance is choppy.

It's not totally incapacitating but it's very annoying to feel that microfreeze all the time. For example, if I'm writing, it freezes every 10 seconds and then it abruptly spits all that has been written during that second.

For now, I've tried these options without success:

- Removing xserver-xorg-video-intel.

- Updating to a more current version of the kernel (5.9), nothing changed and WiFi card keeps showing awful performance too.

- Deactivating the compositor (I'm using a forked Picom and I thought that could be the problem, but switching off the compositor did nothing).

So no matter what I do, every 10-15 seconds I have that 1 second freeze.

If someone has any insight, I would be so grateful. I'd like to keep Bunsenlabs, but I tried a live session with Pop Os (Ubuntu based) and it did not seem to have this problem :-/

Thanks in advance, best regards.

Last edited by korax_nyx (2020-12-14 12:20:03)

sleekmason · 2020-12-14 13:17:56

Ouch! Sorry to hear you are having issues!

Did you use ext4 when installing?

Can you post the output of:

sudo journalctl -b

after a fresh reboot in code tags please. (hi-light text and hit code above).

Last edited by sleekmason (2020-12-14 13:20:04)

rbh · 2020-12-14 13:31:41

I guess this is your box: https://www.chuwi.com/product/items/Chuwi-Herobox.html.

command "inxi -Fz", vill list your hardware and loaded drivers.

Have you checked your logs?
Have you monitored your pc, to se what happens just before freeze (used glances or monit)

Have you tested runing BL in live mode. Runing Debian live iso?

Have you searched the Chuwi support-forum?

unklar · 2020-12-14 14:10:56

^I think it would be more purposeful if instead of posting the entire journal, he tries to analyze the 10-15Sec. freeze using the following command:
Open a terminal and type

sudo journalctl -af

the terminal stays open and he continues working until the freeze occurs. These last 10-20 lines in the terminal should get closer to the error. Exit with Ctrl+c
The whole thing can also be additionally written to a file for the forum:
e.g.

sudo journalctl -af > /home/$User/freeze.txt

Hardware errors should also be detected with the command

sudo dmesg --color=always | less -R

because they are displayed in red here.

sleekmason · 2020-12-14 14:51:41

unklar wrote:

^I think it would be more purposeful if instead of posting the entire journal, he tries to analyze the 10-15Sec. freeze using the following command:
Open a terminal and type
sudo journalctl -af
the terminal stays open and he continues working until the freeze occurs. These last 10-20 lines in the terminal should get closer to the error. Exit with Ctrl+c
The whole thing can also be additionally written to a file for the forum:
e.g.
sudo journalctl -af > /home/$User/freeze.txt
Hardware errors should also be detected with the command
sudo dmesg --color=always | less -R
because they are displayed in red here.

Ha! Very nice:)

rbh · 2020-12-14 15:44:37

unklar wrote:

sudo journalctl -af > /home/$User/freeze.txt

Yes, that is better.

Hardware errors should also be detected with the command
sudo dmesg --color=always | less -R
because they are displayed in red here.

But not only error is colored red on my boxes. I have enabled color output in terminal if that maybe makes difference. I add -T to dmesg, to get human readable timestamps:

[mån dec 14 02:35:37 2020] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-0.bpo.2-amd64 [cut]

The first column (the timestamp), is green. The second ("label", above "Kernel command line:") is red. The third column (information), is red if errors, else white.

Last edited by rbh (2020-12-14 16:52:35)

korax_nyx · 2020-12-14 16:21:19

Hi, and thank you very much to all for the tips.

journalctl does not seem to provide much info during those microfreezes (I said a second, but maybe they last less than that, it's like a stutter and journalctl does not seem to say anything, but I could paste the code anyways).

Using dmesg does not show any special error during those moments either.

Monitoring the activity with htop, as RBH said, and filtering by CPU% usage, when the stutter happens, this process jumps almost always to the top or suddenly it uses a lot of CPU (25%, 30% or even more) during that brief moment, returning to very low numbers after that half second.

/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

I know it's an essential process and maybe it's normal, but I'm just a noob and I don't know much about its behaviour. If it's normal, I can paste the journalctl or dmesg but I think they just don't give any special information during those brief freezes.

Thank you very much for your time, really.

rbh · 2020-12-14 17:14:59

No, I did not recommend htop.
Both monit and glances does more than monitor processes cpu and memory consumtion, like top and htop.

Glances monitor also disk writes, cpu iowaite etc. You can start it in "servermode" and connect from other (well working) computer.

What about running BL and Debian live iso?

korax_nyx · 2020-12-14 18:02:33

Running Bunsenlabs live seems to work better.

I closed almost everything but WiFi on the installed system, in order to run it like the live CD, but it kept doing that 1 second freeze.

Now I'm away from the computer, but I will try those monitoring apps.

Thanks, best regards.

rbh · 2020-12-14 18:34:21

korax_nyx wrote:

this process jumps almost always to the top or suddenly it uses a lot of CPU (25%, 30% or even more) during that brief moment, returning to very low numbers after that half second.

On three of mine boxes, X does not use more than 0.7-2.5 cpu%.
1-10% is normal according to https://wiki.ubuntu.com/X/Troubleshooting/HighCPU.

When you monitored processes with htop, sorted cpu%, did any other process rise when X did?
What about your graphics driver or other drivers?

korax_nyx · 2020-12-14 20:25:04

The other processes that used more CPU were Chrome or Firefox, depending on what I was using to reenact the issue with them. But they were not jumping at the same time, they were fluctuating up and down in their own rythm.

I'll try more things tomorrow since here in Spain is late now.

Thank you very much.

brontosaurusrex · 2020-12-14 20:58:19

If I'd have to guess, I'd blame wifi, try to temporarily disable that.

ohnonot · 2020-12-15 05:23:25

korax_nyx wrote:

journalctl does not seem to provide much info during those microfreezes (I said a second, but maybe they last less than that, it's like a stutter and journalctl does not seem to say anything, but I could paste the code anyways).
Using dmesg does not show any special error during those moments either.

That's sad. I really had hoped for some insight from that. Did you use 'dmesg -w' and 'journalctl -f'?

korax_nyx wrote:

Monitoring the activity with htop, as RBH said, and filtering by CPU% usage, when the stutter happens, this process jumps almost always to the top or suddenly it uses a lot of CPU (25%, 30% or even more) during that brief moment, returning to very low numbers after that half second.
/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

This is an important hint. It means that something that has to do with the graphical desktop is causing the microfreezes.
I think you should take a deeper look what graphical applications are constantly running and which of them follow the same rhythm.
10s? Could be conky, could be Firefox, .......
It could even be your GPU or its driver but somehow I don't think that would show up as Xorg usage, but let's keep an open mind.

rbh · 2020-12-15 12:54:06

korax_nyx wrote:

Running Bunsenlabs live seems to work better.

Have you examined the difference between your install and the live session? What is started in conky, what drivers (esp graphic) drivers are loaded etc?

You can use inxi or download an appimage of hw-probe, the latter gives quite a lot of info.

I closed almost everything but WiFi on the installed system, in order to run it like the live CD, but it kept doing that 1 second freeze.

You closed conky, tint2, browser, run only terminal with tab for htop and tab for giving commands if needed?

Do you have any services running, like apache2 webserver, close them to.

Does the spike for X occur every 15s, even if you leave the computer and only watch?

rbh · 2020-12-15 12:58:23

Btw, have you tested running on cable and not start wiffi?

sleekmason · 2020-12-15 13:24:13

systemctl list-units --type=service --state=running

Will list your running services.

rbh · 2020-12-15 13:36:55

And the command for stopping webserver service is:

$ sudo systemctl stop apache2.service

Sudo is needed as modifing most services needs root rights. When stopped, the service will start after next reboot. To stop apache from starting att all, issue:

$ sudo systemctl disable apache2.service

rbh · 2020-12-15 13:50:18

rbh wrote:

download an appimage of hw-probe, the latter gives quite a lot of info.

I forgot to mention that you need to run the appimage in terminal, pointing to the image:

$ sudo -E ./hw-probe-1.5-149-x86_64.AppImage -all -upload

To get more information read on homepage / run:

$ ./hw-probe-1.5-149-x86_64.AppImage -h | more

korax_nyx · 2020-12-15 18:12:09

Ok, thank you, thank you all very much. I've found the problem.

Following your insights, my tint2 customization causes the microfreezes, while the default tint2 panel of Bunsenlabs did not. That's why the live version runs smoothly.

I'll check the code of the tint2 config in order to find the culprit, but bunsenlabs works very fine now.

I don't know how to thank you, really, I never thought something as simple as tint2 could cause that.

Best regards.

P.S. Sorry for the late answer, I was swamped at work today and I just sat to tinker with my machine after reading all your responses.

Last edited by korax_nyx (2020-12-15 18:14:06)

truscellino · 2020-12-15 18:38:24

There are some profiling instruction on the tint2 wiki. That's another way to get to the bottom of it...
https://gitlab.com/o9000/tint2/-/wikis/profiling

ohnonot · 2020-12-16 06:02:42

korax_nyx wrote:

Following your insights, my tint2 customization causes the microfreezes, while the default tint2 panel of Bunsenlabs did not. That's why the live version runs smoothly.
I'll check the code of the tint2 config in order to find the culprit, but bunsenlabs works very fine now.

Let us know what exactly it was when you find it!

korax_nyx · 2020-12-17 15:37:18

I just copied a nice Tint2 configuration from some other user's Github that I liked, and modified it further to my liking with tint2conf. But I did not see that it was calling a script that I did not have in my machine.

I found it revising the tint2rc line by line in a text editor. That little piece of code lingered there, calling something that did not exist, going nowhere and producing the glitch.

Very rookie mistake when I finally joined the dots :-/

I really appreciate all your selfless help and dedication.

Best regards

Last edited by korax_nyx (2020-12-17 15:37:46)

ohnonot · 2020-12-17 19:42:00

'k thanks!
FWIW, i never use tint2conf, always edit the tint2rc file manually.

o9000 · 2020-12-24 17:36:24

korax_nyx wrote:

I found it revising the tint2rc line by line in a text editor. That little piece of code lingered there, calling something that did not exist, going nowhere and producing the glitch.

Hi Korax,

I would be interested to know what that line was, if you still have it around. Or the original tint2rc source where you found it. I'd like to know what could make a system freeze like that. Thanks.

gargvarun041 · 2021-01-04 10:52:27

I closed almost everything but WiFi on the installed system, in order to run it like the live CD, but it kept doing that 1 second freeze.

#1 2020-12-14 12:15:31

Constant microfreezes causing choppy performance

#2 2020-12-14 13:17:56

Re: Constant microfreezes causing choppy performance

#3 2020-12-14 13:31:41

Re: Constant microfreezes causing choppy performance

#4 2020-12-14 14:10:56

Re: Constant microfreezes causing choppy performance

#5 2020-12-14 14:51:41

Re: Constant microfreezes causing choppy performance

#6 2020-12-14 15:44:37

Re: Constant microfreezes causing choppy performance

#7 2020-12-14 16:21:19

Re: Constant microfreezes causing choppy performance

#8 2020-12-14 17:14:59

Re: Constant microfreezes causing choppy performance

#9 2020-12-14 18:02:33

Re: Constant microfreezes causing choppy performance

#10 2020-12-14 18:34:21

Re: Constant microfreezes causing choppy performance

#11 2020-12-14 20:25:04

Re: Constant microfreezes causing choppy performance

#12 2020-12-14 20:58:19

Re: Constant microfreezes causing choppy performance

#13 2020-12-15 05:23:25

Re: Constant microfreezes causing choppy performance

#14 2020-12-15 12:54:06

Re: Constant microfreezes causing choppy performance

#15 2020-12-15 12:58:23

Re: Constant microfreezes causing choppy performance

#16 2020-12-15 13:24:13

Re: Constant microfreezes causing choppy performance

#17 2020-12-15 13:36:55

Re: Constant microfreezes causing choppy performance

#18 2020-12-15 13:50:18

Re: Constant microfreezes causing choppy performance

#19 2020-12-15 18:12:09

Re: Constant microfreezes causing choppy performance

#20 2020-12-15 18:38:24

Re: Constant microfreezes causing choppy performance

#21 2020-12-16 06:02:42

Re: Constant microfreezes causing choppy performance

#22 2020-12-17 15:37:18

Re: Constant microfreezes causing choppy performance

#23 2020-12-17 19:42:00

Re: Constant microfreezes causing choppy performance

#24 2020-12-24 17:36:24

Re: Constant microfreezes causing choppy performance

#25 2021-01-04 10:52:27

Re: Constant microfreezes causing choppy performance

Board footer