>
>первым делом нафиг все сетевые (особенно рилтек)-оставьте только 3com а лучше замените
>на 3с905,
>http://www.freebsd.org/releases/5.2.1R/hardware-i386.html#ETHERNET
>где вы там увидели Intel 82547EI Gigabit Ethernet? Gigabit Ethernet NICs based
Какая жалость... я работаю на пустышке... :) (шутка)
em0@pci2:1:0: class=0x020000 card=0x34288086 chip=0x10198086 rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = '82547EI Gigabit Ethernet Controller (LOM)'
class = network
subclass = ethernet
>82546EB controller chips em(4)- верхняя,хотя может это и несущественно.
>
Согласен т.к. все перечисленные сетевухи работали в разных канторах на разном железе в течении трех лет и проблемы возникли только при работе с X всех версий и на g4 и на g5. Железо перетряхивалось, кабели проверялись свичи и т.д.
>>Есть несколько вопросов которые я так и не смог решить.
>>
>> FreeBSD 5.2.1(подобное было и на 4.x) netatalk 2 (и предидущие
>>версии то же) - файл сервер для маков.
>
>ядро собрано с поддержкой netatalk?
Да. Но это не обязательно т.к. в конце концов у меня нет теперь класик и кроме afpd мне ничего не требуется и испоьзую только tcp.
Так же замечу что использование еще и atalkd погоды не делает, только машину грузит.
>
>>Пока были 9
>>класик все пахало на ура,
>
>соединение происходило ddp или tcp,если коннект из 9 с нажатым опшном насколько
>стабильно ?
см. выше. С класикой никогда проблем не было. Они с сервака и работали.
По пол года без перегрузки или рестарта служб...
>
>>а вот с 10.x начались проблемы...
>>Да сетевухи были 3com 903 циклон,rl8139,Intel PRO 100 VE и на
>>Intel 82547EI Gigabit Ethernet.
>> 1.) рвется соединение по таймауту при копировании на встречных потоках,
>
>зона задана или по умолчанию? nbplookup что говорит? выложите листинг, Phase
>какие указаны?
>
см. выше. atalk я теперь не использую и маршрутизаровать ddp... :) у меня не так много маков.
>>при копировании с одного сетевого диска на другой(сервер один), переодически отваливаются
>>сетевые диски когда с них работают или на них сохраняются.
>
>если речь о netatalk,а не о samba то очевидно проблема в сервере
Я то же так думаю... вынь клиенты спокойно качают как хотят с этого сервера через самбу без проблем...
>
>
>> Т.е. копирование проходит немного затем соединение остонавливается и по
>>таймауту идет нафиг причем проходит это достаточно тяжело... да и на
>
>а случаем файрвольчики в 10-ке не включены ли? да и на сервере
>не мешало бы на время проверки погасить
Проверял неоднократно... все впорядке!
>
>>сервере дочерний процесс вешается и прибить его можно только по -9
>
>а вот это очень нездорово-пользователи "системные" или "виртуальные"
>приводите логи afpd
>
гости -> nobody. по поводу логов см. ниже щас стоит версия 2 и в ее логах крах не регистрируется. А вот в 1.6 пример я написал...
>>соответственно в логах ничего существенно в netatalk 2 а в 1.6
>>например afpd[26272][server_child.c:262]: I:Default: server_child[1] 37509 exited 1
>>
>>я не силен в Си что бы разобраться что вызвало исключительную систуацию...
>>
>>
>>2.) При работе Mac X с самбой происходит странная штука. Скачивание
>>с самбы на мак проходит со скоростями около 9 МБ/с (сеть
>>100) и 50МБ/с (сеть 1000), а закачка на самбу идет со
>>скоростями... около 300 КБ/с и около 600КБ/с соответственно... самба 2.2.9_1
>>
>
>попробуйте поиграться с duplex и кстати поведайте нам что за коммутатор используете
D-link DGS-1008TL, был 3com office connection (кажется так) и D-link 10/100 fast ethernet switch
>
>
>>
>>Баловался с sysctl
>>
>>kern.polling.enable=1
>>net.inet.tcp.delayed_ack=0
>>net.local.stream.recvspace=65535
>>net.local.stream.sendspace=65535
>>net.inet.tcp.sendspace=65535
>>net.inet.tcp.recvspace=65535
>>
>>и еще что-то но я уже не помню :) результат выше описанный.
>>
>
> можно еще попробовать изменить макcимальные размеры пакетов MTU,а также отключить
>ipv6
Пробовал. никакой реакции... только вот что бы mtu в X выставить поболе 1500... в общем через жопу это... но и это не лечит.