Jump to content
Калькуляторы

Анализ проблем с буферизацией в современных TCP/IP сетях

Тут вот такая история всплыла:

- http://www.opennet.ru/opennews/art.shtml?num=29191

- http://tech.slashdot.org/article.pl?sid=11/01/07/0533226

Интересует, что об этом думают ув.тов. операторы. Считаете ли вы это проблемой? Есть ли она в вашей сети? Пробовали её устранить, и что в результате получилось?

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

Share this post


Link to post
Share on other sites

Если правильно настроена приоритезация трафика, то те протоколы, которые будут дропатся - ни на что не повлияют. Телефония же дропатся не будет, как и другие "нужные" протоколы.

Share this post


Link to post
Share on other sites

Слишком много проверок checksumm (на каждом заголовке). в IPv6 это учли. кое где нет проверки.

Share this post


Link to post
Share on other sites
Насколько я понимаю, посыл автора заключается в том, что если в ЧНН канал работает близко к максимальной пропускной способности, для клиента при этом должен расти не пинг, а сразу процент потерь.

А вы нигде не слышали, что в гигабитном порту нельзя купить больше чем 700 мбит интернета? Ибо при пиках под 900 мбит это уже не интернет, сплошные дропы либо задержки.

Share this post


Link to post
Share on other sites
Слишком много проверок checksumm (на каждом заголовке). в IPv6 это учли. кое где нет проверки.
Не в этом дело.

Да и помимо контрольных сумм там ещё куча проверок, которые отнимают не меньше фактического времени, чем расчёт контрольной суммы, который часто делается аппаратно сетевухой при приёме.

Share this post


Link to post
Share on other sites
А вы нигде не слышали, что в гигабитном порту нельзя купить больше чем 700 мбит интернета? Ибо при пиках под 900 мбит это уже не интернет, сплошные дропы либо задержки.
Не слышали... А что, правда? Вот мы лохи... Выходит нас кинули?!?

 

Share this post


Link to post
Share on other sites
А вы нигде не слышали, что в гигабитном порту нельзя купить больше чем 700 мбит интернета? Ибо при пиках под 900 мбит это уже не интернет, сплошные дропы либо задержки.
а мужики то и незнали. покупать не покупаем, но есть нехилое множество точек, в которых гигабитный порт стабильно загружен на 92-99%, и никаких нареканий...

может не надо экономить на оборудовании и подробно изучать документацию?

Share this post


Link to post
Share on other sites
может не надо экономить на оборудовании и подробно изучать документацию?

Может надо было мат. статистику в школе учить?

Зайдите на свитч в котором этот гигабит формируется из нескольких портов и посмотрите количество заюзанных буферов.

 

Такой гигабитный порт при загрузке больше 80% дает около 1 мс джиттера, если хватает буфера.

Edited by Дегтярев Илья

Share this post


Link to post
Share on other sites
порт стабильно загружен на 92-99%

По графику в mrtg где счетчики снимаются раз в 5 минут?

Ну-ну про "стабильно"

 

Собирал как то статистику снимая счетчик раз в секунду с порта сервера отдававшего ~800 мбит трафика (по mrtg) в несколько сотен потоков.

Так вот битрейт на нем прыгал и ниже 600 мбит и под 950.

Выборки были при максимально разрешенной очереди в 100 пакетов.

Share this post


Link to post
Share on other sites
Может надо было мат. статистику в школе учить?

Зайдите на свитч в котором этот гигабит формируется из нескольких портов и посмотрите количество заюзанных буферов.

Такой гигабитный порт при загрузке больше 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 например).

Share this post


Link to post
Share on other sites
может не надо экономить на оборудовании и подробно изучать документацию?

Может надо было мат. статистику в школе учить?

Зайдите на свитч в котором этот гигабит формируется из нескольких портов и посмотрите количество заюзанных буферов.

 

Такой гигабитный порт при загрузке больше 80% дает около 1 мс джиттера, если хватает буфера.

На самом деле с гигабитами не всё так просто.

Правы и те кто говорят, что видел гигабитную скорость на данных портах и нет.

Просто GE порты разные. :)

Этот вопрос уже обсуждался чуть более года назад.

http://forum.nag.ru/forum/index.php?showto...st&p=448997

 

Share this post


Link to post
Share on other sites
Этот вопрос уже обсуждался чуть более года назад.

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, но медленней.

А в медиаконверторах еще необходимо найти байтовую синхронизацию.

Edited by Дегтярев Илья

Share this post


Link to post
Share on other sites

Имеем ряд линков в 700-800 мбит (усреднённая в 5 минут) и всё работает стабильно - джитер 1мс, задержка 1мс. При измерении iperf`ом линк даёт 0% потери пакетов и 1-2мс джитера.

При загрузки от 900 мбит начинается деградация сервиса. Джитер возрастает не сильно, появляется потеря пакетов порядка 0,05-0,1%. Это по трафику бестэфорд.

Все линки между cisco пылесосами.

 

Переход от etherchanel на 10GE не принёс прироста в суммарной скорости.

 

А 85% загрузки канала - это повод расширять его, при этом 4xGE загруженные на 85% - повод думать о 10GE.

Share this post


Link to post
Share on other sites
При загрузки от 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

Edited by Дегтярев Илья

Share this post


Link to post
Share on other sites

Такой гигабитный порт при загрузке больше 80% дает около 1 мс джиттера, если хватает буфера.

А не флов ли контрол просит заткнутся передающему не надолго?

Share this post


Link to post
Share on other sites
По этой же причине SFP-T стоят как паровоз. Принятые 10 бит необходимо запомнить, преобразовать и передать только 8, но медленней.

А в медиаконверторах еще необходимо найти байтовую синхронизацию.

В каком, простите, месте они стоят как паравоз?

Share this post


Link to post
Share on other sites
По этой же причине SFP-T стоят как паровоз. Принятые 10 бит необходимо запомнить, преобразовать и передать только 8, но медленней.

А в медиаконверторах еще необходимо найти байтовую синхронизацию.

В каком, простите, месте они стоят как паравоз?

видимо речь о родных cisco.. они реально по цене самолета.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this