Arial Georgia Tahoma Times New Roman Verdana

Abit SE6 под управлением Linux

О долгожданном чипсете i815, потенциальном преемнике могучего BX, написано уже немало. Достаточно вспомнить обзор на iXBT. Там же появилось уже и несколько обзоров материнских плат на нем. Я же хотел сказать несколько слов о том, как этот чипсет уживается с Linux. Естественно, исходя из собственного опыта, основанного на примере материнской платы Abit SE6, с коей имел счастье (или — несчастье?) пообщаться.

Тактико-технические данные

Эта системная плата основана на модификации i815E и поддерживает, соответственно, ATA/100 и CNR. Есть вариант и для связки ATA/66 и AMR — Abit SL6, несколько более дешевый.

В коробочном варианте Abit SE6 комплектуется (помимо собственно материнской платы):

• двумя IDE шлейфами — восьмидесятижильным ATA/66/100 и стандартным сорокажильным ATA/33, визуально различающимися структурой поверхности (первый — практически гладкий) и цветом разъемов (на восьмидесятижильном шлейфе средний разъем серый, концевые — один черный, другой синий)
• всякого рода дополнительными железяками — задней панелью для корпуса, с соответствующими разъемами, выносным разъемом для COM2, температурным датчиком
• диском с программным обеспечением (для Windows)
• руководством пользователя

По слухам, все системные платы Abit последнее время комплектуются дистрибутивом Линукса собственного изготовления. Однако в моем случае такового не имелось.

На самой плате, кроме набора микросхем логики, присутствуют:

• процессорное гнездо Socket 370, поддерживающее процессоры PIII 500-1000 и Celeron 300A-733
• три DIMM-разъема для памяти PC-100 или PC-133 (66-мегагерцная память не поддерживается), максимальным объемом 512 Мбайт; при этом, в соответствие со спецификацией чипсета, при заполнении третьего разъема (5-6 банки), частота шины памяти, независимо от типа последней, автоматом переходит на 100 МГц
• слот AGP для установки внешней видеокарты соответствующего стандарта или т.н. AIMM-модуля видеокэша объемом 4 Мбайт (опционально, в комплект не входит); впрочем, в руководстве ни словом не сказано о первом варианте
• шесть слотов PCI и ни одного — ISA
• два IDE разъема (поддерживающие ATA/100) и разъем для флоппи-дисковода

Имеется переключатель для грубой установки частоты процессорной шины — 66, 100 или 133 MГц (более точная настройка осуществляется через BIOS). Есть также джампер для сброса CMOS Setup.

В стандартном для АТХ-плат месте смонтированы COM1 и LPT, VGA-разъем для встроенной видеосистемы, разъемы PS/2 для мыши и клавиатуры, два разъема USB, игровой порт и звуковые входы и выходы (Line-in, Line-out, микрофон). Второй COM-порт — выносной, на заглушке вместо слота расширения подсоединяется к коннектору на плате.

Это — из главного. Из архитектурных излишеств имеются:

• слот VL1 (между AGP и PCI) для дополнительной карты, обеспечивающей подключение второго монитора, телевизора или жидкокристаллической панели; разумеется, он может использоваться только при отсутствии внешней видекарты
• слот CNR для мифических (или футуристических) программных сетевых карт, возможно — модемов и прочего; насколько я знаю, пока таких устройств никто своими глазами не видел;
• коннектор для второй пары разъемов USB, выводимых на переднюю или заднюю панель корпуса; впрочем, это опция — самих разъемов в комплекте нет
• всякого рода коннекторы — для пробуждения от модема и сетевой карты, подключения термодатчиков, дополнительных вентиляторов, инфракрасного порта

В общем, имелось, как будто, все необходимое. И даже кое-что лишнее. Оставалось посмотреть, как она, эта мама, работать будет

В составе готовой системы

Плата была установлена в корпус In-Win (с 250-ваттным блоком питания), содержащий уже:

