sawared Опубликовано 18 апреля, 2011 · Жалоба Собственно сам сабж для следующих вариантов подключений: 10 GE, 10 WAN пришедшая STM-64. Просто имея два таких линка максимально до 10 Гбит/с прогрузить оба не получается. Понимаю, что часть полосы под служебную инфу, но вопрос сколько максимум полезной нагрузки может пропустить каждое из таких подключений. У кого как? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 18 апреля, 2011 (изменено) · Жалоба Если на вскидку, то STM-1 -это 63 потока E1 в реале или 155 мбит со служебным трафиком stm-64 - 9920 мбит со служебным трафиком или 63*2*64=8064 мбит полезной нагрузки с stm-64 дел не имел, так что всё чисто теоретически. Изменено 18 апреля, 2011 пользователем secandr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 18 апреля, 2011 · Жалоба Если на вскидку, то STM-1 -это 63 потока E1 в реале или 155 мбит со служебным трафиком stm-64 - 9920 мбит со служебным трафиком или 63*2*64=8064 мбит полезной нагрузки с stm-64 дел не имел, так что всё чисто теоретически. как-то совсем мало , у нас полка рисовалась на 8.8г Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sawared Опубликовано 18 апреля, 2011 (изменено) · Жалоба Если на вскидку, то STM-1 -это 63 потока E1 в реале или 155 мбит со служебным трафиком stm-64 - 9920 мбит со служебным трафиком или 63*2*64=8064 мбит полезной нагрузки с stm-64 дел не имел, так что всё чисто теоретически. Харашо, пасиб за теорию. А на 10GE есть практика? Если на вскидку, то STM-1 -это 63 потока E1 в реале или 155 мбит со служебным трафиком stm-64 - 9920 мбит со служебным трафиком или 63*2*64=8064 мбит полезной нагрузки с stm-64 дел не имел, так что всё чисто теоретически. как-то совсем мало , у нас полка рисовалась на 8.8г И Вам пасиб. Есть кто ещё, кто юзал STM-64. Изменено 18 апреля, 2011 пользователем sawared Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j_box Опубликовано 18 апреля, 2011 · Жалоба http://runetmonitor.ru/books/10GigabitEthernet_EEA1100.pdf Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sawared Опубликовано 18 апреля, 2011 · Жалоба http://runetmonitor.ru/books/10GigabitEthernet_EEA1100.pdf Пасиб бегло проглядел получается пик для 10 WAN 9.2 Гбит/с полезной нагрузки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 18 апреля, 2011 · Жалоба Зависит от размера пакетов. При среднем размере пакета в 500байт получается примерно 9Гбит/с для 10GE LAN PHY, 8.5Гбит/с для 10GE WAN PHY и 9.5Гбит/c для STM-64(POS). (у HDLC размер L2 заголовка меньше, чем у Ethernet-фреймов - в этом весь секрет). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
biox Опубликовано 18 апреля, 2011 (изменено) · Жалоба Помимо гигабит в секунду есть ещё один не менее важный параметр - количество пакетов в секунду, которое способен обработать ваш девайс с 10Г портами... Потолок пропускной способности может быть достигнут гораздо ранее загрузки 10Гиг интерфейса и как раз по причине не хватки производительности девайса. Изменено 18 апреля, 2011 пользователем biox Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 апреля, 2011 · Жалоба (у HDLC размер L2 заголовка меньше, чем у Ethernet-фреймов - в этом весь секрет). В случае P2P линка можно вообще L2 заголовки не слать ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
j_box Опубликовано 18 апреля, 2011 · Жалоба р2р линк поверх стм-64 ага!... Найдите мне МГ линк, где есть "лишний" стм-64 и есть только р2р трафик на данном направлении! И готового(ых) заплатить за линк ценник стм-64 интерфейсов с двух сторон! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 18 апреля, 2011 (изменено) · Жалоба (у HDLC размер L2 заголовка меньше, чем у Ethernet-фреймов - в этом весь секрет). В случае P2P линка можно вообще L2 заголовки не слать ;) А как тогда выделять начало-конец фрейма из синхронного потока? Как определять какого протокола этот пакет? р2р линк поверх стм-64 ага!... Найдите мне МГ линк, где есть "лишний" стм-64 и есть только р2р трафик на данном направлении! И готового(ых) заплатить за линк ценник стм-64 интерфейсов с двух сторон! Ох и повеселили :D Изменено 18 апреля, 2011 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 19 апреля, 2011 (изменено) · Жалоба А как тогда выделять начало-конец фрейма из синхронного потока? Как определять какого протокола этот пакет? http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/rtpfast.html можно жать и tcp и rdp заголовки и между прочим получается довольно заметная экономия, правда CPU под это дело надо нехило. А тип фрейма, ip/tcp/rdp заголовок заменяются хеш-ссылкой по которому на другой стороне и восстанавливаются. Изменено 19 апреля, 2011 пользователем secandr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 апреля, 2011 · Жалоба А как тогда выделять начало-конец фрейма из синхронного потока? Как определять какого протокола этот пакет? Я про эзернет говорил, прямое соединение = P2P, и без свича. Собственно можно без мак адресов слать фреймы, а для протокола хватит 1 байта. Экономия 13 байт на пакет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 19 апреля, 2011 (изменено) · Жалоба А как тогда выделять начало-конец фрейма из синхронного потока? Как определять какого протокола этот пакет? http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/rtpfast.html можно жать и tcp и rdp заголовки и между прочим получается довольно заметная экономия, правда CPU под это дело надо нехило. А тип фрейма, ip/tcp/rdp заголовок заменяются хеш-ссылкой по которому на другой стороне и восстанавливаются. Ох, какие все умные ) rtp наверно таки, а не rdp? :) И сколько таких параллельных сессий оно может держать? Не масштабируется оно на S64. Там заменяется L3/4 заголовок и вводится специальный новый тип протокола, L2 заголовки оно не отменяет. А как тогда выделять начало-конец фрейма из синхронного потока? Как определять какого протокола этот пакет? Я про эзернет говорил, прямое соединение = P2P, и без свича. Собственно можно без мак адресов слать фреймы, а для протокола хватит 1 байта. Экономия 13 байт на пакет. Вендоры в рамках стандартов работают, поэтому такое оборудование не производят. Да и без МАК-ов этож не езернет уже, а практически POS ) Изменено 19 апреля, 2011 пользователем visir Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sawared Опубликовано 19 апреля, 2011 · Жалоба Спасибо милыи люди!!! Зависит от размера пакетов. При среднем размере пакета в 500байт получается примерно 9Гбит/с для 10GE LAN PHY, 8.5Гбит/с для 10GE WAN PHY и 9.5Гбит/c для STM-64(POS). (у HDLC размер L2 заголовка меньше, чем у Ethernet-фреймов - в этом весь секрет). У нас получается на WAN приходящий STM-64 не более 8.8 дальше полочка,а на 10 GE 9.5 и потом полка. Но жалоб хомячков нету. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ArcticFox Опубликовано 19 апреля, 2011 · Жалоба Кстати, у кого-нибудь лаба есть, для этой задачи? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 апреля, 2011 · Жалоба Вендоры в рамках стандартов работают, поэтому такое оборудование не производят. Да и без МАК-ов этож не езернет уже, а практически POS ) Собственно джамбофреймы никто не вспомнил, в рамках стандартов. И никто не запрещал вендорам реализовать это в железе обозвав какнить круто и отрекламировав, как циска со всеми своими(?) придумками делает. Типа на наших коммутаторах л3 при прямом соединении интерфейсов можно задействовать мега опцию для увеличения пропускной способности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 21 апреля, 2011 · Жалоба Вендоры в рамках стандартов работают, поэтому такое оборудование не производят. Спасибо, поржал. Если бы вендоры работали в рамках стандартов жить было бы скучно и не интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 27 апреля, 2011 · Жалоба alcatel OS9702E и Intel X520-SR2 общались между собой по 10GE на скорости до 9.7Гбит и 1.46мегапакетов/с (по графику немного больше 9.5). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
