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):
- поворачивается на фиксированный (90 градусов) угол
- вращается на произвольный (для определенности и единообразия — 52 градуса) угол
- подвергается гауссовому размытию с радиусом 10 пикселей.
В чем физический смысл этих, в общем достаточно элементарных, манипуляций? В первую очередь это пересчет пикселей, то есть скорость определяется быстродействием процессорной (в широком смысле слова, включая кэш и системную память) подсистемы. При повороте на произвольный угол (и, в меньшей степени, при размытии) на это накладывается еще и быстродействие видеоподсистемы — изрядную долю времени занимает просто перерисовка экрана. Но при одной и той же видеокарте определяющей является процессорная составляющая. А размер файла подобран (методом ползучего эмпиризма) таким образом, чтобы обеспечить достаточную длительность процесса и при этом свести к минимуму влияние дисковой подсистемы (при данном объеме оперативной памяти индикатор жесткого диска активности не проявляет).
Я не настаиваю на строго количественном характере своих тестов. Но уверен, что качественную оценку чистого быстродействия конкретного железа в реальной работе они дают. Ничуть не менее значимую, кстати, чем кадры в секунду при игре в Quake. Хотя бы потому, что под последний все, кому ни лень, оптимизируют и железо, и драйверы к нему. А вот до подобной оптимизации под Linux-программы мы пока не дожили…
К сожалению, пришлось отказаться от использования в качестве тестовой системы StarOffice (к сожалению — потому что это мог бы быть инструмент межплатформенного сравнения: он существует и под Linux, и под Windows, и под Solaris обоего рода). Дело в том, что измерения посредством его оказались практически невоспроизводимы: скорость загрузки его самого, открытия любого документа или манипуляции с последним, как оказалось, могут различаться буквально на порядки — в зависимости от того, обращаетесь ли вы к этому файлу и операции впервые за сеанс (Linux; не XWindow!) или повторно. Вероятно, опять же, вследствие кэширования. Для чистоты эксперимента это потребовало бы полной перезагрузки системы после каждого действия. А согласитесь, перезагружать Linux по несколько десятков раз на дню — занятие не из самых веселых и полезных для здоровья…
Результаты
Мне не известны результаты тестирования аналогичных (или хотя бы близких) конфигураций под Linux. Поэтому никаких внешних объектов для сравнения у меня нет. Остается прибегнуть к сравнению за счет внутренних ресурсов. То есть — к разгону.
Для начала были опробованы установки по умолчанию — FSB 133 МГц, шина памяти 100 МГц, внутренняя частота процессора 733 МГц. Значения производительности (в секундах) при этих параметрах сравнивались с нормальными рабочими установками — то же, плюс шина памяти на 133 МГц. А затем начинались игры с частотой FSB (и, следовательно, внутренней частотой процессора и скоростью работы памяти). Результаты оказались весьма неожиданными.
Таблица 1. Абсолютная производительность, с | ||||
Configuration | Copy files | Rotation for 90 | Free rotation | Gaussian Blur |
704-128-128 | 6.97 | 8.53 | 28.13 | 19.72 |
715-130-130 | 6.53 | 8.50 | 27.07 | 19.68 |
733-133-100 | 7.19 | 9.78 | 27.94 | 19.81 |
733-133-133 | 5.69 | 8.29 | 24.71 | 18.37 |
754-137-102 | 4.60 | 8.81 | 27.32 | 19.19 |
754-137-137 |
Не загрузилось ядро
|
|||
770-140-105 | 4.34 | 9.19 | 27.63 | 19.05 |
770-140-140 |
Машина не запустилась
|
|||
800-145-108 | 6.58 | 9.28 | 26.40 | 18.50 |
825-150-112 | 6.59 | 8.50 | 26.63 | 17.97 |
842-153-115 | 6.97 | 9.72 | 25.81 | 17.88 |
Таблица 2. Производительность относительно P-733 133/133, % | ||||
Configuration | Copy files | Rotation for 90 | Free rotation | Gaussian Blur |
704-128-128 | 122 | 103 | 114 | 107 |
715-130-130 | 115 | 103 | 110 | 107 |
733-133-100 | 126 | 118 | 113 | 108 |
733-133-133 | 100 | 100 | 100 | 100 |
754-137-102 | 81 | 106 | 111 | 104 |
770-140-105 | 76 | 111 | 112 | 104 |
800-145-108 | 116 | 112 | 107 | 101 |
825-150-112 | 116 | 103 | 108 | 98 |
842-153-115 | 122 | 117 | 104 | 97 |
Примечание к табл. 1 и 2: меньшие значения, естественно, соответствуют лучшему результату.
Как можно видеть из таблиц, увеличение чистого быстродействия памяти на 1/3 дает прирост производительности от 8 до 26%. При этом он максимален для теста копирования файлов, где быстродействие подсистемы процессор-кэш-системная память не осложняется влиянием графического режима. Для тестов GIMP различия сглаживаются, как уже говорилось, за счет нивелирующего влияния видеподсистемы.
Рис. 1. Сравнительное быстродействие при различных установках частоты системной шины и памятиИдея дальнейшего исследования состояла в плавном изменении частоты системной шины (с минимально возможным шагом, 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…
Дополнительно |
|