• винчестер IBM-DTLA-307015 15 Гбайт (7200 об. мин, ATA/100)
• CD-RW Mitsumi CR-4802TE (запись/перезапись/чтение — 4/2/8)
• флоппи-дисковод

На саму плату были установлены:

• процессор P-III 733EB (правда, на Лопе де Вега похоже? ;))
• память 128 Мбайт PC-133 производства Micron, вроде бы 8 нс
• видеокарта ASUS AGP-V3800Magic (на Riva TNT2 M64) с 16 Мбайт памяти SDRAM
• звуковая карта PCI неизвестного происхождения на чипе ESS1869
• плата видеозахвата Fly Video на чипе Brooktree Corporation Bt848

К соответствующим разъемам были подключены монитор Acer 76i (17 дюймов), 3-кнопочная мышь Logitech PS/2, клавиатура Mitsumi с таким же разъемом, принтер HP DJ 840, колонки и микрофон без родословной :)

Все это богатство не без успеха питалось от сети очень переменного тока через ИБП APC Back-UPS 300, что и было доказано благополучным включением машины и запуском BIOS Setup.

BIOS платы — Award'овского происхождения. Подробно о нем говорить не буду. Остановлюсь только на наиболее важных моментах, из которых первым по праву (да и по порядку) является фирменная (хотя на этот счет существуют противоречивые мнения) технология Soft Menu, имеющая номер II.

А в ней первым пунктом идет определение процессора. Штатно можно выставить частоты от 300 МГц (при 66 на шине) до 933 (при 133 FSB). Имеется также и частота в 1 ГГц, но частота шины при этом не указана :) Ну и, естественно, есть и User Define.

При штатных частотах процессора и системной шины частота шины памяти может принимать значения 100, 133 МГц и Auto. При последнем варианте в моем случае правильно определилась PC-133 память.

При выборе пользовательского определения частоты процессора активизируется опция ручного подбора частоты FSB. В сцепке с ней в различных сочетаниях меняются частоты шин памяти и PCI. Это имеет, например, такой вид: 133 MГц (4:4:1) — для FSB, SDRAM и PCI, соответственно. Такая установка в моем случае отвечает 733 МГц внутренней частоты процессора, по 133 МГц на шинах системной и памяти. Из чего можно заключить, что за единицу принята частота PCI (33 Mhz), хотя в качестве базовой трактуется частота шины памяти. Что имеет некоторые не очень положительные последствия (о чем — ниже).

Диапазон значений FSB — 66-153 MГц, шаг — 3-5 MГц. В интервале от 66 до 125 MГц FSB коэффициент шины памяти зафиксирован на 3 (то есть 100 MГц при 66 и 100 МГц FSB и соответствующие значения при нестандартных частотах; 66-мегагерцная память не поддерживается еще со времен i810). Начиная со 125 MГц FSB память можно тактировать и как 4. А вот обратный вариант — использование 133 MГц на шине памяти при частоте FSB в 100 MГц — не реализован вследствие архитектурных особенностей чипсета. Хотя, как покажут дальнейшие события, такое сочетание могло бы принести немало пользы. Если память потянет, разумеется…

Следует заметить, что по умолчанию выставлена частота шины памяти в 100 MГц. Что, как будет показано ниже, не есть мудро при памяти PC-133.

Есть возможность изменения множителя шины FSB. Впрочем, как всем понятно, чисто теоретическая: все процессоры Intel уже давно выпускаются с фиксированным коэффициентом умножения.

Имеется и опция изменения напряжения на ядре процессора. Каковой, впрочем, никогда не пользовался, и другим не советую.

Из других (в общем, более-менее обычных для Award) пунктов BIOS Setup мое внимание привлекла возможность определения трех загрузочных устройство последовательно: 1-го, 2-го и 3-го. Каждое из них может быть любым диском (от HDD0 до HDD3), SCSI, CD ROM, ZIP, LS-120, FDD, или быть отключенным как класс.

