![SimplyExplained](/img/default-banner.jpg)
- 91
- 23 628
SimplyExplained
Registrace 1. 10. 2022
Simple explanations of networking features and protocols. And verification of technologies I am interested in.
Note: This is simplified presentation of networking functions and protocols (for easier understanding of why and how). You still need to read standards and specs.
Простое объяснение сетевых протоколов и функций. И тестирование технологий которые мне интересны.
Важно: Это упрощённое представление функций и протоколов, чтобы облегчить их понимание (для чего они, и как работают). Спецификации всё равно надо читать.
Note: This is simplified presentation of networking functions and protocols (for easier understanding of why and how). You still need to read standards and specs.
Простое объяснение сетевых протоколов и функций. И тестирование технологий которые мне интересны.
Важно: Это упрощённое представление функций и протоколов, чтобы облегчить их понимание (для чего они, и как работают). Спецификации всё равно надо читать.
ИИ пишет мобильное приложение. Видео 4. Результаты проекта и Системного Теста.
Видео №4 в серии ИИ пишет мобильное приложение для меня.
Разработка закончена! Выкладываю приложение в магазины Apple, Google, Huawei и решаю связанные с этим проблемы.
Общий вывод: Предстоит огромная работа для того, чтобы ИИ мог приносить больше пользы, чем требуется усилий для работы с ним, или для того, чтобы заменить людей на некоторых должностях.
Статус приложения в магазинах:
- iOS. AppStore: На ревью, есть ошибки в версии iOS 17.5.1 iOS
- Android. Huawei AppGallery: Не компилируется. ИИ "соврал" мне о том, что для Huawei можно использовать ту де версию что и для Google.
- Android. Google Play Store: На закрытом тестировании.
0:00 Intro
0:22 Презентация приложения на симуляторе iPhone
4:16 Пример проблем в ответах ИИ
8:48 Описание достижений ИИ
17:19 Результаты системного теста
Предыдущие Видео:
Видео #3: czcams.com/video/MWYKgMP9bFs/video.html
Видео #2: czcams.com/video/BJLq1ErQqWA/video.html
Видео #1: czcams.com/video/vFTxewKTRMI/video.html
Видео возможностей приложения: czcams.com/video/CASY0muLfG0/video.html
Разработка закончена! Выкладываю приложение в магазины Apple, Google, Huawei и решаю связанные с этим проблемы.
Общий вывод: Предстоит огромная работа для того, чтобы ИИ мог приносить больше пользы, чем требуется усилий для работы с ним, или для того, чтобы заменить людей на некоторых должностях.
Статус приложения в магазинах:
- iOS. AppStore: На ревью, есть ошибки в версии iOS 17.5.1 iOS
- Android. Huawei AppGallery: Не компилируется. ИИ "соврал" мне о том, что для Huawei можно использовать ту де версию что и для Google.
- Android. Google Play Store: На закрытом тестировании.
0:00 Intro
0:22 Презентация приложения на симуляторе iPhone
4:16 Пример проблем в ответах ИИ
8:48 Описание достижений ИИ
17:19 Результаты системного теста
Предыдущие Видео:
Видео #3: czcams.com/video/MWYKgMP9bFs/video.html
Видео #2: czcams.com/video/BJLq1ErQqWA/video.html
Видео #1: czcams.com/video/vFTxewKTRMI/video.html
Видео возможностей приложения: czcams.com/video/CASY0muLfG0/video.html
zhlédnutí: 46
Video
AI writes a mobile app. Video 4. Project and Test Results overview.
zhlédnutí 9Před 7 hodinami
Video # 4 of series how AI write a mobile app for me. Coding is done! Release to Apple, Google and Huawei markets is problematic. General conclusion: There is huge task before AI start bringing more value that efforts required to operate it, and before AI could take some human jobs. App status: - iOS. AppStore: In review - reported errors for iOS version 17.5.1 iOS - Android. Huawei AppGallery:...
ИИ пишет мобильное приложение. Видео 3. С ИИ всё таки можно договорится.
zhlédnutí 11Před 19 hodinami
Видео №3 серии ИИ пишет мобильное приложение для меня. Приложение будет проверять фотографии в Photos смартфона на присутствие визуально похожих изображений и группировать их по подобию. Что ж, оказалось, что если следовать определенным правилам взаимодействия с ИИ, прогресс ускоряется. Но все равно, ИИ это очень мощный инструмент, а не решение. Решать придётся всё равно людям. Статус приложени...
AI writes a mobile app. Video 3. We can agree with AI
zhlédnutí 5Před 19 hodinami
Video # 3 of series how AI write a mobile app for me. App will check photos in smartphone's Photos and group them by visual similarity. Well, there are certain rules of interactions with AI that make progress better. But still, AI is a very powerful tool, not a solution. Human have to resolve task first. App status: iOS. AppStore: In review Android. Huawei AppGallery: In review Android. Google ...
AI writes a mobile app. Video 2. Examples of interactions with AI.
zhlédnutí 3Před dnem
Video #2. Working with AI. Getting into many issues and recovering from them. AI for now yet can't replace a human, but can speed-up work in RND and scientific research. First video about initial steps of AI in writing App: czcams.com/video/-hhEdTu-4Yo/video.html Screen recoding of app: czcams.com/video/asULfN7eawY/video.html App is in process of delivery to Google Play Store and Huawei AppGall...
ИИ пишет приложение. Видео 2. Примеры взаимодействия с ИИ.
zhlédnutí 19Před dnem
Видео №2. Работа с ИИ. Появились проблемы с кодом, и способ решения этих проблем. ИИ пока что не может заменить человека, но может значительно ускорить НИОКР и научные исследования. Первое видео о начальных шагах ИИ в написании приложения: czcams.com/video/vFTxewKTRMI/video.html Видео с готовым мобильным приложением czcams.com/video/CASY0muLfG0/video.html Приложение в процессе публикации в Goog...
Без Звука! Запись экрана работы мобильного приложения.
zhlédnutí 18Před dnem
Без звука! Мобильное приложение готово, но ещё не добавлено в магазины мобильных приложений. Это запись экрана, работа мобильного приложения, скрины, возможности.
No sound! App is ready. (but not delivered yet)
zhlédnutí 9Před dnem
No sound! Here is a screen recording of mobile app, its functions and capacities.
ИИ пишет приложение. Видео 1
zhlédnutí 21Před dnem
Видео №1 из серии видео "Как ИИ пишет мобильное приложение для меня". Спойлер: ИИ это улучшенный "спроси у Гугла" с плохим характером, потому что ИИ решает какой ответ лучше всех. И в целом пока что у ИИ лапки. ИИ это следующий технологический прорыв? Давайте его протестируем. Базовые требования к ИИ в этом тесте: - ИИ умнее людей в целом. - ИИ умнее людей в конкретных технологических знаниях и...
AI writes a mobile app. Video 1.
zhlédnutí 11Před dnem
Video #1 in a series of videos "how AI writes a mobile app for me". Spoiler: AI is advanced "ask Google" with attitude because AI decides what is the best answer. And in general AI has tiny little cute kitty paws. Is AI the next big thing? Let's test it. Basic Requirements to AI in this test: - AI is smarter than a human overall. - AI is smarter than a human in specific technology. - AI is fast...
No Audio. Method for Color-independent matching of Visual Scene similarity
zhlédnutí 9Před 2 měsíci
No Audio! Demo of color-independent method of matching Image (Visual Scenes) Matching. Visual Scenes will be found similar when they have the same objects in different colors, even if objects are rotated and shifted over Visual Scene.
Базовые понятия MPLS
zhlédnutí 858Před 4 měsíci
Простое объяснение основных определений, операций и функций MPLS
Simple explanation of MPLS
zhlédnutí 67Před 4 měsíci
Simple explanation of need for, basic definitions and basic operations of MPLS.
Базовые протоколы передачи данных
zhlédnutí 309Před 4 měsíci
Простое объяснение базовых протоколов передачи данных (пакетов данных). Это стандартные протоколы для обработки и передачи пакетов данных в сети.
Data Frames Transfer Protocol(s) basics
zhlédnutí 63Před 4 měsíci
Simple explanation of basic data frames transmit protocols basic operations. Those are standard protocols for data transfer used by all devices in the network.
Basic Snooping operations (IGMP Snooping and MLD Snooping)
zhlédnutí 173Před 6 měsíci
Basic Snooping operations (IGMP Snooping and MLD Snooping)
Основные операции Snooping (IGMP Snooping и MLD Snooping)
zhlédnutí 289Před 6 měsíci
Основные операции Snooping (IGMP Snooping и MLD Snooping)
Зачем мерять производительность(и простое объяснение - как и почему)
zhlédnutí 164Před 8 měsíci
Зачем мерять производительность(и простое объяснение - как и почему)
Meaning of Benchmarking and Performance measurements
zhlédnutí 30Před 8 měsíci
Meaning of Benchmarking and Performance measurements
BGP Выбор лучшего маршрута Best Path selection
zhlédnutí 227Před 8 měsíci
BGP Выбор лучшего маршрута Best Path selection
No sound. Usage of Demo Site to try tech for automated similar images detection
zhlédnutí 9Před 9 měsíci
No sound. Usage of Demo Site to try tech for automated similar images detection
No sound. Demo Site displaying storable/reusable image metadata for matching (so called hash)
zhlédnutí 7Před 9 měsíci
No sound. Demo Site displaying storable/reusable image metadata for matching (so called hash)
vtep интерфейс включаем в bridge (linux) в который включена виртуалка?
Короткий ответ: VTEP это ещё один интерфейс, нужный чтобы совершить некоторые действия с пакетом (добавить/убрать/изменить поля пакета нужные для операций с туннелем). VTEP связывает "Интерфейс локального конца туннеля" с "Интерфейсом для взаимодействия с host/станцией". К портам, на которых сконфигурирован "Интерфейс для взаимодействия с host/станцией" - подключаете виртуалки. К порту, на котором сконфигурирован "Интерфейс локального конца туннеля" - подключаете устройства нужные для дальнейшего выхода в сеть. Более развёрнутый ответ: Думал добавить схему, но в комментарии нельзя. Представьте себе схему прохождения пакета через маршрутизатор, от стороны host до входа в туннель, так Станция (host) -> Физический порт подключения host -> Интерфейс для взаимодействия с host (VLAN или IP интерфейс) -> VTEP -> Интерфейс локального конца туннеля ( Всегда IP интерфейс) -> Выходной физический порт --- ... ---> Второй конец туннеля Пакет проходит от выхода из туннеля в сторону host схематически так: Второй конец туннеля --- ... ----> Входной физический порт -> интерфейс локального конца туннеля (всегда IP интерфейс) -> VTEP -> Интерфейс для взаимодействия с host/станцией (VLAN или IP интерфейс) -> Физический порт подключения станции -> Станция (host) Я в этом видео рассказываю, что для упрощения сложных схем, можно рассматривать все так: есть порт - физическая дырка. Он нужен для физического подключения. Потом вы конфигурируете интерфейсы для определения того, какие наборы полей пакета и по каким правилам будут использоваться дальше (VLAN, Router Interface), и все остальные интерфейсы и протоколы это набор дополнительных правил либо реакции на значения полей пакета, либо для изменения полей пакета, их добавления/удаления. czcams.com/video/kyWbxySjhqE/video.html
что за срез? может это широковещательный домен?
Уточните пожалуйста вопрос. Где именно? Это схематическое представление router, потому что VxLAN в части передачи пакетов по туннелю работает по IP/UDP. Сторона, содержащая непосредственно станции/hosts (те станции которые общаются с другими станциями через туннель) могут использовать как L2 (VLAN) так и L3 (IP networks/sub-nets)
@@simplyexplained2642 host он же не знает ничего про VxVLAN. ip протокол хоста без arp запросов (они широковещательные) не сможет общаться с другими хостами. Один и тот же VxVLAN на разных площадках объединяет широковещательные домены хостов. arp запрос как попадает через VXVLAN на другую физическую ноду/узел
@@simplyexplained2642 почему то исчез мой вопрос про широковещание и arp ы между хостами на разных железках но в одной VxVLAN
Видео супер, удивлена, что у канала так мало подсписчиков. Очень доступно и понятно рассказывает!
Спасибо!
спасибо, коротко ясно
Спасибо!
просто топ
Спасибо!
Я вам признателен за данный материал , очень просто и понятно все обьяснили .
Спасибо!
Спасибо вам,отлично и понятно все объяснили
Спасибо!
Спасибо за доклад. Было бы интересно послушать про RT & RD.
Спасибо! Спасибо за идею!
Спасибо большое за ваш труд. Это реально все очень полезно. Но прошу вас выпустить ролик про Multichassis LAG EVPN. Я так понимаю эта реализация имеет rfc
Спасибо! Если вы имеете в виду комбинацию настроек MC-LAG (Multichassis LAG ) + EVPN, то это интересная комбинация, никогда такой не встречал, уточню. Возможно я что-то неправильно понял в вашем вопросе, если можете - уточните пожалуйста.
Я прошу прощения, это я не правильно понял. Я имею в виду EVPN мультихоминг. Это же может называться rfc реализацией mc-lag, на сколько я понимаю.
@@lekseiagrafenin2497 Спасибо за идею!
айпишка, айдишка - блювануть хочется
Приятного!
К сожалению не объяснили как dhcp сервер различает подсети, если запрос пришел от relay
Спасибо за вопрос. Отвечу кратко и детально. Кратко: Задача DHCP Relay - настроить промежуточный девайс так, чтобы DHCP пакеты доходили до нужных устройств. А уже DHCP Server оперирует сетевыми адресами и прочими настройками. Детальнее: Я разобью ответ на 2 части: 1. Как выбрать подсеть для устройства (девайса) и 2. Как DHCP Relay знает кому куда отвечать. 1.). Выбор подсети IP address конкретного устройства - это настройка DHCP Server. В конфигурационном файле указываются правила, по которым девайсу с каким-то MAC address выдаётся IP address в конкретной подсети (или даже конкретный IP address). У каждого девайса уникальный MAC address, который указан в DHCP пакетах (как минимум в Request/Reply, как Client Hardware Address) и по нему DHCP Server ищет настройки в своём конфигурационном файле, и предлагает IP address в нужной подсети, в зависимости от настроек администратора. 2.). Передача DHCP пакетов в правильные VLAN - это настройка DHCP Relay + FDB (устройство выучило, в каком VLAN на каком порту был получен пакет от устройства с MAC address = Source MAC из DHCP пакета). Я напомню, что все фактические операции с пакетами сводятся к нескольким базовым сетевым функциям - коммутации (switching), маршрутизации (routing) или нескольким другим. Все остальные протоколы, по сути нужны для уточнения параметров этих сетевых функций и/или для обработки данных на данном устройстве. studio.czcams.com/users/videokyWbxySjhqE/edit
Отлично, всё по полочкам и наглядно, спасибо огромное!
Спасибо!
Большое спасибо, коротко, ясно и по делу! Собственно, возникает вопрос исходя из Вашего видео, как VTEP понимает на какой DST-IP (VTEP) нужно отправить пакет, при условии, например, у нас множество VTEP и за каждым хост (виртуалка) в одном VNI Segment?
Спасибо! Ответ на ваш вопрос получается большим. Если ответ получился и непонятным - напишите, я попробую переформулировать. Термин "туннель" не совсем точно визуализиреут происходящее с трафиком. Это не две дыры в земле с соединяющими их дорогой. Это скорее два почтовых пункта. На оригинальном пакете указан конечный пункт назначения. Вы приносите этот пакет на ближайший к вам (в вашем VNI) пункт ЗАпаковки (VTEP_1). У пункта ЗАпаковки есть адрес ближайшего к конечному адресу пункту РАСпаковки (VTEP_2). Дальше ваш оригинальный пакет запаковывают ещё раз, и на новой упаковке указывают адрес пункта РАСпаковки (VTEP_2). И дальше по существующим дорогам и способам доставки отправляют в пункт РАСпаковки. Там его развернут (он попадёт в нужный VNI) и отправят к конечному адресату. Система работает точно так же. Мы на устройстве с VTEP_1 должны запаковать пакет и указать в новом IP-layer информацию об устройстве, на котором пакет распакуется. Другими словами мы знаем, что наш трафик должен достичь VTEP_2 - выхода из туннеля. В дополнительном IP указывается DST_IP = IP VTEP_2. SRC_IP = IP VTEP_1 (наш VTEP, на котором мы запаковываем пакеты). И дальше запакованный пакет маршрутизируется (routes, роутится) через существующие сети на VTEP_2, используя DST_IP = IP VTEP_2. Туннель должен иметь точку входа и точку выхода - они конфигурируются на устройстве !входа! с указанием нужных данных. На устройстве VTEP_1 мы конфигурируем информацию о VTEP_2, его IP и т.п. Если есть несколько разных туннелей, начинающихся на нашем устройстве - мы конфигурируем их все указывая наш VTEP_1 -> VTEP_2; VTEP_1 -> VTEP_3 и т.п. Или можно VTEP_1.1 -> VTEP_2, VTEP_1.2 -> VTEP_3, тут уже зависит от того, действительно ли вы хотите сконфигурировать несколько разных точек входа на одном и том же устройстве. Просто напоминаю, что туннель IPinIP и VxLAN однонаправленный. На точке входа конфигурируете туннель VTEP_1 - > VTEP_2. Если вам надо, чтобы трафик бежал обратно, вы на втором устройстве должны сконфигурировать туннель VTEP_2 -> VTEP_1.
Интересный контент! Спасибо! Интересно узнать о дальнейших планах на контент, какие темы хотели бы обозреть.
Спасибо. Сейчас готовлю видео по MPLS. И если у вас есть идеи о том, какие ещё важные и запутанные протоколы нуждаются в объяснении - пожалуйста, пишите.
@@simplyexplained2642 было бы интересно послушать про statefull/stateless
+
Отличный материал, четко, понятно, спасибо!
Спасибо!
очень круто все объяснено, коротко и понятно
Спасибо!
nice ! thank you, it helps!
Thank you!
о, наконец-то мультикаст))) автор, а практика настройки будет?)
Пока что не планирую долгие нудные лекции с деталями и нюансами. По Cisco видео с примерами много, а детали настройки зависят от конкретного производителя маршрутизатора, и, как правило, для каждого конкретного семейства устройств у производителя в документации примеры прописаны лучше всего. Эти видео планируются для того, чтобы максимально просто объяснить основные понятия и операции, и дальше, читая документацию с конкретными деталями люди кивали и говорили "угу, угу, угу" а не "это вообще они что кому на каком написали?"
@@simplyexplained2642 буду ждать долгие нудные лекции с деталями и нюансами. Уже давно перерос джун-уровень)
Спасибо!
А как используется адрес подсети? Какая там служебная информация ходит?
Если я словами сформулирую не совсем понятно - скажите, я попробую картинку нарисовать. Адрес подсети это "условная величина". В подавляющем большинстве случаев это число используется, чтобы определить направление, в котором находится хост, чтобы роутить туда трафик, предназначенный этому хосту. Представьте себе маршрутизатор (роутер), с тремя интерфейсами. И на нём сконфигурированы роуты (маршруты), которые говорят, что за одним интерфейсом находится подсеть с "адресом подсети" 11.12.13.0/24, за вторым 22.23.24.0/24, а за третьим 33.34.35.0/24. Тогда, если вам надо отправить пакет хосту 22.23.24.157, система выберет отправить его за второй интерфейс, потому что хост - где то там, в подсети с "этим адресом". При этом, сам по себе 0 в конце ничего не значит. Если у вас адрес хоста 44.55.66.0, но в этом сегменте так много хостов, что он имеет "адрес подсети" 44.55.0.0/16 - то адрес хоста ни у кого не вызывает вопросов. Даже больше, вы можете пользоваться "адресом подсети" как адресом хоста внутри своей подсети, например, у вас будет хост с IP 10.10.10.0 и второй 10.10.10.1, и они будут пингать друг друга в подсети 10.10.10.0/31 и даже 10.10.10.0/24, но вот уже настроить роутинг так, чтобы снаружи без проблем роутился трафик с dst IP 10.10.10.0 может оказаться проблемным (зависит от того, что у вас за устройства и какие защиты у них включены по умолчанию)
@@simplyexplained2642 задал вопрос, так как арендую сервер на hetzner с белой 29ой сеткой, подключенной через бридж гипервизора. Получается, что из сети теряется адреса: 1 для бриджа, 1 для сети, 1 для бродкаста, 1 для шлюза (это такие рекомендации от hetzner). И как бы что остается? Да ничего не остается... Есть идеи как это сделать по другому, но останавливать нельзя, да и IPMI там нет. А после прочтения комента думаю, что наверное можно навешать все, (кроме бродкаста) на адрес сети.
Офигительный канал! Автор очень крут! Одна гигантская просьба к автору, разбить все по плейлистам.
Спасибо! Я не разбивал нетворкинговые видео по плейлистам потому что они в некоторых протоколах взаимосвязаны и плей-листы будут пересекаются, но с учётом получившегося количества видео - согласен, я попробую их сгруппировать.
так, разобрали теорию, а практика будет?)
Если практика - это пройтись по конкретным протоколам мультикаст роутинга, вроде IGMP или DVMRP - да, есть планы. Если видео по настройке мультикаст в каких-то эмуляторах - то пока что нет в планах.
@@simplyexplained2642 да, я про эмуляторы
мля, у мекня глаз от англицкага выпал, но есть на русском. Благодарка
а за мультикаст поговорим?)
Хорошая идея, спасибо!
@@simplyexplained2642 я точно посмотрю про мультик
@@unicoxr5tj417 Тема мультикаста очень обширная, новое видео с обзором мультикаста тут: czcams.com/video/OXMp7JEGb-c/video.html
@@simplyexplained2642 посмотрел
Настроил на коммутаторах Dell пока ради теста. Хост подключенный к зеленому порту устройства 2 не пингует хост подключенный к зеленому порту устройства 3, и наоборот. Это нормально? Причина в том что обучения через пир линк не происходит. мак-таблица устройства 2 не содержит записей по устройствам подключеным к зеленым портам устройства 3, и наоборот. Видимо неправильно хотеть от этой схемы такой работы
В целом - да, задача MC-LAG в том, чтобы гарантировать связность для того устройства, которое находится на вершине этого треугольника: для синего устройства. И всё таки вы можете решить, что связность хостов за устройством 2 и хостов за устройством 3 вам всё таки нужна, и другого, хорошего, способа организовать её - нет. И тогда вы можете, например: - настроить роутинг (маршрутизацию) через УС как через маршрутизатор. У некоторых производителей роутинг на тот же интерфейс запрещён (если это по сути отражение/reflection пакета), по этому вы можете, к примеру, развести подсети по разным VLAN. Это усложняет общую конфигурацию MC-LAG :( - если Dell позволяет - настроить роутинг (маршрутизацию) через подсеть Peer портов. Но это всегда самый плохой способ, даже если разрешено вашим Dell, считается разумным блокировать не MC-LAG связность по Peer Ports. Там и так кипит работа. В принципе, фантазия и готовность выйти за границы разумного помогут вам в организации почти любой топологии. Когда получится настроить - поделитесь пожалуйста, как :) .
This explanation has everything I could need to understand the difference between GARP and ARP proxy. Simply wow. Liked and Subbed!
Thank you!
Спасибо посмотрел. Стало понятнее)
Спасибо!
Здравствуйте! А будет информация как обработка пакета происходит когда большая нагрузка на интерфейсе устройства. Интересует вопрос, как влияет нагрузка на задержки и как рассчитать какую задержку следует ожидать при определенной нагрузки линка между устройствами.
Здравствуйте! Спасибо за вопрос, я коротко :) отвечу на него в комментариях и потом попробую снять видео на эту тему. 1. Измерение задержек в зависимости от нагрузки - это часть Performance Benchmarking testing. Могут быть требования к задержкам в зависимости от условий эксплуатации устройства, или их измеряют по стандартам, чтобы сравнить с конкурентами. Для сетевых устройств стандарт: rfc 2544. datatracker.ietf.org/doc/html/rfc2544 Для датацентров стандарт rfc 8239 datatracker.ietf.org/doc/html/rfc8239 2. Hardware platforms for automated network testing такие как IXIA и Spirent имеют встроенную поддержку как минимум для тестирования по RFC2544, (проверьте, есть ли у вас соответствующие лицензии). 3. Допустимые значения задержек сильно зависят от типа сетей и оборудования, их назначения и т.п., их скорее всего надо искать в требованиях к проекту или к оборудованию для проекта, я даже не могу вспомнить, видел ли я хоть в каком-то стандарте такие требования. разве что в IEEE 802.3, но он чудовищный по размерам, просто не помню. 4. И коротко о собственно задержках. 4.1 Нагрузки на систему должны никак не влиять на возможности принять входной трафик. Это касается всех типов портов ethernet устройств. Система должна быть физически не в состоянии перегрузить вход. 4.2 Задержки "физически" появляются на выходе из устройства, после прохождения пакета от входа до выхода, сильно зависят от устройства, типа трафика, количества и типа активных протоколов и функций и т. п. Механизмы уменьшения задержек зависят от всего этого зоопарка. Важно: В стандарте описаны настройки и процедуры для измерения работы параметров системы !согласно стандарта! Если у вас специализированная система - вам надо мерять параметры системы и в условиях приближённых к фактическим условиям работы. 5. Борьба с задержками делиться на: a) собственно борьбу с задержками, например, самый простой способ влияния на свич (коммутатор) - store-and-forward поменять на cut-through b) реакцию на нагрузку ( CoS-QoS-DiffService) c) борьба с нагрузкой: паузы (PFC), можете посмотреть их обзор тут: czcams.com/video/0NxvsGLFHM8/video.html Если есть вопросы или хорошие идеи о чём ещё надо снять видео - пишите.
@@simplyexplained2642 Это из реального кейса, между двумя маршрутизатора линк в 100Гбит. При штатной работе пинг с маршрутизатора 1 до маршрутизатора 2 ~1 мсек. Трафик ~ 5-10 Гбит. В чнн трафик поднимается до 80-90 Гбит пинг увеличивается до 50мсек.
@@user-le8cx3uy3x О, хороший пример, поможет показать, почему в технических проектах так важно всё записывать. Вот смотрите, с человеческой точки зрения рост пинга во много раз - это слишком много и так быть не должно. С технической точки зрения - возникает 2 вопроса: 1) в каких условиях (что за конфигурация и трафик)? и 2) а какой рост в этих условиях допустимый? В вашем примере поведение можно разбить на четыре основных роли: - Пользователь продукта: начинает жаловаться на то, что при каких-то там 80-90 Гбит пинг увеличивается с 1 мсек до 50 мсек, ужасно, так жить нельзя, сделайте что-то и т.п. Что вполне ожидаемо. - Менеджер продукта (не технический): начинает бегать по офису с криком "Всё пропало, немедленно исправить, клиент уезжает, продукт простаивает а-а-а-а-а-а" - Девелопер, разрабатывающий этот маршрутизатор: спрашивает "а как должно то быть?" - Тестер продукта: Смотрите, пинг это IP/ICMP, который обрабатывается, скажем так, CPU маршрутизатора. Это полноценная обработка IP пакета (убрать Ethernet header, отправить на CPU, получить ответ с CPU, найти соответствующий IP Interface, проверить таблицу ARP и если нет записи опросить соседей, добавить Ether header, отправить). Это долго само по себе. Если вырос трафик, и это просто data-traffic который должен просто по L2 форвардиться по существующим правилам - то пинг, по идее так сильно расти не должен, если... : - если это не какой-то маршрутизатор, который всё делает через CPU. - Или если это какой-то трафик, который заставляет маршрутизатор интенсивно перестраивать таблицу машрутизации в X тысяч записей (смотря сколько поддерживается) или интенсивно учить ARP, или делать другие действия которые дополнительно грузят CPU. Тогда, в некоторых условиях, рост в 25 раз - это всего в 25 раз. - если есть конфигурация, которая позволяет дать пингу более высокий приоритет при обработке, и снизить задержку при сильных нагрузках, и эта конфигурация не срабатывает - ...... (другие варианты) Поэтому нужна дополнительная информация для того, чтобы реагировать на увеличение времени пинга: - Есть документ, в котором написано, что пинг соседа для 100Гбит подключения, в данной конфигурации и для данного типа трафика, или независимо от трафика, не должен превышать ххх мсек (сильно меньше или больше 50). - Вы сравниваете версии маршрутизаторов, и с таким же трафиком и конфигурацией, прошлая версия маршрутизатора проводила пинг за xxx мсек (ххх>50 или xxx<50, стало лучше, хуже, не поменялось) и надо что-то по этому поводу предпринять. Или нет. - Вы сравниваете производителей маршрутизаторов, и при одинаковой конфигурации и с таким же трафиком маршрутизатор другого производителя показал пинг ххх мсек, и вы, сравнив все параметры, выбираете производителя ...
At was that?
Idea is to detect all yogurt logos visible on the shelf. Photo was done at the shop, just passing by the shelf. Code is written on Python, and processing is just math (visual scene analysis), no ML. Simple segmentation mechanism is used (color-based) and algorithm have to use 3 detection params except of 2, but it's expected for simple segmentations.
Спасибо за базовые вещи простым языком!!!😊
Спасибо! :)