>>>>> "VT" == Vadim Tulinov writes:
Привет.
>> >> > Этому есть конкретное объяснение, на семинаре специалист Chipcom
>> >> > (за основу 3Сom Corebuilder легли их разработки) демонстрировал
>> >> > презенташку. Как мне объяснили суть в том, что в дуплексном режиме
>> >> > файл пересылается полностью и подтверждение приходит в конце->
>> >> один
>> >> > пакет потерян или порчен, делай все заново.
>> >> Извините - это полный бред, относительно half/full duplex на эзере...
>>
VT> Ну, это ваше мнение...
>>
>> Ну, знаете-ли, это уже перебор;) Это вещи, которые стыдно не знать.
>> Файл пересылается с помощью протокола как минимум третьего уровня. А
>> механизм обнаружения коллизий (не обнаружения их в данном случае;)
>> - на
>> втором уровне (даже, точнее, на MAC). Это вещи, не связанные в
>> принципе. Да и логически Ваше утверждение как-то не стыкуется;)
VT> Хорошо, хорошо, меня заклеймили... ;-).
VT> Рассмотрим только вот такую ситуацию- конечная станция подключена по
VT> full duplex к коммутатору напрямую. Идет пересылка большого файла, на
VT> транспортном уровне UDP (могу привести пример сервиса), подтверждение
VT> приходит в конце передачи файла, одновременно на на станцию некто
Это уж design flow, извините. И Ваше отверждение про то, что "в
дуплексном режиме файл передается полностью и подтверждение приходит в
конце" - полнейший бред, sorry. Если протокол передачи файла кривой - это
никаким дуплексом/симплксом не вылечить.
VT> пытается сбросить данные, карта не справляется (или не справляется сам
VT> компьютер) и один из пакетов сбрасывается или портится. Full duplex
VT> требует дополнительно ресурсов от самого компьютера и карты, у
Ну вот так и надо говорить. Если поставить тормозную тачку и кривую
карту... Но, опять же, проблема возникает из за кривого
протокола. А не из-за дуплекса. Что будет с вашим протоколом, если в момент
передачи файла будет перегружено межсвичевое соединение, по которому он
идет? Нормальные протоколы так не делают.
VT> коммутаторов он уже заложен, на сколько я понимаю при разработке железа
VT> и софта. 3Сom выпустил специальную серию карт для fullduplex -Server
ну, про это карту тут без меня рассказали.
VT> NIC, он именно разгружает CPU.
а что, та же 3C905 DMA не умеет, что-ли? не верю...
>> Да, а что касается трикома, IMHO, они не рекомендуют это делать по одной
>> простой причине - их карточки никогда нормально в фуллдуплексе не
>> работали.
VT> Дешевый вариант, если можно так говорить о картах 3Com, и не
VT> гарантировали нормальной работы со всеми коммутаторами в этом режиме.
дешевый и негарантирующий - это, вон, китайские NONAME за
копейки. А за ту же цену, что и 3c905, допустим, есть Intel Ether Express,
у которой таких проблем я никогда не видел.
>> Я, правда, с код назад последний раз с ихним борахлом общался, но,
>> думаю, ситуация не изменилась...
VT> Изменилась,серия server NIC, которая работает ИМЕЕНО с full duplex
VT> вышла именно год назад.
Именно с full-duplex нормальные NICи были уже довольно давно. Как,
впрочем, и с ISL...
--
Best regards, -- Alex Bakhtin.
AMT Group, Cisco Systems Gold Partner, http://www.amt.ru
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on http://info.east.ru/rus/inetadm.html