вторник, 26 Апрель, 2005

Cooler TTC-K8ATB/825/Sc

Беда, так сказать, не приходит одна. Не успел "поюзать" новый БП, как пришлось обзаводиться новым куллером для процессора. Черт дернул меня "почуствовать" воздушный поток создаваемый вентилятором Igloo 7200, случайно коснулся пропеллера, тот в свою очередь остановился от перекоса. Вот же "сопливо" делают. Выпрямление закончилось оторванной одной из лопаток и как следствие - довольной шумной работой и некоторой вибрацией (эксцентрик получился). Было желание оторвать симметричную лопатку, но мысль обзавестись новым куллером победила. Не долго думая выбрал titan'овский TTC-K8ATB/825/Sс. Поставил на минимальные обороты. Тут некоторе отступление. У меня либо bios не то кажет про скорость вращения процессорного куллера, либо питание идет несколько большее. Для примера на старом было 2700 об/мин против 2500 паспортных, на новом 2250 об/мин против 1800 паспортных.. Так вот, поставил на минимальные обороты (2250) и решил протестировать. При игре в q3 получил температуру процессора меньше ожидаемой (градусов эдак на 10). После этого занялся вопросом нагрузки несколько иначе. Был запущен burnK7 на некоторый период времени. В итоге, по прошествии 1 часа имел 58,5 градусов на процессоре, 40 градусов на плате (это что мне показывал lm_sensors) и температура не увеличивалась.

В завершение могу констатировать: общее снижение шума, производимого компьютером, каковое и было подтверждено домочадцами. Осталось разве что Palit'овский 6600GT укротить, но это пока не скоро случиться.

пятница, 22 Апрель, 2005

Авария с Блоком питания

