Запись. Снова GeeseFS показал лучшие результаты с пропускной способностью: 24,7 MiB/s (25.9 MB/s) против 44,1 MiB/s (46,3 MB/s). Это указывает на лучшую оптимизацию чтения у GeeseFS.
Похоже, в конце процесса написания статьи автор устал и перестал следить за текстом и содержимым. 24.7 MiB/s - это хуже, чем 44,1 MiB/s, а не лучше
демонстрировал более стабильную производительность с пиковым значением 16,91 мс против 300,555 мс у Goofys
Кто именно демонстрировал?
Пиковым значение составило 8,982 мс по сравнению с 121,541 мс у Goofys.
Очень классная статья, спасибо. Наглядно, с понятными и логичными примерами. Даже у меня, новичка в Истио, неясностей и вопросов по описанным схемам и сценариям не возникло.
В TCP нигде не используется TLS , TCP о нём ничего не знает.
"Это мой первый пост, рад любой критике."
Покритикую. Прежде, чем публиковать статью, сначала её надо несколько раз перечитать самому, чтобы привести в порядок орфографию, грамматику ( желательно и стилистику тоже), перепроверить смысл написанного в каждом абзаце. Затем отложить хотя бы на день и на свежую голову перечитать заново. Если ничего больше не режет глаз, то тогда уже публиковать. А из-за множества ляпов ценность статьи падает.
И в дополнение к упомянутым недостаткам можно упомянуть:
Повышенную утилизацию cpu из-за обязательности шифрования
реализация только в userspace. В ядре Линукса - неизвестно, когда (насколько понимаю)
таймауты для UDP на промежуточных устройствах ( FW, к примеру) обычно гораздо более агрессивные, чем для TCP, это может негативно влиять на сессии quic-а
Большое спасибо за примеры с bash скриптами! Отличная идея, как быстро организовать перебор портов при проверке и выдавать данные о доступности через AND/OR. Век живи - век учись:)
Mac флаппинг поверх какого-нибудь варианта оверлея , не реализующего соответствующий механизм защиты от него, может приводить к весьма неприятным последствиям. Некоторые вендоры отыгрывают такую ситуацию жёстким err.disable физич.интерфейса, с которого летит флапающий mac
Проблему потери связности по BGP между коробками вследствие падения нижестоящего протокола , думается, вполне решило бы наличие аварийного статич. маршрута для общего префикса подсети опорных loopback интерфейсов со сбросом в Null (чуть выше в комментах упомянули о blackhole). В нормальном рабочем состоянии системы данный маршрут less specific, и ни на что не влияет. Кажется, этого было бы достаточно, чтобы п.п.2-3 не триггернули. По этой проблеме видится ошибка проектирования.
Интересно, для чего на коробках clos фабрики на М9 потребовался dhcp функционал
Похоже, в конце процесса написания статьи автор устал и перестал следить за текстом и содержимым. 24.7 MiB/s - это хуже, чем 44,1 MiB/s, а не лучше
Кто именно демонстрировал?
Туда же:)
Очень классная статья, спасибо. Наглядно, с понятными и логичными примерами. Даже у меня, новичка в Истио, неясностей и вопросов по описанным схемам и сценариям не возникло.
Оригинал здесь:
https://community.cisco.com/t5/networking-knowledge-base/34-things-about-ospf/ta-p/3162082
у меня сначала по ходу чтения возникло ощущение, что тут не обошлось без Сhat GPT, а он в русский пока не умеет, вроде как :)
"...но поскольку он построен на UDP, который не ориентирован на связь.."
"Поскольку QUIC подключается клиент и сервер одним соединением..."
"...быстрее обрабатывать восполнение хвостовых задержек..."
И такого
"В TCP также используется TLS,..."
В TCP нигде не используется TLS , TCP о нём ничего не знает.
"Это мой первый пост, рад любой критике."
Покритикую. Прежде, чем публиковать статью, сначала её надо несколько раз перечитать самому, чтобы привести в порядок орфографию, грамматику ( желательно и стилистику тоже), перепроверить смысл написанного в каждом абзаце. Затем отложить хотя бы на день и на свежую голову перечитать заново. Если ничего больше не режет глаз, то тогда уже публиковать. А из-за множества ляпов ценность статьи падает.
И в дополнение к упомянутым недостаткам можно упомянуть:
Повышенную утилизацию cpu из-за обязательности шифрования
реализация только в userspace. В ядре Линукса - неизвестно, когда (насколько понимаю)
таймауты для UDP на промежуточных устройствах ( FW, к примеру) обычно гораздо более агрессивные, чем для TCP, это может негативно влиять на сессии quic-а
Большое спасибо за примеры с bash скриптами! Отличная идея, как быстро организовать перебор портов при проверке и выдавать данные о доступности через AND/OR. Век живи - век учись:)
Mac флаппинг поверх какого-нибудь варианта оверлея , не реализующего соответствующий механизм защиты от него, может приводить к весьма неприятным последствиям. Некоторые вендоры отыгрывают такую ситуацию жёстким err.disable физич.интерфейса, с которого летит флапающий mac
Проблему потери связности по BGP между коробками вследствие падения нижестоящего протокола , думается, вполне решило бы наличие аварийного статич. маршрута для общего префикса подсети опорных loopback интерфейсов со сбросом в Null (чуть выше в комментах упомянули о blackhole). В нормальном рабочем состоянии системы данный маршрут less specific, и ни на что не влияет. Кажется, этого было бы достаточно, чтобы п.п.2-3 не триггернули. По этой проблеме видится ошибка проектирования.
Интересно, для чего на коробках clos фабрики на М9 потребовался dhcp функционал