Долго искал в BIOS возможность отключения встроенного видео. Безуспешно. В пункте, повествующем о встроенной периферии, есть только опция переключения 1-го дисплея — Onboard/AGP или PCI. Здесь, конечно, интересней было бы два "ИЛИ". Но, как показала практика, встроенное видео отключается просто фактом установки видеокарты в слот AGP.

А вот встроенный аудиокодек при использовании внешней звуковой карты нужно отключить явно в уже упомянутом пункте о встроенной периферии — иначе работать внешняя карта не будет.

Операционная система и тесты

Покопавшись с BIOS, перешел к установке системы. Для этого на диске были созданы разделы:

• primary размером 2.5 Гбайт (еxt2fs)
• swap-раздел размером 128 Мбайт
• два extended-раздела (ext2fs) — /usr/local и /home, 1 и 11 Гбайт, соответственно

Устанавливался Linux Mandrake 7.0/RE, содержащий ядро 2.2.14, glibc 2.1.2, XFree86 3.3.6. Использовался SVGA-сервер из комплекта поставки (хотя есть и сервер NVIDIA, специально предназначенный для видеокарт на чипах TNT/TNT2). В XWindow использовалось разрешение 1024х768 при 16-битной глубине цвета.

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

В первую голову это серия глубоко вложенных подкаталогов, содержащих небольшие файлы (HTML, GIF, JPEG, PNG, DjVu), которые посредством скрипта в консольном режиме копируются с места на место. Как ни странно, это, в первую очередь, нагрузка не на диск, а на процессор (включая кэш и системную память) поскольку в UNIX и ему подобных дисковые операции кэшируются в оперативной памяти. Кто не верит — смотрите внимательно на индикатор активности винта при копировании кучи мелких файлов под Linux (суммарный объем их может достигать многих мегабайтов): редко когда загорится красный огонек…

Далее, изготовляется геологическая карта размером 2560*1586 и экспортируется в несжатый TIFF, что дает файл размером 11,6 Мбайт. Этот файл в GIMP (под WindowMaker):

1. поворачивается на фиксированный (90 градусов) угол
2. вращается на произвольный (для определенности и единообразия — 52 градуса) угол
3. подвергается гауссовому размытию с радиусом 10 пикселей.

В чем физический смысл этих, в общем достаточно элементарных, манипуляций? В первую очередь это пересчет пикселей, то есть скорость определяется быстродействием процессорной (в широком смысле слова, включая кэш и системную память) подсистемы. При повороте на произвольный угол (и, в меньшей степени, при размытии) на это накладывается еще и быстродействие видеоподсистемы — изрядную долю времени занимает просто перерисовка экрана. Но при одной и той же видеокарте определяющей является процессорная составляющая. А размер файла подобран (методом ползучего эмпиризма) таким образом, чтобы обеспечить достаточную длительность процесса и при этом свести к минимуму влияние дисковой подсистемы (при данном объеме оперативной памяти индикатор жесткого диска активности не проявляет).

Я не настаиваю на строго количественном характере своих тестов. Но уверен, что качественную оценку чистого быстродействия конкретного железа в реальной работе они дают. Ничуть не менее значимую, кстати, чем кадры в секунду при игре в Quake. Хотя бы потому, что под последний все, кому ни лень, оптимизируют и железо, и драйверы к нему. А вот до подобной оптимизации под Linux-программы мы пока не дожили…

