Welcome!

Please read this important information about MX sources lists.
News
  • MX Linux on social media: here
  • Mepis support still here
Current releases
  • MX-16.1 release info here
  • antiX-16.2 release info here
New users
  • Please read this first, and don't forget to add system and hardware information to posts!
  • Read Forum Rules

MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

Message
Author
User avatar
MX-16_fan
Forum Regular
Forum Regular
Posts: 287
Joined: Mon Feb 13, 2017 12:09 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#11 Postby MX-16_fan » Fri May 19, 2017 1:24 pm

skidoo wrote:
if anything moves to swap, and swap is on the usb, you get a double hit.
other factors that most would-be micromanaging tweakers neglect to consider when they post:
-- messing with zram
-- setting swappiness to 90 (OMG, asinoro posted that as a "tip")
-- writing to savefile residing on a FAT32 -formatted LiveUSB


Sorry, skidoo, I don't get it, are these three a recommendation, or just tips you're mocking about because you think that they don't do the job?

I will be happy to work myself through all recommendations as soon as I know which are serious and which aren't :number1:.


Greetings, Joe
Last edited by MX-16_fan on Fri May 19, 2017 1:48 pm, edited 2 times in total.

skidoo
Forum Regular
Forum Regular
Posts: 495
Joined: Tue Sep 22, 2015 6:56 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#12 Postby skidoo » Fri May 19, 2017 1:39 pm

Any idea what I can do about this?
Scusa if this post doesn't suit your system specs or usage requirements.
Here are my suggestions for BestPractices:

-- host your LiveUSB on an ext4 formatted partition

-- forego use of "atime" mount option for the boot partition (done. handled per antix liveboot defaults)

-- use dynamic (non-static) persistence... and for peace of mind, whenever possible, power your rig via a UPS

-- unless your rig is memory-limited, set swappiness to 1 (and/or forego use of swap altogether)

-- (minimal performance impact, but) unless your rig is memory-limited, forego use of "zram"

-- if your system has plentiful RAM, include "toram" arg in your bootline (Yah! Livin' in a ramdrive! warpspeed!)

Also, each time I put an additional pendrive into service as a liveboot device, I benchtest its performance.
How you choose to benchmark is up to you ~~ I'm just pointing out that some devices are "keepers", others are not.
Same brand, identical model... doesn't matter (isn't a reliable predictor). I always benchtest.

There's also a setting in Firefox/Chrome where you can adjust how often it backs up its state
Thanks, Stevo! That's an important tweak, IMO, and my quoted post had neglected to mention it.
In firefox about:config the prefkey name is browser.sessionstore.interval and milliseconds is the unit value.
Even though its drive access is moot in a dynamic persistence scenario, I set mine to "120000" (every two minutes)

skidoo
Forum Regular
Forum Regular
Posts: 495
Joined: Tue Sep 22, 2015 6:56 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#13 Postby skidoo » Fri May 19, 2017 1:50 pm

I asked lshw-gtk for the CPU's SKU but it doesn't know it.
I don't have "lshw-gtk" installed in antix. `lscpu` at a terminal prompt will show CPU family, model, name (what you're referring to as "SKU"?), stepping...

User avatar
MX-16_fan
Forum Regular
Forum Regular
Posts: 287
Joined: Mon Feb 13, 2017 12:09 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#14 Postby MX-16_fan » Fri May 19, 2017 1:57 pm

skidoo wrote:
I asked lshw-gtk for the CPU's SKU but it doesn't know it.
I don't have "lshw-gtk" installed in antix. `lscpu` at a terminal prompt will show CPU family, model, name (what you're referring to as "SKU"?), stepping...


https://en.wikipedia.org/wiki/Stock_keeping_unit. The above-mentioned article mentions the SKUs of the CPUs that had issues. Greetings, Joe

User avatar
MX-16_fan
Forum Regular
Forum Regular
Posts: 287
Joined: Mon Feb 13, 2017 12:09 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#15 Postby MX-16_fan » Fri May 19, 2017 2:13 pm

@skidoo:

skidoo wrote:
if anything moves to swap, and swap is on the usb, you get a double hit.
other factors that most would-be micromanaging tweakers neglect to consider when they post:
-- messing with zram
-- setting swappiness to 90 (OMG, asinoro posted that as a "tip")
-- writing to savefile residing on a FAT32 -formatted LiveUSB


