Phenom’енальный шестичлен: первые впечатления

Автор: Алексей Федорчук

Вот и наступил момент первого запуска машины уже с какой-нибудь ОСю. В качестве таковой я избрал LiveCD RFRemix 14 — в первую очередь меня интересовало, как он будет взаимодействовать со встроенным видео от AMD. На счёт остального как-то сомнений не было. Для первого раза никаких настроек в BIOS’е я не трогал, кроме включения загрузки с внешнего USB-сидюка, ибо другого у меня в хозяйстве не было.

Оказалось, что с видео всё хорошо: к нему автоматически подцепился свободный иксовый драйвер radeon, распознавший видеочип как Radeon HD4250, установив правильное (то есть соответствующее матрице дисплея) разрешение и ту глубину цвета, которую GNOME’вская утилита настройки видеосистемы задумчиво называет Миллионы цветов.

Тут я таки решил поглядеть, что делается в BIOS’е относительно разделяемой видеопамяти — той, которая отрезается от общего ОЗУ; как я уже говорил, собственной набортной памяти моя мама не имеет. Согласно документации, BIOS поддерживает до 512 Мбайт shared memory, но меня интересовало как раз наименьшее значение — в игры я не играю, а более она, вроде, ни для чего в таком количестве и не требуется.

Оказалось, что минимально возможно отдать под видеопамять 32 Мбайт. Причём по умолчанию этот параметр был установлен в положение Auto. Согласно как показаниям BIOS, так и выводу команды

$ dmesg | grep VRAM

В моём случае это самое Auto составило 256 Мбайт. Что мне показалось роскошью, более чем излишней, и я, по старой привычке свёл этот параметр к минимуму — 32 Мбайт.

Каково же было моё удивление, когда при следующей попытке загрузиться с того же LiveCD я сначала не увидел стартовой сплэш-картинки — вместо него вывелась бегущая полоска. Это бы ладно — нежных чувств к сплэшам я не испытывал со времён пользования Archlinux’ом (кто-то из его разработчиков метко сказал, что для изготовления сплэша, помимо всего прочего, требуется ещё и some time to kill). Но система отказалалсь загружаться в графическом режиме вообще: то есть окно авторизации Gdm мелькало на экране считанные секунды, потом исчезало, появлялось на мгновение вновь — и так до бесконечности. Так что, до лучших времён изучения BIOS я вернул умолчальное значение Auto — и всё стало нормально.

Оценивать производительность машины по LiveCD — занятие бессмысленное (а в отношении традиционно задумчивых LiveCD от Fedora — бессмысленное вдвойне). Так что настало время для установки системы. Как легко догадаться, ею стала та же самая Fedora в варианте RFRemix 14, и устанавливалась он а с того же LiveCD по методике, описанной здесь.

Установка проводилась на SSD, который я на этот раз разметил как единый раздел (почему — скажу со временем). Тем не менее, на всякий случай выполнил выравнивание, согласно сказанному здесь. Он выступает у меня как системный и одновременно — как носитель текущей работы.

Отступление: тут мне подумалось — а не пора ли, при использовании SSD, отказаться наконец от разметки в стиле MBR и перейти на таблицу разделов GPT (GUID Partition Table)? Уж больно первый выглядит архаичным даже для современных винчестеров, не говоря уже о твердотельных накопителях. Однако не рискнул, так как не успел в должной мере ознакомиться с вопросм. Буду признателен за любые соображения по теме, основанные на личном опыте.

На втором диске (напомню — обычном SATA-винчестере объёмом 160 Гбайт от Samsung’а) я сделал:

• символический раздел подкачки в 1 Гбайт (чисто для страховки, при восьми гигабайтах памяти вероятность его использования видится мне пока сомнительной — но чёрт его знает, что будет при активном запуске виртуальных машин);
• раздел на 100 Гбайт в качестве промежуточной файлопомойки (как основная свалка парнухи, напомню, у меня выступает внешний терабайтник);
• оставшиеся 50 Гбайт с копейками я оставил неразмеченными на предмет экспериментов с файловыми системами, ибо не теряю надежды опробовать ZFS в нативном исполнении для Linux (благо, способ такой ныне существует).