К сожалению, пришлось отказаться от использования в качестве тестовой системы StarOffice (к сожалению — потому что это мог бы быть инструмент межплатформенного сравнения: он существует и под Linux, и под Windows, и под Solaris обоего рода). Дело в том, что измерения посредством его оказались практически невоспроизводимы: скорость загрузки его самого, открытия любого документа или манипуляции с последним, как оказалось, могут различаться буквально на порядки — в зависимости от того, обращаетесь ли вы к этому файлу и операции впервые за сеанс (Linux; не XWindow!) или повторно. Вероятно, опять же, вследствие кэширования. Для чистоты эксперимента это потребовало бы полной перезагрузки системы после каждого действия. А согласитесь, перезагружать Linux по несколько десятков раз на дню — занятие не из самых веселых и полезных для здоровья…

Результаты

Мне не известны результаты тестирования аналогичных (или хотя бы близких) конфигураций под Linux. Поэтому никаких внешних объектов для сравнения у меня нет. Остается прибегнуть к сравнению за счет внутренних ресурсов. То есть — к разгону.

Для начала были опробованы установки по умолчанию — FSB 133 МГц, шина памяти 100 МГц, внутренняя частота процессора 733 МГц. Значения производительности (в секундах) при этих параметрах сравнивались с нормальными рабочими установками — то же, плюс шина памяти на 133 МГц. А затем начинались игры с частотой FSB (и, следовательно, внутренней частотой процессора и скоростью работы памяти). Результаты оказались весьма неожиданными.

Примечание к табл. 1 и 2: меньшие значения, естественно, соответствуют лучшему результату.

Как можно видеть из таблиц, увеличение чистого быстродействия памяти на 1/3 дает прирост производительности от 8 до 26%. При этом он максимален для теста копирования файлов, где быстродействие подсистемы процессор-кэш-системная память не осложняется влиянием графического режима. Для тестов GIMP различия сглаживаются, как уже говорилось, за счет нивелирующего влияния видеподсистемы.

Идея дальнейшего исследования состояла в плавном изменении частоты системной шины (с минимально возможным шагом, 3-5 MГц) и, соответственно, внутренней частоты процессора при обоих возможных значениях шины памяти. К сожалению, осуществить ее не удалось. Уже при частоте FSB 137 MГц установка такой же частоты памяти вызвала сообщение о невозможности загрузить ядро Linux. А при частотах FSB и памяти 140 МГц система отказалась грузиться вообще.

Тем не менее, при снижении частоты шины памяти удалось достигнуть максимально возможной частоты FSB — 153 MГц. Однако радости это принесло мало.

Так, скорость копирования файлов плавно возрастала до внутренней частоты 770 MГц (до 25%). А затем упала на 16% при частоте 800 MГц и на 22% — при максимально возможной частоте 842 MГц.

В тестах вращения (как на фиксированный, так и на произвольный угол) ни при какой частоте FSB понижение частоты шины памяти давало снижение быстродействия на 5-10%, независимо от частоты FSB. И только гауссово размытие еле заметно ускорилось при частотах FSB 150-153 MГц.

Повторяю, я далек от того, чтобы абсолютизировать полученные цифры. Однако, на мой взгляд, тенденцию они безусловно отражают. А именно: снижение частоты шины памяти (и, соответственно, ее абсолютного быстродействия) приводит к ощутимому снижению быстродействия на реальных приложениях Linux. Оно не только не компенсируется увеличением частоты FSB и внутренней частоты процессора, но в ряде случаев даже усугубляется ими.

Рис. 2. Зависимость быстродействия от частоты системной шины и памяти для различных задач

Для пущей проверки этой тенденции я решил прибегнуть, если так можно выразиться, к ловерклокингу. То есть, сохранив частоту шины памяти, стал плавно понижать частоту FSB — сначала до 130 MГц, затем — до 128.

Результаты подтвердили мои предположения: даже в сочетании 704-128-128 быстродействие системы (хотя и несколько падало относительно варианта 733-133-133) оставалось чуть выше, чем при установках 733-133-100. А иногда оказывалось выше, чем при нештатных повышенных частотах. Опять-таки, в абсолютных значениях разница не велика, но тенденция — налицо.

Выводы

