fox_m

Получается, что "физических" ядер 20 на каждом ЦП, но каждое из них имеет по два как бы "виртуальных" ядра? Как когда то в hyper threading было?

Всем привет! Есть Blade сервер от Dell, с двумя установленными физическими процессорами Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz. В спецификации к ЦП указано, что у них по 20 ядер (40 потоков). т.е. по идее должно быть 40 ядер в сумме. Но ОС показывает в сумме 80 "процессоров". Откуда такое расхождение? И еще, cat /proc/cpuinfo показывает тоже 80 CPU, с 20 ядрами у каждого (cpu cores : 20) processor : 79 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz stepping : 7 microcode : 0x5003003 cpu MHz : 2743.262 cache size : 28160 KB physical id : 1 siblings : 40 core id : 26 cpu cores : 20 apicid : 117 initial apicid : 117 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes

Всем привет! Судя по логам у нашей WS-C3750G-12S вышел из строя какой-то из вентиляторов. Подскажите, подойдет ли вентилятор от WS-C3560G-24TS? 004052: Feb 10 09:34:03 MSK: %PLATFORM_ENV-1-TEMP: Abnormal temperature detected 004053: Feb 10 09:34:07 MSK: %HARDWARE-5-FAN_OK: Fan works fine 004054: Feb 10 09:34:09 MSK: %HARDWARE-2-FAN_ERROR: Fan Failure 004055: Feb 10 09:34:09 MSK: %PLATFORM_ENV-1-FAN: Faulty fan detected 004056: Feb 10 09:34:09 MSK: %PLATFORM_ENV-1-TEMP: Abnormal temperature detected 004057: Feb 10 09:34:10 MSK: %HARDWARE-5-FAN_OK: Fan works fine 004058: Feb 10 09:34:37 MSK: %HARDWARE-2-FAN_ERROR: Fan Failure 004059: Feb 10 09:34:37 MSK: %PLATFORM_ENV-1-FAN: Faulty fan detected 004060: Feb 10 09:34:37 MSK: %PLATFORM_ENV-1-TEMP: Abnormal temperature detected 004061: Feb 10 09:34:38 MSK: %HARDWARE-5-FAN_OK: Fan works fine

Понял. Спасибо за разъяснение.

Всем привет! Объясните, при сборке образа docker в самом верху по любому будет какая-то операционка: busybox, ubuntu и.т.п.? Без нее никак? И почему, когда я собираю образ под python, например и пишу FROM python, docker откуда то все равно вставляет в образ ОС ubuntu?

У вас префикс лист только default фильтрует. le 32 надо добавить по идее в конце

В общем пока на нашем кодере (elive) принудительно выставили CBR 4Мбит/c для выходной трубы. До этого он сам формировал трубу исходя из из битрейтов видео + аудио. IAT все равно остается высоким, но таких больших берстов пока не наблюдаем. Вообще есть подозрение, что проблема в кодере, поскольку с ним в последнее время что то происходить стало, и на некоторых потоках с него стали появляться CC error, хотя в исходных потоках все в порядке. В общем продолжаем наблюдать.

Понятно. Спасибо!

Почему на IAT обращать внимание? IAT - это по сути ведь джиттер? Кстати, он на этом канале раз в 10 больше, чем у остальных. Поток берем от партнера (RTMP через Интернет) и прогоняем его через свой кодер, что бы мультикаст получить на выходе.

В общем, вот такая картина получается. Видимо эти burst'ы и есть причина дропов. Самое интересное, у нас есть специальный анализатор мультика (Bridgetech), так он показывает максимальный битрейт не более 5 Мбит/c. Вот и доверяй ему после этого.

Подскажите, Max BW - это грубо говоря максимальный битрейт? Если то, то получается, что он достигал 160 Мб/c? И что значит колонка Mux Burst (в документации написано, что вроде это максимальное кол-во пакетов в единицу времени)? Тут тоже значения значительно отличаются от нормальных потоков.

Спасибо, попробую. А wireshark покажет эти burst'ы?

Всем привет. Столкнулся с такой проблемой. Есть коммутатор Cisco3750, к которому подключены потребители мультикаста. В какой-то момент, на одном интерфейсе стали сыпаться ТВ каналы, а на самом интерфейсе появились output drops. Дропы растут не постоянно, а примерно раз 5-10 мин. QoS активирован, под мультик выделена своя очередь с увеличенным буфером. Собственно, через коммутатор идет только мультикаст другого трафика можно сказать что нет. Пробовал крутить буфера, и настройки шедулера интерфейса, но не помогло. Дропы в мультикастной очереди продолжались. Проблемный интерфейс принимает ~ 50-70 разных мультикаст групп. Удалось заметить, что если отключиться от одной из групп, то все приходит в норму. Судя по всему, проблемная группа генерит какой-то странный поток или что-то в этом роде. Битрейт при этом у нее совсем небольшой ~ 4-5 мбит/c. Как он умудряется забивать буфера на интерфейсе совершенно непонятно. Что самое интересное, на других C3750 тоже возникают проблемы, если подключиться к этой проблемной группе. Что за хрень такая?

А какого рода проблемы?

У нас стримеры подключаются в разные коммутаторы стека для резервирования. В общем понятно, нужно проверять все

Да, еще вопрос. Стекирование они вроде как поддерживают?

Да, нам как раз нужно раздавать мультик со стримеров, ресиверов и мультиплексоров.

Главное, что нужно: OSPF, PIM-SM, PIM-SSM, QoS маркировка и поддержка очередей для разного вида трафика. Так же желательно vrf-lite. Буфера мелкие на портах?

Коллеги, добрый день! На работе добровольно-принудительно будем закупать коммутаторы Элтекс (типа импорто-замещение) на замену старым циско коммутаторам. На данный момент сеть моно-цисочная. Поделитесь пожалуйста впечатлением о данных устройствах. Сеть у нас в основном передает мультикаст трафик (провайдер IPTV). Не хотелось бы столкнуться с подводными камнями. Спасибо.

Спасибо!

Спасибо. А можете ссылкой поделится на доку?

Походу так и есть. Задал вопрос в саппорт Dell'овский. На Cisco тоже не было никогда проблем с этим диапазоном

Всем привет Никто не сталкивался с проблемой использования диапазона 232.0.0.0/8? Ситуация следующая, есть коммутатор Dell, встроенный в шасси для блейд-серверов. И по непонятной причине, он не обрабатывает IGMP Join на группы в 232.0.0.0/8 (не появляется в igmp snooping groups). Все во всех остальных диапазонах проблем нет. Есть подозрение, что это связано с тем, что 232.0.0.0/8 вроде как зарезервирован под PIM SSM.

Спасибо за информацию. Подумаем.

Коллега, а почем сейчас /48 ipv6 префиксы. Нам один из операторов большой 4-ки предалагает за 60к в год. Дороговато как-то.