Again, is this serious advice, or are you just kidding here?

skidoo wrote:Joe, in another topic we've already done "the cpufreq dance" and I reported that I found ZERO benefit from (installing extras and) tweaking the defaults. On that subject, I have nothing further to add here except to point out "c'mon... cpufreq cain't hardly be the limiting factor related to slow pendrive write operations"


Might be, but it still is very strange that xfce-cpufreq-plugin shows such a lot of nonsense. E.g. presently it shows me that two cores have 1.62 Ghz as available frequency, whereas the others have 1.58 available, this whole thing being while it claims that all four cores are running on "performance". Haha. Either xfce-cpufreq-plugin gets everything wrong, or the system does nonsense with the CPU.

skidoo wrote:
firefox does a lot of writes to disk.
Yep. Lookit here


to avoid the continual disk i/o, all you need to do is change a firefox preference, instructing the browser to write to tmpfs

prefkey:
browser.cache.disk.parent_directory
value:
/tmp/happyfox

note: No need to manually mkdir whatever subdir under /tmp. As needed, firefox will create it.


Very good piece of advice, thank you ever so much. While still being far from what I would expect, this speeds up my system by approx. 50%. However, the other issues remain, unfortunately.


Greetings, Joe

User avatar
MX-16_fan
Forum Regular
Forum Regular
Posts: 287
Joined: Mon Feb 13, 2017 12:09 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#16 Postby MX-16_fan » Fri May 19, 2017 2:26 pm

Stevo wrote:You can turn p-state off with a kernel boot cheat, "intel_pstate=disable"


Thanks a lot, I'll try that out anyway. I guess at least it's worth trying, given the fact that there is an endless Ubuntu thread where people propose that intel_pstate should be disabled by default. Where would I have to add this "intel_pstate=disable"?

Stevo wrote:There's also a setting somewhere in Firefox/Chrome where you can adjust how often it backs up its state--the current (15 second?) setting ends up writing many GB to the drive over time, and that worries a lot of SSD owners.


I already thought about that. I refrained from that because according to the discussion here: https://www.servethehome.com/firefox-is ... to-fix-it/, it is not quite clear whether the value you have to change is in microseconds or miliseconds. I'll try it out anyway (using 60000).


Greetings, Joe

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 12876
Age: 58
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#17 Postby Stevo » Fri May 19, 2017 2:53 pm

MX-16_fan wrote:
Stevo wrote:You can turn p-state off with a kernel boot cheat, "intel_pstate=disable"


Thanks a lot, I'll try that out anyway. I guess at least it's worth trying, given the fact that there is an endless Ubuntu thread where people propose that intel_pstate should be disabled by default. Where would I have to add this "intel_pstate=disable"?

Stevo wrote:There's also a setting somewhere in Firefox/Chrome where you can adjust how often it backs up its state--the current (15 second?) setting ends up writing many GB to the drive over time, and that worries a lot of SSD owners.


I already thought about that. I refrained from that because according to the discussion here: https://www.servethehome.com/firefox-is ... to-fix-it/, it is not quite clear whether the value you have to change is in microseconds or miliseconds. I'll try it out anyway (using 60000).


Greetings, Joe


You can test it first by hitting "e" on the GRUB menu screen and then adding the cheat intel_pstate=disable next to the quiet parameter. It can be added permanently by using the GRUB configuration utility or manually editing /etc/default/grub and adding it to the GRUB_CMDLINE_LINUX_DEFAULT line.

The Liquorix kernel maintainer has been switching p-state as default off and on for the last few releases; I've also noticed that the CPU frequency is reported a bit off by p-state--by about 100 MHz, so it reports as 499 instead of 400. Or else the scheduler is not dropping it down to the lowest speed, as he's trying to work out some issues with the new MuQSS scheduler and what's getting reported to the monitor applications. I can't see any difference in the CPU temperature or battery life between the two power managers on my machine with the same load, though.

Edit: The tlp utility also offers many manual configuration settings. http://linrunner.de/en/tlp/docs/tlp-configuration.html We have it in the test repo.

skidoo
Forum Regular
Forum Regular
Posts: 495
Joined: Tue Sep 22, 2015 6:56 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#18 Postby skidoo » Fri May 19, 2017 5:10 pm

