При переустановке сервака с v4.11 на V6.1 возникла вот такая проблема:
время прохождения ping до ADSL модема или скажем www.r0.ru очень большое.
К примеру 50 packets transmitted, 30 packets received, 40% packets loss
round-trip min/avg/max/stddev = 4630.053/9780.690/14600.844/2535.739 ms
Не подскажите в чем может быть проблема?
Кабель до модема и сетевуха уже менялись - толку нет.
netwind 09:59 11.08.2007
а на линукс пробовал менять?)
Erema 10:20 11.08.2007
да,
сначала ставил 6.2 с двух СD, потом нашел 6.1 на двух DVD дистр от линукс-центра.
В ядро как всегда добавляю поддержку IPFIREWALL, подправляю rc.conf, resolv.conf
Erema 10:23 11.08.2007
При старте пару раз пишет rl0: watchdog timeout
rl0 - внешний интерфейс
Erema 10:25 11.08.2007
ifconfig -a
возвращает что он поднят, статус active
сам себя пингует без проблем
netwind 15:22 11.08.2007
6.1 это же не линукс.
вот для линукса есть средства диагностики уровня сетевой карты типа ethtool.
показывает всякие там ошибки и тд. и в гугле проще найти проблему тк тестируется шире. и драйвер с меньшей вероятностью написан, прости торвальдс, гомосексуалистами.
Erema 13:51 13.08.2007
Вообще-то кто-нибудь поднимал сервак на FreeBSD 6.2 (июльский релиз этого года) или все так и юзают 4.11 или 5.4???
Venzlav 13:56 13.08.2007
У меня есть пара серваков на 6.2
В твоем случае, попробуй руками выставить 10мбит на интерфейсе.
netwind 14:05 13.08.2007
наверняка ктото поднимал)
не в курсе специфики, но cудя по rl0: watchdog timeout
я бы сказал, что у тебя какие-то проблемы с acpi и прерываниями. наверное в 5 или 6 фре как раз и сделали acpi.
может во фре можно при загрузке отключить acpi?
вот в широте отладки драйвера rl0 я не сомневаюсь.
Erema 14:16 13.08.2007
Venzlav, Можно у тебя как-нибудь даистрибутивы откопировать?
Venzlav 14:19 13.08.2007
Можно в бисти выбрать нужный пункт или прописать в хинтах, ну или unset'ом. Только как-то маловероятно, что в этом проблема =)
Venzlav 14:20 13.08.2007
@Br, можно, 2 болванки...
netwind 14:25 13.08.2007
Venzlav, я так понимаю он на древнюю тачку, где была еще 4 устанавливил 6. А патчкорд и сетевуха старые.
запросто может быть, что на старье не тестировали.
Venzlav 14:34 13.08.2007
netwind, по поводу прерываний, было бы сообщение из серии rl0:couldn't set up irq, а с acpi у 6.2, видел проблемы только на ноутах и пролиантах =), ну еще у меня была похожая засада на 5.3 от линуксцентра, если не изменяет память действительно acpi отрубал. Была б интеловская карточка, тогда можно было бы думать на управление IRQ, а так...
Erema 14:41 13.08.2007
поставил старую 4.11
пересобрал ядро с поддержкой IPFIREWALL
подправил /etc/rc.conf (обе сетевые, повесил nat на внешнюю)
создал resolv.conf, дописал в него адреса dns
перзагрузил,
внешние и адсл-модем пингуются 0.23 ms
две сетевые, обе на RTL8139D
В чем проблема с 6.2?
Venzlav 14:46 13.08.2007
@Br, блин, вариантов накидали, пробуй:
1.скорость интерфейса понизить.
2.ACPI срубить
Дальше видно будет...
Еще кстати, есть вариант дрова собрать модулем, тупо конечно, но пару раз выручало...
netwind 15:27 13.08.2007
и 3: поставить линукс) реализации acpi в линуксе завидует даже биллгейтс
Erema 15:31 13.08.2007
Venzlav, как отрубить то ACPI? просмотрел ядро - в глаза ничего такого не бросается.
Venzlav 16:39 13.08.2007
а как угодно:
При загрузке выбрать вариант без ACPI
или
echo hint.acpi.0.disabled="1" >> /boot/device.hints
или
unset acpi_load в лоадере
Venzlav 16:50 13.08.2007
netwind, давай не будем флэйм разводить...Ну лучше в линухах ACPI, ну файловая система побыстрее, и кэширование под десктоп заточено, и? Зато кривые симофоры, убогая система портов (ну может кроме дебиан и слаки, да и то до бсдшной им далеко), хреновое быстродействие на серверных задачах(ну тот же сервер бд), да и просто бессистемность развития большинства дистрибов (взгляни хоть на гентушные ебилды).
Erema 16:53 13.08.2007
понял,
во еще интерестность, если долго пинговать, то пишет
ping: sent to: No buffer space available
ping: sent to: No buffer space available
ping: sent to: No buffer space available
ping: sent to: No buffer space available
64 bytes from 192.168.1.110: icmp_seq=236 ttl=254 time=66195.346 ms
64 bytes from 192.168.1.110: icmp_seq=237 ttl=254 time=65194.554 ms
64 bytes from 192.168.1.110: icmp_seq=238 ttl=254 time=64193.720 ms
Venzlav 16:59 13.08.2007
Ну буфер у карточки загибается, ну это нормально, замучил ты ее...
options NMBCLUSTERS=65535
Den 17:28 13.08.2007
Сообщение от Venzlav: netwind, хреновое быстродействие на серверных задачах(ну тот же сервер бд)
Уточните каких БД.
netwind 18:28 13.08.2007
Venzlav, да че тут флеймить. пример глючащей фри вот вам перед глазами.
пора уже отечественным сисадминам понять, что фря отстает и дальше будет только хуже.
делайте свой выбор! не позволяйте бородатым гомосексуалистам маккузикам овладевать вас !
zic 20:49 13.08.2007
за примерами глючащего линукса прошу пожаловать на sata типа raid на чипе sil3112
zic 20:50 13.08.2007
Сообщение от :
Уточните каких БД.
ну не оракал явно
может мускуль?
netwind 22:02 13.08.2007
Какой-нибудь postgress или informix в 2000 году, быть может.
Но точно не mysql.
Alex_Saf 22:08 13.08.2007
Сообщение от zic:
может мускуль?
Да именно он. Проблема в масштабировании при большом кол-ве процессов. Точнее ее резкое падение при определённых условиях. Перетералось на LOR. В итоге вроде были предложены патчи для ядра, устраняющие это проблему.
Сообщение от zic:
за примерами глючащего линукса прошу пожаловать на sata типа raid на чипе sil3112
Наверное не на каждый линукс. У меня было много плат с этими чипсетами. В основном tyan. Если ставил еще rhel 3 то можно было подсунуть штатные драйвера производителя. Но уже с федоры 3 проблем не было.
Рискну предположить, у фри на этих чипсетах было (а может и есть) еще больше проблем.
netwind 22:33 13.08.2007
В мануале на mysql.com нарочно написано про предпочтения : 1. linux 2. solaris, 3. еще туда-сюда freebsd.
Ага, определенные условия падения при более чем 8-ми процессорах.
И в итоге чувак из интела, которому была они таки доступны, пофиксил лажу но в glibc, а не в ядре. К моменту широкой доступности таких систем все будет два года как пропатчено.
Alex_Saf 22:58 13.08.2007
Сообщение от netwind:
Ага, определенные условия падения при более чем 8-ми процессорах.
И в итоге чувак из интела, которому была они таки доступны, пофиксил лажу но в glibc, а не в ядре. К моменту широкой доступности таких систем все будет два года как пропатчено.
Да все так. Тем не менее проблема имела место быть. И, насколько я помню, проблема была не с "патченьем", а с признанием ее наличия. Исправление затянулось именно "благодаря" людишкам, которые почему то упорно не хотели признавать наличие проблемы. И приводили массу аргументов из класса "этого не может быть, потому что не может быть никогда"
А касательно наличия 8-ми процессорного сервера, у меня подобный был уже около полутора лет назад. Это был 4-х сокетный на базе матери tyan и каждый проц двукорный. Так что восемь процессоров в настоящее время - плевое дело.