В чем причина этого явления? Рискну высказать предположение.

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

Это особенно заметно для консольных задач, определяемых исключительно взаимодействием процессор-кэш-память. В графическом режиме закономерность выражена несколько слабее, так как в этом случае параллельно с частотой FSB растет и частота шины AGP, несколько увеличивая скорость вывода графики (если, разумеется. выдерживает видеокарта).

Хочу подчеркнуть, что цифровые результаты тестов полностью согласуются с субъективными оценками быстродействия при реальной работе. Так, торможение консольных приложений при переходе к предельным частотам FSB (150-153 MГц) ощущаешь просто физически, так же, как и замедление программ графического режима, едва только переключаешь частоту шины памяти в режим 4:3:1. Собственно, именно эти субъективные ощущения и подвигли меня на проведение квазиколичественных оценок…

Каковы практические следствия проведенного исследования? Их несколько. По крайней мере, при работе в Linux — на Windows я свои выводы распространить бы не рискнул.

Во-первых, с точки зрения цена/производительность сочетание относительно дешевого процессора со 100-мегагерцной шиной (речь идет только о продукции Intel) и памяти PC-133 может дать больший эффект, чем более дорогого 133-мегагерцного процессора и памяти PC-100. Разумеется, если чипсет допускает асинхронную работу памяти.

Во-вторых, это ставит в заведомо невыгодное положение чипсет i815 — в нем первое сочетание возможно (при разгоне процессора), но уж больно велик числитель дроби из предыдущего абзаца. Тогда как применение новых чипсетов VIA способно снизить этот числитель до предела (разница в цене мам на VIA и i815 очень велика, сами знаете, в чью пользу).

В-третьих, можно поставить под сомнение целесообразность разгона процессора. Не сочтите меня беспринципным ренегатом. Ведь всегда ратовал за разгон, а тут… Так вот, хоть и мысль изреченная банальна, изрекаю:

На современном этапе процессоростроительства разгон одного процессора (если не играть в Quake, конечно) большого практического смысла не имеет. Тем более — под Linux, и еще тем более — если выполняется некая практическая работа. Прирост производительности, если не трогать память сомнителен (а иногда — "урост" просто несомненен). Последствия же могут быть печальными. Ведь это в Windows при мертвом висе нажал Reset — и после принудительного лечения (ScanDisk'ом, то есть) все более-менее приходит в норму… В Linux же это грозит разрушением файловой системы и прочими приятными развлечениями. Одно утешает — как показал мой (пока ограниченный) опыт: Linux — не дурак, если что не так, он просто не загрузится…

Рассуждая теоретически, можно предположить: максимальный выигрыш от разгона можно получить на старом добром BX-чипсете. На тех мамах на его основе, которые (полу-) штатно поддерживают 133 MГц на FSB. Ведь здесь пропорционально скорости последней, будет возрастать и быстродействие памяти. В принципе, тоже самое касается и синхронного режима работы и на других чипсетах. Если память сдюжит, конечно…

Правда, предварительные результаты, отраженные в моей предыдущей заметке на эту тему, этого, как будто, не подтверждают: PIII 733EB на i815 дал просто научно-фантастический выигрыш по сравнению с PIII 533B на разогнанном BX. Однако: ведь речь шла о сравнении процессоров двух разных архитектур (C-Mine и Katmai, соответственно). Так что, возможно, основной вклад в этот прирост был обусловлен не двустами лишними мегагерцами процессора (и, тем более, не различными чипсетами), а четырехкратным ускорением кэша второго уровня (пусть и меньшего объема)? В свете влияния подсистемы памяти на суммарное быстродействие под Linux, такой вывод представляется вполне обоснованным.

В этой связи было бы интересно исследовать T-Bird с его сумасшедшим кэшем первого уровня и большим суммарным эффективным объемом кэш-памяти. Теоретически рассуждая, это, может быть, самая эффективная система для использования под Linux…