Если я правильно вас поняла, вам нужно монтировать в fstab например по uuid. https://wiki.archlinux.org/index.php/Persistent_block_device_naming
vasek
и не понятное мне высказывание

you can do this if you have two way crossfire and if your video cards do they usally come with a cord to hook them together and then you could probably run them with one hdmi cord but they have to be two way cross fire

Это про две дискретные видеокарточки, https://ru.wikipedia.org/wiki/AMD_CrossFireX.
vasek
Не ставят на ноутбуки такие вентиляторы, которые при полной загруженности процессора обеспечат нормальную температуру.

Понятно, вот только у меня вовсе не ноутбук, а обычный десктоп))) И обороты вентилятора регулируются не скачками, а плавно, вот сейчас, наапример - 1991 RPM, два ядра загружено, температура процессора 45 градусов.

vasek
запусти для надежности dstat или что похожее, если conky врет.

Именно это я и собираюсь сделать, когда баг снова появится. Именно про это я в первом посте и спрашивала, помните? Про дополнительные мониторинговые утилиты.
vasek
Не заметил эту фразу. Тогда точно нужно искать, виновника.

Или это я так непонятно пишу, или это вы ну очень невнимательно читаете :) Торможение системы наблюдается когда система по горло занята, например, компиляцией на всех ядрах. Тогда стопроцентная загрузка всех ядер показывается и в conky, и в прочих утилитах, htop, top, qps. И да, если в этом случае conky выключить, торможение все равно будет продолжаться))) А баг, описанный в первом посте, систему не тормозит, и вообще никак не проявляется, кроме как в коньках.

vasek
при длительной работе на максимальных оборотах температура должна быть близка к максимальной

Не поняла, это почему? Вроде система охлаждения должна поддерживать не максимальную температуру, а оптимальную? Tjunction это вроде бы температура, при которой начинается троттлинг, доводить до нее хорошая система охлаждения никак не должна, а уж тем более до критической.
vasek
Значит с большой долей вероятности можно предположить, что так называемой нагрузки на процессор нет и нет смысла ее мониторить.

Какой-то странный у вас вывод, "чего я не вижу, того не существует" :) . Просто у меня довольно хороший вентилятор процнссора, который умеет менять свою скорость. В обычном состоянии температура процессора около 40 градусов и вентилятор может даже совсем остановиться, а под серьезной нагрузкой, например, когда я компилирую что-то большое вроде хромиума, вентилятор разгоняется на полную, и температура процессора при этом около 50 градусов. И что, это значит, что нагрузки нет? Еще как есть, вся система притормаживает!

Я прекрасно понимаю, что точных значений нагрузки процессора добиться сложно, я и не использую абсолютные значения, мне достаточно приблизительных. А именно - если процессор совсем не занят, значит, можно запустить тяжелое многопоточное приложение, если занято несколько ядер, но не все, значит, можно продолжать работать в обычном режиме и даже видео запустить, если занято одно ядро, значит, можно занять ещё несколько, если занято все на полную, лучше сходить кофейку выпить. Часто у меня в фоне рендерятся несколько разных видео на разных ядрах, а иногда что-нибудь собирается многопоточно на всем процессоре сразу, и все это я мониторю одним взглядом на коньки. Так что мне представление нагрузки каждого ядра нужно, я этим пользуюсь!

Извините за много букв)))

PS Статья довольно интересная, но для меня лишена практического смысла, какая мне разница, показывает монитор фактическую нагрузку процессора или бутылочное горлышко в памяти? Все равно я рассматриваю это именно как комплексное показание загруженности всей системы.
Посмотрела ваш makepkg.conf, от моего не сильно отличается. У вас -j5, у меня -j2, ну и еще по мелочам... В любом случае у меня аномальная активность показывается и тогда, когда ничего не собирается, и когда ничего вообще не происходит. Все жирные программы закрыты, все лишние демоны остановлены, фактически только openbox и conky запущены, и коньки показывают это чудо, а все прочие мониторы, если их запустить, не показывают.
Вот мой конфиг, часть про процессор:

${voffset -3}${GOTO 39}${color3}CPU1:${color}${GOTO 100}${cpubar cpu1 10,115} ${cpu cpu1}%${GOTO 250}${color3}@${color}${freq_g 1} GHz${GOTO 100}${cpugraph cpu1 10,115 555555 11aaff}
${voffset -3}${GOTO 39}${color3}CPU2:${color}${GOTO 100}${cpubar cpu2 10,115} ${cpu cpu2}%${GOTO 250}${color3}@${color}${freq_g 2} GHz${GOTO 100}${cpugraph cpu2 10,115 555555 11aaff}
${voffset -3}${GOTO 39}${color3}CPU3:${color}${GOTO 100}${cpubar cpu3 10,115} ${cpu cpu3}%${GOTO 250}${color3}@${color}${freq_g 3} GHz${GOTO 100}${cpugraph cpu3 10,115 555555 11aaff}
${voffset -3}${GOTO 39}${color3}CPU4:${color}${GOTO 100}${cpubar cpu4 10,115} ${cpu cpu4}%${GOTO 250}${color3}@${color}${freq_g 4} GHz${GOTO 100}${cpugraph cpu4 10,115 555555 11aaff}

Впрочем, когда мой баг проявляется, я пробовала упрощать вообще весь конфиг до

${cpu cpu1}
${cpu cpu2}
${cpu cpu3}
${cpu cpu4}

и ничего не менялось, то есть загрузка одного ядра все равно была видна, так что конфиг скорее всего не причем :)
Мышепрозрачность отвалилась ещё в версии 1.10.6 или около того. А мой баг у меня по-моему с версии 1.9, а может и раньше. Я все ставлю новые версии с надеждой, что он наконец уйдет, пробовала собирать различные версии из аура, опять возвращалась к стандартной... А баг и ныне тут :)
Нет, не то, я переписала конфиг в новом формате как только он появился...
Это косвенно подтверждает версию бага в коньках.