[casperrr]

Тогда что такое unicast address of the port и когда используется такая альтернатива?

Для передачи STP и прочего. Посмотрите, как в документе по Вашей ссылке алгоритм обработки попадает в альтернативу PAUSE (на всех 3х диаграммах) - только при DA=01-80-C2-00-00-xx.

Да, действительно.

Тогда получается, что посылка PAUSE приводит к блокировке/замедлению ЛЮБОЙ сетевой активности интерфейса?

Вот по этой ссылке есть рисунок. http://www.networkworld.com/netresources/0913flow2.html

Как раз ситуация, похожая на пример с торентом.

>>120% Line Rate traffic is now Destined for Station D (See diagram). Some switches or routers would send pause frames to stations A, B and C, because station D's path is overloaded. These pause frames will slow >>down or even stop the unrelated conversation between stations B and C. This constitutes what is called External Head of Line Blocking.

Т.е. обмен между B и C вроде не при чем, а он пострадает. Ну и механизм.

To vIv: т.е. "почти шейпинг" средствами какого-нибудь файлового хранилища может интерфейсы куче клиентов отрубить, с которыми идет обмен в момент перегрузки?

Изменено 8 сентября, 2009 пользователем casperrr

[m_medved]

Вы ещё сидите на half-duplex? 8-)

Это вопрос к m_medved, его пример. Пример выглядит как жизненный, наблюдаемый лично, а не в духе "что, если". Или описанная ситуация не соотв. дейсвительности и m_medved чего-то не тогой, или... тогда хочется понять механизм :) А то вон даже мужики на форуме длинк-а - и те не в курсе :)

Да и вообще, для раскрытия заявленной темы, так сказать.

Да жизненный пример, жизненный. Я из тех, и кому мозги компосировали, и кто разбирался в проблеме. ВСЯ активность понижается до скорости медленного принимающего.

 

Вы ещё сидите на half-duplex? 8-)

Я не главный, поэтому, к моему великому сожалению, не могу запретить решать проблему «укладыванием в десятку».

[HoatDog]

Не работает этот функционал нормально на 35хх в связке 3627.

Может вызвать сбой сети, проверено на своей шкуре неделя общения из за чего сбойй с сапортом д-линка ничего не дала пока сами опытным путем не выяснили эту фенечку д-линков.

[vIv]

To vIv: т.е. "почти шейпинг" средствами какого-нибудь файлового хранилища может интерфейсы куче клиентов отрубить, с которыми идет обмен в момент перегрузки?

Да, но я бы это более сравнил с троттлингом общения с именно самим хранилищем. А если хранилище умное, то оно может "чуть придушить" конкретного клиента.

[Rst7.CBSIE]

А если хранилище умное, то оно может "чуть придушить" конкретного клиента.

Если связь с хранилищем осуществляется по TCP, то это случится автоматически - все же требования к реализации TCP предусматривают обязательность (хотя может в стандарте фигурирует "желательность", надо поглядеть в RFC) реализации грамотного управления окном. Т.е. TCP в среднем не будет плодить пакетов больше, чем может пролезть в канал, а значит, в среднем низкоскоростной линк не сможет придавить высокоскоростной по обсуждаемому сценарию. Небольшие пики будут сглажены наличием внутренних буферов в коммутаторах.

 

Вопрос о реализации (да и вообще о наличии) такого управления в торрент-клиентах не то что открыт, а походу даже не поднимался. Не зря многие считают, что торренты - зло еще то.

[casperrr]

Вопрос о реализации (да и вообще о наличии) такого управления в торрент-клиентах не то что открыт, а походу даже не поднимался. Не зря многие считают, что торренты - зло еще то.

Че то есть все таки.

"Про µTP в новых версиях µTorrent: что это, как, зачем?"

http://torrents.ru/forum/viewtopic.php?t=2162837

>>Одна из основных целей µTP — устранить эту лишнюю нагрузку на провайдеров от P2P-трафика.

>>В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными.

 

[Rst7.CBSIE]

Че то есть все таки.

Понял. Вопрос о наличии (по крайней мере для uTorrent'а) - снимается. Вопрос о качестве реализации - остается.