Ну вот, беда пришла и в мой дом, а именно, PowerOne, служивший мне верой и правдой 3 года попросился на покой. Выразилось это в том, что выдаваемое по +12V каналу упало примерно на 0,15 и стало в пределах 11,56-11,64 (об этом мне говорил lm_sensors). Проблемки стали проявляться при нагрузке видеосистемы, например, игрушками (люблю, знаете ли, иногда в вульфенштейн поиграться). Компьютер просто зависал, монитор гас и т.п. нехорошие вещи из которых выход был только грубой перезагрузкой. Хотя, стоить отметить, что при обычной работе да и на простых игрушках - никаких проблем не было (дочкин supertux работал "только-в-путь"). Взятый во временное пользование (спасибо spir'у) inwin'овский PowerMan "закрыл брешь в обороне". Сейчас пребываю в ожидании Delta'вского блока питания.

понедельник, 11 Апрель, 2005

ubuntu-5.04-install

Появился в моем "загашнике" ubuntu-5.04-install-i386.iso с сотоварищем kubuntu-5.04-install-i386.iso

О дистрибутиве: Ubuntu это дистрибутив Linux созданный в духе Debian (и основанный на нём), который имеет чёткий график релизов (новый релиз каждые шесть месяцев) и ориентированный на простоту использования и удобство работы (всё должно "просто работать" TM). Каждый релиз Ubuntu поддерживается обновлениями безопасности (security updates) в течение 18 месяцев. Ubuntu поставляется с самой свежей версией Gnome и с такой подборкой серверного и десктопного программного обеспечения которая позволяет создать удобное рабочее окружение c помощью всего лишь одного установочного CD.

Опубликовано Константин Климчев в 10:16
Отредактировано: пятница, 15 Апрель, 2005 13:37
Категории: Дистрибутивы
|

пятница, 08 Апрель, 2005

Возможности почтовой системы на основе postfix+cyrus-imap из состава debian sarge

Обзор основан на попытке исследования возможности применения указанного программанорго обеспечения в условиях АТК-Интернет. Здесь будет приведен фрагмент отчета по результатам исследования.

Техническое описание:

Тестируемый:

Аппаратное обеспечение:

  • CPU: 2xPIII450
  • Mem: 256 Mb
  • HDD: аппаратный SCSI-RAID1 (Mylex DAC960PTL1), отдельный раздел /var (т.е. спул и ящики на одном разделе), fs – reiser 3.6.19
Программное обеспечение:
  • OS: debian sarge (testing - декабрь 2004)
  • postfix 2.1.4
  • cyrus-imap 2.1.17
  • sasl2 2.1.19

Тестирующий:

Программное обеспечение:

  • OS: debian sarge (testing - декабрь 2004)
  • postal 0.62 – генератор почтового потока
  • python 2.3
  • набор python-скриптов по управлению почтовыми ящиками (создание, удаление и т.п.)

Краткое описание системы:

  • Почтовые пользователи – виртуальные, хранятся в базе пользователей cyrus-imap (db-файл).
  • Авторизация пользователей на основе sasl (информация хранится в sasldb – доступ через unix-socket; возможно использование иных хранилищ, как то: mysql, ldap и т.п.).
  • Письма в пользовательских ящиках хранятся в формате типа MH.
  • Имеется набор скриптов (python) которые позволяют управлять пользователями (локально и удаленно), а также менять пароли в sasldb на авторизацию (локально).
  • Какие-либо правила в отношении почтовых аккаунтов (блокирование получение почты, разрешение получение всей почты и т.п.) хранятся в файлах db (созданных с помощью postmap) postfix'а.

Краткая методика тестирования:

  1. С помощью скриптов, запущенных на тестирующем компьютере, была создана база пользователей (около 4200 пользователей). Время на создание пользовательской базы ~ 25 минут.
  2. Сгенерирован файл со списком почтовых адресов для генератора почтового потока (на основе созданных почтовых пользователей)
  3. Запуск postal с различными параметрами на тестирующем компьютере для выявления пропускной способности тестируемой системы (Работа в штатном режиме;Изменение настроек почтовой системы для выяснение оптимальных параметров).
  4. Создание нештатных ситуаций
  5. Исследования проводились при использовании unix-socket: cyrus-доставщик cyrus-imap'а, lmtp-доставщик postfix'а (проверка работоспособности по tcp не проводилась)

Фрагмент итоговых выводов:

  • Работа, используя доставщик cyrus-imap, более производительна и стабильна по сравнению с использованием lmtp-доставщика postfix'а. При использовании cyrus-доставщика на указанном оборудовании обеспечивалась стабильная работа в течение 30–40 минут (далее не проверялось) для следующего потока писем: 300 писем в минуту в 100 потоков. При этом количество процессов доставщика было на уровне 15–18, почтовая очередь postfix'а не переполнялась (не отмечено более 5–7 писем в очереди). При использовании lmtp-доставщика постфикса при указанном потоке писем отмечалось переполнение очереди postfix'а и проведение проверки останавливалось явно через 5–10 минут после начала проверки. Количество процессов доставщика было на уровне 50–60.
  • Останов cyrus-imap'а во время проведения проверки вызывало разрастание почтовой очереди postfix'а. После восстановления работоспособности cyrus-imap'а сообщения из очереди postfix'а передавались для дальнейшей доставки cyrus-imap'у. Потерянных писем не отмечено.

воскресенье, 03 Апрель, 2005

nvidia в Debian Sarge

Вы стали счасливым обладателем дисков в Debain Sarge, но тут же замечаете, что на носителях отсутствуют Nvidia'вские дрова. Ну придется вам узнать слудеющее: Указанный софт относится к классу несвободного и "обитает" в секции non-free, которой на cd/dvd дисках нет.

Предварительная подготовка:

Как поступить? Очень просто - скопировать с официального ftp или с одного из зеркал. По следующему пути: debian/pool/non-free/n/nvidia-graphics-drivers/ находится все необходимое, в том числе и для сборки модуля ядра. Если у Вас ядро ver. 2.4.27 (Sarge'вское) - тут: debian/pool/non-free/n/nvidia-modules-i386/ уже есть собранные модули. Не забудьте также и пакет nvidia-kernel-common - обитает по следующему пути debian/pool/contrib/n/nvidia-kernel-common/. С этим пакетом, вернее со всем nvidia иногда твориться нечто странное. Он то попадает в testing (Debian Sarge), то опять возвращается в unstable. Вообщем проследите, чтоб версия nvidia-kernel-common совпадала с nvidia-graphics-drivers.

Вообщем мы скопировали себе пакеты (указанные версии были на момент написания):

  • nvidia-kernel-common_1.0.7167-1_all.deb
  • nvidia-glx_1.0.7167-1_i386.deb
  • nvidia-kernel-source_1.0.7167-1_i386.deb

Сборка модуля ядра:

Сборка модулей ядра в Debian - процедура стандартная и отработанная, но я до сих пор не могу понять, почему в некоторых случаях пишем debian/rules binary-modules, а в некоторых debian/rules binary_modules. Например, если в случае fuse используется первый, то в случае nvidia - второй. Но все равно - опишу пошаговое действие:

# dpkg -i nvidia-kernel-common_1.0.7167-1_all.deb
# dpkg -i nvidia-kernel-source_1.0.7167-1_i386.deb
# cd /usr/src
# tar xfz nvidia-kernel-source.tar.gz
# export KVERS=`uname -r`
# export KSRC=/usr/src/kernel-headers-`uname -r`
# cd modules/nvidia-kernel
# debian/rules binary_modules        
Как обычно, не забываем предварительно проинсталировать kernel-headers для вашего ядра (посмотреть можно командой uname -r), ну и само-собой про kernel-kbuild-2.6-x (я веду разговор про сборку модуля для ядра версии 2.6).

Инсталляция:

Инсталлируем собранный модуль ядра и glx-пакет. У меня это:

# dpkg -i /usr/src/modules/nvidia-kernel-2.6.8-2-686_1.0.7167-1_i386.deb
# dpkg -i nvidia-glx_1.0.7167-1_i386.deb        

Конфигурирование:

Тут ничем не отличается от какого-либо другого дистрибутива. Читайте /usr/share/doc/nvidia-glx/README.gz и правьте настройки XFree в файле /etc/X11/XF86Config-4. Если хотите включить NVIDIA TLS, в файле /etc/default/nvidia-glx установите опцию USE_TLS=1.

PS. В связи с тем, что в Debian Etch изменено именование пакетов с kernel-* на linux-* в вышеописанном нужно это учитывать.

Опубликовано Константин Климчев в 14:09
Отредактировано: вторник, 13 Декабрь, 2005 16:12
Категории: Советы
|