Joe, I wasn't mocking you. Wasn't even "mocking" asinoro ~~ I refrained elsewhere from posting to counter his "tip" (if it works for him, um... bless his heart, but I'm uncomfortable seeing that "tip" stand unchallenged). I was pointing out that even though you've provided plenty of details (including some superfluous considerations, like cpufreq) your successful troubleshooting will probably require tweaking/retesting of numerous factors, one-thing-at-a-time. Specific to swappiness... based on my prior testing, I was suggesting to set swappiness to 1 (NOT 90, as you may have read as a "tip" elsewhere in this forum).

it is not quite clear whether the value you have to change is in microseconds or miliseconds. I'll try it out anyway (using 60000).
I included that detail in my earlier post "milliseconds... I set mine to 120000 (two miniutes)"
but understandably easy to overlook that among the "too many words".

never totally understood the "persistence" concept

During a liveboot session, we're dealing with a "layered filesystem".
First, a base layer, populated from the content read from the linuxfs file is generated, then

if dynamic root persistence was requested (otherwise, skip this step),
a layer populated with the content of the rootfs savefile (perhaps currently empty/blank) is added atop the first, then

Finally, a blank layer which will serve as a (writable) session scratchpad is added atop the stack.

-=-

Throughout the session, in response to each file read/write request:
If home persistence was requested, and the affected file is pathed under /home, it is DIRECTLY read from, and written to, homefs storagefile
(else if) STATIC root persistence was requested, the changed file is directly, immediately, written to, rootfs storagefile.
Otherwise, the filesystem "consults the stacked layers".

When a file residing in the stack is modified (created, edited, deleted) during the session, that change is recorded to the top layer.

Each time the filesystem "consults the stacked layers" to retrieve a file, the record in the top layer takes precedence.
If a requested file is present (AND has not been "marked deleted") in the top layer, the filesystem retrieves it and.. done.
(else if) it is present in the populated-from-rootfs layer (AND is not "marked deleted") the filesystem retrieves it and.. done.
(else) the filesystem retrieves the file from populated-from-linuxfs layer (OR reports "file not found")

-=-

During a "persist-save" operation, the content of rootfs file is updated (is `rsync` -ed) to match the current state of the top layer.

User avatar
Jerry3904
Forum Veteran
Forum Veteran
Posts: 18568
Joined: Wed Jul 19, 2006 6:13 am

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#19 Postby Jerry3904 » Fri May 19, 2017 5:23 pm

Is the word "stack" just a metaphor? Or are there *really* linked components that rise "up" from kernel space to user space? (Been wondering that every since I started mucking around in the bluetooth stack.)
Production: 4.7.0-0.bpo.1-amd64, MX-15 RC1, AMD FX-4130 Quad-Core, GeForce GT 630/PCIe/SSE2, 8 GB, Kingston SSD 120 GB and WesternDigital 1TB
Testing: AAO 722: 3.16-0-4-686-pae. MX-15, AMD C-60 APU, 4 GB

skidoo
Forum Regular
Forum Regular
Posts: 495
Joined: Tue Sep 22, 2015 6:56 pm

Re: MX-16 issue: Super low performance and CPU governor / frequency issues on DELL 3150 (Silvermont / Bay Trail-M)

#20 Postby skidoo » Fri May 19, 2017 5:59 pm

Yes, a metaphor.
IIRC, throughout the aufs docs and overlayfs docs, the term used is "branch" (not "layer").

During live init, content of linuxfs is copied to a tmpfs mountpoint, and content of rootfs is copied to /ThatMountpoint/live/aufs
then a pivot_root (chroot to ThatMountpoint) is performed.

FWIW, as root/sudo, you can browse the files written into the the session layer (er, branch) @ /live/aufs-ram
Any ".wh.somefilename" therein represents a same-named file in a lower branch which has been "marked deleted".
(mnemonically, the ".wh" prefix stands for "whiteout")
Although mere mortals aren't s'pposedta manually meddle with the files pathed there,
heh heh heh... even without a ".Trash", by selectively deleting .wh. files, you can surgically UNdelete files which were written during an earlier session (or existed in the linuxfs) that you've mistakenly deleted during the current session.


Return to “Software / Configuration”

Who is online

Users browsing this forum: No registered users and 1 guest