rm_ Опубликовано 12 января, 2011 · Жалоба Тут вот такая история всплыла: - http://www.opennet.ru/opennews/art.shtml?num=29191 - http://tech.slashdot.org/article.pl?sid=11/01/07/0533226 Интересует, что об этом думают ув.тов. операторы. Считаете ли вы это проблемой? Есть ли она в вашей сети? Пробовали её устранить, и что в результате получилось? Насколько я понимаю, посыл автора заключается в том, что если в ЧНН канал работает близко к максимальной пропускной способности, для клиента при этом должен расти не пинг, а сразу процент потерь. Но вот действительно ли такое поведение будет лучше (незаметней) для большинства сетевых протоколов, что-то сомнительно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 12 января, 2011 · Жалоба Если правильно настроена приоритезация трафика, то те протоколы, которые будут дропатся - ни на что не повлияют. Телефония же дропатся не будет, как и другие "нужные" протоколы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
netime Опубликовано 12 января, 2011 · Жалоба Слишком много проверок checksumm (на каждом заголовке). в IPv6 это учли. кое где нет проверки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 12 января, 2011 · Жалоба Насколько я понимаю, посыл автора заключается в том, что если в ЧНН канал работает близко к максимальной пропускной способности, для клиента при этом должен расти не пинг, а сразу процент потерь. А вы нигде не слышали, что в гигабитном порту нельзя купить больше чем 700 мбит интернета? Ибо при пиках под 900 мбит это уже не интернет, сплошные дропы либо задержки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 12 января, 2011 · Жалоба Слишком много проверок checksumm (на каждом заголовке). в IPv6 это учли. кое где нет проверки.Не в этом дело.Да и помимо контрольных сумм там ещё куча проверок, которые отнимают не меньше фактического времени, чем расчёт контрольной суммы, который часто делается аппаратно сетевухой при приёме. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 12 января, 2011 · Жалоба А вы нигде не слышали, что в гигабитном порту нельзя купить больше чем 700 мбит интернета? Ибо при пиках под 900 мбит это уже не интернет, сплошные дропы либо задержки.Не слышали... А что, правда? Вот мы лохи... Выходит нас кинули?!? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 13 января, 2011 · Жалоба А вы нигде не слышали, что в гигабитном порту нельзя купить больше чем 700 мбит интернета? Ибо при пиках под 900 мбит это уже не интернет, сплошные дропы либо задержки.а мужики то и незнали. покупать не покупаем, но есть нехилое множество точек, в которых гигабитный порт стабильно загружен на 92-99%, и никаких нареканий... может не надо экономить на оборудовании и подробно изучать документацию? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 13 января, 2011 (изменено) · Жалоба может не надо экономить на оборудовании и подробно изучать документацию? Может надо было мат. статистику в школе учить? Зайдите на свитч в котором этот гигабит формируется из нескольких портов и посмотрите количество заюзанных буферов. Такой гигабитный порт при загрузке больше 80% дает около 1 мс джиттера, если хватает буфера. Изменено 13 января, 2011 пользователем Дегтярев Илья Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 13 января, 2011 · Жалоба порт стабильно загружен на 92-99% По графику в mrtg где счетчики снимаются раз в 5 минут? Ну-ну про "стабильно" Собирал как то статистику снимая счетчик раз в секунду с порта сервера отдававшего ~800 мбит трафика (по mrtg) в несколько сотен потоков. Так вот битрейт на нем прыгал и ниже 600 мбит и под 950. Выборки были при максимально разрешенной очереди в 100 пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 13 января, 2011 · Жалоба Может надо было мат. статистику в школе учить?Зайдите на свитч в котором этот гигабит формируется из нескольких портов и посмотрите количество заюзанных буферов. Такой гигабитный порт при загрузке больше 80% дает около 1 мс джиттера, если хватает буфера. может и справедливо для бюджетных азиатов, но не стоит обобщать.если с обоих сторон линка стоят железки, с честной фабрикой - проблем не должно возникать. нарастание output queue drop не исключаю - здесь просто может начать упираться в физику порта - как только поток допустим захочет посыпаться чуть больше гигабита в гигабитный порт. но если у вас нарастает input queue drop - это уже надо срочно инспектировать и устранять. на практике можно обозначить пороговые значения в 95% для cisco me серий, и 92% для l2/l3. для монстров аля 45/49 и 65/76 порог можно обозначить в 97%. но опять же - только при условии что линк с обоих сторон заходит на равносильное оборудование. если у вас с одной стороны какая нибудь 65ая, с другой стороны какой нибудь длинк (да хоть 3627) - естественно под 90% загрузки у вас будет болеть голова. просто к слову об оборудовании, после замены LACP 4G (cisco -> 3627g) на 10g/cx4 - графики загрузки мнгновенно подскочили (с 1.8g для lacp до 2.2g для 10g), хотя на связке cisco -> cisco portchannel на 4G выжимался почти на честные 4G (3.7G без головной боли - выжимать больше небыло смысла, 10G...). если мы гонемся за показателями sla, конечно пороговое значение для равносильного оборудования прийдется существенно занизить (до 80%), чтобы с чистой совестью давать гарантию качества. но если мы гонемся за качеством - то давайте исключать узкие места. не справляется железка - ставим что то более производительное. очевидно же, что если 3627G как L2 на полном запуске не переваривает даже 50% нагрузки, то тот же 4924 утирает ему нос, повышая показатель переваривания до тех же 85%-90%. ну тут и разница в цене более чем очевидна. ну и естественно, что любой маломальски адекватный сетевик, при наблюдении загрузки линии под 80-85% будет активно искать возможность увеличения пропускной способности, например вдвое (за счет тех же etherchannel например). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 13 января, 2011 · Жалоба может не надо экономить на оборудовании и подробно изучать документацию? Может надо было мат. статистику в школе учить? Зайдите на свитч в котором этот гигабит формируется из нескольких портов и посмотрите количество заюзанных буферов. Такой гигабитный порт при загрузке больше 80% дает около 1 мс джиттера, если хватает буфера. На самом деле с гигабитами не всё так просто.Правы и те кто говорят, что видел гигабитную скорость на данных портах и нет. Просто GE порты разные. :) Этот вопрос уже обсуждался чуть более года назад. http://forum.nag.ru/forum/index.php?showto...st&p=448997 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 13 января, 2011 (изменено) · Жалоба Этот вопрос уже обсуждался чуть более года назад.http://forum.nag.ru/forum/index.php?showto...st&p=448997 Школьникам из той темы всем надо колы ставить. Да, по опте бежит 1250 мегабит. Ну и байты там не по 8 бит, а по 10. Привет 8B/10B кодирование. Полезных же данных ровно гигабит. В меди используется не 4, а 5 уровней кодируют 2 бита, поэтому там избыточного кодирования для передачи не используют и ползет честный гигабит, по 125 изменений уровня в микросекунду (максимальная полоса 62 МГц) на каждую пару.. Читайте стандарты. По этой же причине SFP-T стоят как паровоз. Принятые 10 бит необходимо запомнить, преобразовать и передать только 8, но медленней. А в медиаконверторах еще необходимо найти байтовую синхронизацию. Изменено 13 января, 2011 пользователем Дегтярев Илья Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 13 января, 2011 · Жалоба Имеем ряд линков в 700-800 мбит (усреднённая в 5 минут) и всё работает стабильно - джитер 1мс, задержка 1мс. При измерении iperf`ом линк даёт 0% потери пакетов и 1-2мс джитера. При загрузки от 900 мбит начинается деградация сервиса. Джитер возрастает не сильно, появляется потеря пакетов порядка 0,05-0,1%. Это по трафику бестэфорд. Все линки между cisco пылесосами. Переход от etherchanel на 10GE не принёс прироста в суммарной скорости. А 85% загрузки канала - это повод расширять его, при этом 4xGE загруженные на 85% - повод думать о 10GE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 13 января, 2011 (изменено) · Жалоба При загрузки от 900 мбит начинается деградация сервиса. От этого числа еще отнимаем две сотни, т.к. у клиентов интернет на скорости линка и верояность что загрузят 200 в опеределенном направлении совсем не маленькая. На выходе получаем, что в часы ЧНН можем показать клиентам например этот трейс Трассировка маршрута к mail.ru [94.100.191.204] с максимальным числом прыжков 30: 1 <1 мс <1 мс <1 мс 6-ka-core.mipt.ru [93.175.6.1] 2 <1 мс <1 мс <1 мс ASR1006-1-TenGE2.mipt.ru [81.5.90.26] 3 <1 мс <1 мс <1 мс C7609-GW.mipt.ru [193.125.142.97] 4 1 ms 1 ms 1 ms m10-ix.msk.runnet.ru [194.190.254.41] 5 1 ms 1 ms 1 ms m9-3-gw.msk.runnet.ru [194.85.40.221] 6 1 ms 1 ms 1 ms m9-1-gw.msk.runnet.ru [194.85.40.226] 7 1 ms 1 ms 1 ms MailRu.msk.runnet.ru [194.190.254.234] 8 1 ms 1 ms 1 ms vl931.br1.m100.net.mail.ru [94.100.183.94] 9 2 ms 2 ms 2 ms 94.100.191.204 Изменено 13 января, 2011 пользователем Дегтярев Илья Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 января, 2011 · Жалоба Такой гигабитный порт при загрузке больше 80% дает около 1 мс джиттера, если хватает буфера. А не флов ли контрол просит заткнутся передающему не надолго? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
L-ZiX Опубликовано 13 января, 2011 · Жалоба По этой же причине SFP-T стоят как паровоз. Принятые 10 бит необходимо запомнить, преобразовать и передать только 8, но медленней. А в медиаконверторах еще необходимо найти байтовую синхронизацию. В каком, простите, месте они стоят как паравоз? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 13 января, 2011 · Жалоба По этой же причине SFP-T стоят как паровоз. Принятые 10 бит необходимо запомнить, преобразовать и передать только 8, но медленней. А в медиаконверторах еще необходимо найти байтовую синхронизацию. В каком, простите, месте они стоят как паравоз? видимо речь о родных cisco.. они реально по цене самолета. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