Установка прошла без всяких проблем, в том числе и в отношении видеосистемы: как и при загрузке с LiveCD, разрешение и цветность установились как надо — и всё это посредством стандартного драйвера radeon, без малейшего проприетарного calalist’а. Никаких тормозов в 2D-графике не отмечалось.

Для грубой оценки возможностей в 3D я использовал tuxracer’а — единственную игру из этой оперы, которой изредка балуюсь — да и то обычно в тестовых целях, как сейчас. Что же, и здесь свободный драйвер показал себя достойно: герой-пингвин подбирал рыбку с заснеженных склонов ничуть не менее справно, чем он делал это на чипе Nvidia с драйвером проприетарным.

Наконец, фильмы в формате HDTV воспроизводилось в Gnome-mplayer’е без малейших проблем в обоих вариантах — 720p и 1080p, а про стандартные avi’шки и говорить нечего. Впрочем, воспроизведение HDTV зависит не только от видеосистемы, но и от процессора, так что к этому вопросу мы ещё вернёмся.

Таким образом, можно констатировать, что для пользователей видеочипов AMD, не являющихся закоренелыми игроманами и не занимающимися профессионально 3D-графикой, необходимости в установке фирменных драйверов ныне нет — в отличие от недавнего ещё времени, когда свободный драйвер не обеспечивал даже полноценной работы в двухмерном режиме.

Вообще, с видеокартами ATI/AMD у меня давние счёты — но это тема отдельной беседы. А пока остаётся только порадоваться, что они, похоже, остались в далёком прошлом.

Закончив вчерне с видеосистемой, я решил поглядеть, как ведёт себя процессор с точки зрения тактовой частоты и использования ядер при типичной у меня рабочей нагрузке. Каковая определяется следующим приложениями, раскиданными по шести рабочим столам:

• терминальным окном с 3-5 вкладками;
• файловым менеджером Nautilus, обычно содержащим 3-4 вкладки;
• Gnome-mplayer’ом, воспроизводящим flac-музыку;
• текстовым редактором Geany, в котором сочиняются эти строки;
• браузером Firefox с десятком сайтов, открытых в отдельных вкладках;
• torrent-клиентом Transmission, работающим на раздачу беспрерывно, на скачивание — время от времени;
• IM-клиентом Empathy.

К этому непременному списку в данном случае следует добавить системный монитор из штатного комплекта GNOME.

По умолчанию процессор используется в режиме On Demand (по требованию), то есть тактовая частота всех его ядер динамически изменяется в зависимости от нагрузки. Отслеживать её можно с помошью апплета, который так и называется — Монитор изменения тактовой частоты процессора. Правда, в каждый момент времени он может показывать частоту лишь одного из ядре. Тем не менее, переключая их, можно составить качественное представление об изменении частотных характеристик всех.

Так вот, большую часть времени любое ядро функционирует на тактовой частоте 800 Мгц, изредка подскакивая до номинального предела — 3,2 Ггц, и ещё реже выходя на промежуточные значения — 1,2 и 1,6 Ггц.

Нагрузка на ядра сильно меняется, типичный моментальный снимок можно видеть на этом скриншоте:

Каковой демонстрирует, что основная нагрузка падает на первые три процессорных ядра, но и последняя их тройка тоже задействется. Интересно, что при прокручивании HDTV через Gnome-mplayer нагрузка на первые два ядра иногда возрастает до 25-30%, на остальные же остаётся без изменений.

Ну а субъективные впечатления от быстродействия системы превосходят любой уровень восторга. Хотя изрядная его часть — заслуга не только «железа», но и дистрибутива.

Что же до того быстродействия, которое может быть представлено в числах, то оно будет предметом следующего цикла заметок.