SK>>Зачем поиск?
SK>>В процентном отношении как часто производится эта странная операция?
S>Приходит на роутер IP-пакет. В нем указан IP-адрес назначения. Вам нужно бинарным поиском по таблице найти куда его отправлять дальше.
Даже если смотреть на бинарный поиск (в реале там будет хэштаблица, а бинарный поиск максимум в ее bucket'ах) — то процедура поиска будет сравнивать не целиком 16байтные значения, а нативные, вторая половина адреса будет загружаться и сравниваться намного реже (лишь при совпадении первой), причем какую именно половину смотреть первой (а так же как считать хэш таблицу) можно сделать так, чтобы вторая часть сравнивалась как можно реже. То есть по факту потери скорости будут далеко не в 2 раза, но будут конечною

Здравствуйте, Serginio1, Вы писали:

<...>

N>>Теперь корректируем на 300 байт на пакет, на 100GBit/s линк (есть и такие уже), на рост таблиц BGP (при полном переходе на IPv6 его таблица минимум удвоится, если не дойдёт до миллиона, как сейчас с IPv4). Медленно охреневаем от числовых требований и понимаем, что без подхода типа "8 параллельных процессоров на каждой сетевой карте с полным объёмом данных в собственной памяти" это не работает. А я ещё не начал считать внутренние кросс-шины, сколько и как они должны пропустить...

S> Опять же когда ты используешь деревья для поиска, то для понимания больше меньше, тебе не надо сравнивать полностью 16 байт. В большинстве случаев хватает и 8.

В интересующем нас случае, как уже сказал, хватает и 6.
Но от этого совсем легко не становится.

S>Только в конце поиска тебе придется полностью сравнивать.

Это делается — в интересном случае — уже другим железом. (Домашний раутер и даже раутер уровня трёх многоэтажек у домового провайдера не показательны.)

S> Опять же посмотрим во сколько раз производительность процессоров и памяти выросла и количество ядер

И снова мух не ловишь и несёшь клиническую чушь.

"Производительность памяти", та, что выросла, это _потоковая_ скорость передачи _DRAM_ при условии нахождения в пределах открытой строки без смены адреса в пределах строки!
(Строка, ликбез, это элемент структуры DRAM. Например, 4GB модуль будет состоять из 8 чипов, каждый 65536*65536 бит, одна строка это 65536 бит в пределах чипа и 65536 байт в пределах модуля.)
Если тебе нужно перейти на другой адрес в пределах строки — теряешь 10 нс на лучших текущих DDR5 и 15 нс на бюджетных DDR4. Зовётся "CAS latency".
Если тебе нужно поменять строку — операция закрытия одной строки и открытия другой это от 30-32 нс в лучших DDR5 и 45-50 нс в бюджетных DDR4. И не видно, чтобы эти времена уменьшились в ближайшем будущем, почему и продолжают разбухать процессорные кэши.
А теперь забываем про эти цифры вообще и думаем про SRAM.

Теперь про производительность процессоров. Выросла она только на тех применениях, где получается применить конвейер и максимально длинное out-of-order исполнение. Например, на Skylake (для более поздних цифры я не нашёл, секретят) 97 команд x86 ISA и 224 микрокоманды, сделанных из них. Но это всё работает только когда нет постоянных branching miss! А на лукапе по таблицам раутинга именно он и будет довлеть (опять же, не домашний раутер, где нормально что 95% пакетов в течение часа это один фильм, а магистральный). Значит, все эти достижения — в топку, и остаётся голая тактовая. А она сейчас с максимально быстрыми и простыми процессорами ≈10ГГц и не растёт уже последние 20 лет, а если сложный процессор — замедляйся до 4ГГц или меньше. Цифры тактовой не выросли по сравнению с Pentium 4, а то и упали в массе, потому что растекаться лужицей от перегрева никому не хочется.

Количество ядер? А моё сообщение, что на каждое из таких ядер потребуется полная копия таблицы раутинга, чтобы не конфликтовать друг с другом — ты пропустил?
Сколько ядер влезет в один "камень", если каждому ядру потребуется 128MB SRAM? В лучших ксеонах от Intel, которые за 15 килобаксов, L3 кэш, как пишут, 504MB, но это один общий на все ядра.

И каждый день добавляется по несколько блоков IP в мировом раутинге, потому что всем хочется интернета.

Когда ты читаешь всякие 3dnews, где тебе рекламируют память для игрового компа и как новое поколение ускорило какой-нибудь Crysis аж на 2 FPS, включай голову и разбирайся, о каких именно характеристиках идёт речь. Ничего из твоих аналогий не работает в мире магистральных раутеров, и твой опыт идёт в /dev/null.

S> При этом 64 битные процессоры массово появились относительно недавно.

В мире Windows? Да, наверно. Он в этом смысле (и не только в этом) убог и ограничен.

S> И тоже крику было много. Однако живем и в мобильниках давно существует.

Как только пошёл вопрос о RAM толще 1GB, это стало неизбежно. И никто разумный по этому поводу не кричал.

Здравствуйте, netch80, Вы писали:

N>А вот вычисление маски плохо ускоряется.
N>А сделать заранее маску из длины префикса возможно не всегда. Я об этом.

Длин префиксов совсем немного. Можно табличку сделать.

Здравствуйте, netch80, Вы писали:

Это все прекрасно в теории! Сколько в итоге мы теряем при использовании 16 байтных IP-адресов?
В кэше не надо держать все адреса, а только часто используемые ну и так далее.
Кто то считал?

Здравствуйте, netch80, Вы писали:
N>А сделать заранее маску из длины префикса возможно не всегда. Я об этом.
А что нас остановит? Разных масок всего 127.

Здравствуйте, Serginio1, Вы писали:

S>Это все прекрасно в теории!

Я тебе голую-голейшую практику привёл.
Это проблемы, с которыми мировой раутинг сталкивается ещё с середины 90-х.
Авторитетно говорю как бывший старший админ провайдера, который держал BGP fullview.

S> Сколько в итоге мы теряем при использовании 16 байтных IP-адресов?

В полтора раза.
На 8-байтных адресах схемы адресации были бы, скорее всего, что блоки /24 для PA и до /32 для PI.
Соответственно в урезанном варианте хранились бы база+маска не по 8 байт каждый, а по 4; nexthop хранился бы не 16 байт, а 8.
Обращение в память 8-байтным словом давало бы не два обращения получить параметры для поиска в одном узле дерева, а одно.
И так далее.
Не два, а полтора — потому, что затраты на адресацию в дереве и на атрибуты раута не изменились бы.

S>В кэше не надо держать все адреса, а только часто используемые ну и так далее.

Кэша для fullview не может быть в принципе, и это я тоже описал в предыдущих сообщениях.
Никакого "ну и так далее".

S>Кто то считал?

Конечно, много раз. Читай профильные рассылки и отчёты, если хочешь хоть что-то знать по теме.

Здравствуйте, netch80, Вы писали:

S>>Кто то считал?

N>Конечно, много раз. Читай профильные рассылки и отчёты, если хочешь хоть что-то знать по теме.
Ну в итоге полтора раза. И из-за этого сыр-бор? Понятно, что будут затраты и компенсируются они количеством железа и различными алгоритмами, в том числе балансировки.
И вот почему то в базах используют GUID а не long итд?
Прежде всего удобство использования, а скорость не первостепенна!

Здравствуйте, netch80, Вы писали:

N>Только вот тут начинается особенность — нормальные люди все эти потрошка не выставляют в интернет голым мировым задом даже при наличии адресов. Им дают link-local, site-local (да, формально устаревшие), и прочее. Это если вообще у них будут IP адреса, а не локальные идентификаторы какой-то другой системы. Времена энтузиазма 90-х, когда думали, что можно выставить всех напрямую, давно прошли (ну, у вменяемых, разумеется. в разум комитетов я давно не верю), каждый очередной CVE и смысл буквы S в аббревиатуре IoT этому помогает.
У меня есть сомнения в критериях нормальности тут. Потому что вы пересказываете иными словами историю ранней IP-телефонии, когда каждый телефон при пробуждении тупо шёл по ftp://localname/mymacadress.xml и качал свою конфигурацию (включая SIP username & password). Потому что "нормальные люди все эти потрошка не выставляют в интернет голым мировым задом", сталбыть и секьюрности никакой не надо.
А потом наступил Cloud IP Telephony, когда у пользователя телефоны вполне себе торчат во внешнюю сеть, и никакого локального FTP-сервера для файлов конфигурации не существует.
И тут-то все и забегали — внезапно выяснилось, что толковые пацаны успешно угоняют пользовательские аккаунты и прекрасно звонят родственникам в антарктиду за счёт посторонних абонентов.

А всего-то надо было с самого начала вклеивать в устройства поддержку SSL и идентификацию по device certificate.
Аналогичные проблемы были с железом для видеоконференций: дегенераты-электронщики всё проектировали в парадигме "secured perimeter" и "corporate VPN". Поэтому примерно любой желающий с порт-сканнером мог безо всяких кредов зайти и посмотреть на митинг румы штаб-квартир корпораций из Fortune 500.

IoT — это ровно та же история, когда мы применяем "простую железку", и нам категорически не хочется думать ни о правилах файрволла для неё, ни о том, чтобы её как-то конфигурировать "локально".
Воткнул — работает. Отсканировал QR-код, зарегистрировал на себя у вендора, и настроил через вендорскую же контрольную панель. То, что лампочка с выключателем будут общатся по локальной сети — это, конечно плюс; но возможность выключить утюг, уже сидя в самолёте таки требует доступа в большой интернет.
И вот иллюзия того, что от хакеров можно защититься NAT-ом, а не криптографией — это иллюзия. Если протокол засекьюрен, то наличие прямого доступа ничем хакерам не поможет. (на всякий случай напомню, что примерно любой желающий сейчас эксплуатирует домашний роутер на белом IP-адресе; так что как минимум одна железка из дома торчит наружу — и никаких массовых взломов этих роутеров не происходит). Если не засекьюрен — то никакой NAT не спасёт: рано или поздно атака будет выполнена.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, netch80, Вы писали:
N>>А сделать заранее маску из длины префикса возможно не всегда. Я об этом.
S>А что нас остановит? Разных масок всего 127.

Тут уже вопрос, в какую сторону мы выгинаем компромисс.
Если раутер мелкого уровня, то проблем нет, работает любой подход — всё равно ресурса хватит.

А вот если магистральный...

Или мы заранее вычисляем и храним маску в данных дерева раутинга. Тогда эта часть дерева утолщается на ширину маски. Суммарные затраты растут. Пусть у нас один элемент дерева выглядит как

struct node {
  struct node *left, *right;
  check_addr_t base, mask;
  dest_addr_t nexthop;
  // тут может быть тип интерфейса, флаг "на самом деле дропаем нахер",
  // флаг "сложный случай, звать основной процессор", и т.п.
  int attributes;
}

(Не очень-то упростил, скорее всего. Потому что эту структуру придётся повторять на каждый раут, а их сейчас 200 тысяч в IPv6 full view и около миллиона в IPv4 full view. Поэтому их стараются ужимать до предела.)

Если хранится маска, получаем 60 байт (считаю int = 4 байта, check_addr_t — 16 байт, адресация памяти 32 бита).
Если хранится длина префикса, её можно поместить в attributes, остаётся 44 байт.
Экономия 36% — для таких задач очень существенна.
(А если check_addr_t на 8 байт, потому что раутинг глобальный, то получается, соответственно, 36 байт вместо 44. Тоже заметно, ~20%.)
Но тогда нужна поддержка получения маски из prefixlen. Если специализированный процессор или тем более ASIC — считаем, оно сделано в железе.
А если процессор 64-битный общего назначения — привет, бранчинг. Или лукап в памяти.
Лукап в памяти на каждый узел дерева, даже если это SRAM — дорого. Значит, делаем команду процессора.

Конечно, при выпуске миллионами это недорого. Тут Shmj неправ.
Но тщательно подумать (и вложиться) таки придётся.

Кстати, с расчётом количества масок ты сильно неправ.

Если считать все от /0 (все unicast для default route) до /128 (один адрес), то это 129 значений, а не 127.

Но реально сейчас маски в диапазоне от /65 до /127 включительно — практически невозможны. Остаются 66 значений.
Ну, легче от этого не будет

Здравствуйте, netch80, Вы писали:

N>Возьмём линк на 40Gbit/s, это нормальная скорость для провайдера мирового масштаба. Средний размер пакета очень плохо гуглится. Я считал 500 байт, но есть неясной авторитетности сообщения про 300 байт. Я готов поверить, потому что сейчас >90% трафика это видео.

Честно говоря, нарезать видео пакетами по 300 байт — это лютая жесть. Видео даёт достаточно большой поток данных, чтобы даже при небольшой задержке на агрегацию набирать полные пакеты по полтора килобайта.

И с учетом твоих слов, что сейчас 90% трафика — это видео (это утверждение выглядит весьма разумным), я бы предположил, что средняя длина пакета очень близка к 1.5K.

Остальные выкладки звучат вполне разумно.

N>Теперь корректируем на 300 байт на пакет, на 100GBit/s линк (есть и такие уже), на рост таблиц BGP (при полном переходе на IPv6 его таблица минимум удвоится, если не дойдёт до миллиона, как сейчас с IPv4). Медленно охреневаем от числовых требований и понимаем, что без подхода типа "8 параллельных процессоров на каждой сетевой карте с полным объёмом данных в собственной памяти" это не работает. А я ещё не начал считать внутренние кросс-шины, сколько и как они должны пропустить...

Попораздирающая история

Здравствуйте, Serginio1, Вы писали:

S> Опять же посмотрим во сколько раз производительность процессоров и памяти выросла и количество ядер. При этом 64 битные процессоры массово появились относительно недавно.
S>И тоже крику было много. Однако живем и в мобильниках давно существует.

Валентин говорит, всё в память упирается. Производительность памяти совсем не так быстро растет, как производительность процессоров.

Здравствуйте, Pzz, Вы писали:

S>> Опять же посмотрим во сколько раз производительность процессоров и памяти выросла и количество ядер. При этом 64 битные процессоры массово появились относительно недавно.
S>>И тоже крику было много. Однако живем и в мобильниках давно существует.

Pzz>Валентин говорит, всё в память упирается. Производительность памяти совсем не так быстро растет, как производительность процессоров.

Ну в итоге мы теряем в 1.5 раза. Это небольшая плата за удобства.

Здравствуйте, Sinclair, Вы писали:

N>>Только вот тут начинается особенность — нормальные люди все эти потрошка не выставляют в интернет голым мировым задом даже при наличии адресов. Им дают link-local, site-local (да, формально устаревшие), и прочее. Это если вообще у них будут IP адреса, а не локальные идентификаторы какой-то другой системы. Времена энтузиазма 90-х, когда думали, что можно выставить всех напрямую, давно прошли (ну, у вменяемых, разумеется. в разум комитетов я давно не верю), каждый очередной CVE и смысл буквы S в аббревиатуре IoT этому помогает.

S>У меня есть сомнения в критериях нормальности тут. Потому что вы пересказываете иными словами историю ранней IP-телефонии, когда каждый телефон при пробуждении тупо шёл по ftp://localname/mymacadress.xml и качал свою конфигурацию (включая SIP username & password). Потому что "нормальные люди все эти потрошка не выставляют в интернет голым мировым задом", сталбыть и секьюрности никакой не надо.
S>А потом наступил Cloud IP Telephony, когда у пользователя телефоны вполне себе торчат во внешнюю сеть, и никакого локального FTP-сервера для файлов конфигурации не существует.
S>И тут-то все и забегали — внезапно выяснилось, что толковые пацаны успешно угоняют пользовательские аккаунты и прекрасно звонят родственникам в антарктиду за счёт посторонних абонентов.

S>А всего-то надо было с самого начала вклеивать в устройства поддержку SSL и идентификацию по device certificate.

Да, позиция понятна и какая-то аналогия есть. Но очень ограниченная и как раз из первой части понятно, почему.

Когда были первые IP-телефоны, у них были крайне ограниченные ресурсы. Это ведь ещё 90-е. Что можно было поставить, например, в Cisco ATA186, Sipura 2000 и тому подобные железяки?
Я их разбирал. Внутри у SPA2000 (позднее Cisco PAP2) были:
1) Процессор — не помню как звался, но на MIPS-X(!), разработанный для проигрывания VideoCD(!) и потому имевший аппаратные подпорки для ITU-T кодеков.
2) ISA сетевуха Realtek 8019.
3) Силовой чип для поддержки абонентской линии. (В последующих зверях типа SPA841 — для телефонной трубки.)

Впихнуть туда что-то, умевшее SSL, просто не получалось (или жестоко тормозило). Это началось уже начиная с первой половины 2000-х, и началось именно с замены железа.

А вот в случае IoT всё сильно разнообразнее. В какой-нибудь электросчётчик впихнуть то, что умеет сформировать, закодировать и подписать пакет данных, не проблема: если оно сожрёт дважды в сутки два ватта в течение трёх секунд, никто и не заметит. Но там есть и такие устройства, которые должны висеть на внешней стене дома и работать 5 лет от одной батарейки — и при этом регулярно слать свой статус.

(Справедливости ради, такие устройства и не будут цепляться к 5G или что там сейчас. У них будет LoRa или что-то похожее. Вот там вообще раутинга не будет, только точка-точка.)

Но я согласен с тем, что нормальная защита в IoT придёт ещё не скоро. По этой аналогии или нет, но в ближайшие надцать лет выпускать их в большой внешний мир будет нежелательно.

S>Аналогичные проблемы были с железом для видеоконференций: дегенераты-электронщики всё проектировали в парадигме "secured perimeter" и "corporate VPN". Поэтому примерно любой желающий с порт-сканнером мог безо всяких кредов зайти и посмотреть на митинг румы штаб-квартир корпораций из Fortune 500.

А это уже проблема администрирования. Для видео нет портящих тут картину жёстких лимитов по железу, иначе оно не работало бы. Но запрос на "secured perimeter" и "corporate VPN" шёл и идёт не от электронщиков, а как раз от корпоративных админов и безопасников. Потому что те люди, что есть, не потерпят чрезмерных ограничений со стороны техники, они с ними не справятся. А защита в стиле "попал в периметр — уже имеешь какие-то права" это то, что работает как адекватный компромисс между шлепанутыми менеджерами по маркетингу и шизанутыми безопасниками.

S>IoT — это ровно та же история, когда мы применяем "простую железку", и нам категорически не хочется думать ни о правилах файрволла для неё, ни о том, чтобы её как-то конфигурировать "локально".
S>Воткнул — работает. Отсканировал QR-код, зарегистрировал на себя у вендора, и настроил через вендорскую же контрольную панель. То, что лампочка с выключателем будут общатся по локальной сети — это, конечно плюс; но возможность выключить утюг, уже сидя в самолёте таки требует доступа в большой интернет.
S>И вот иллюзия того, что от хакеров можно защититься NAT-ом, а не криптографией — это иллюзия. Если протокол засекьюрен, то наличие прямого доступа ничем хакерам не поможет. (на всякий случай напомню, что примерно любой желающий сейчас эксплуатирует домашний роутер на белом IP-адресе; так что как минимум одна железка из дома торчит наружу — и никаких массовых взломов этих роутеров не происходит). Если не засекьюрен — то никакой NAT не спасёт: рано или поздно атака будет выполнена.

Это всё потому так, что тема тех же раутеров уже стабилизировалась — что они делают, как и почему. Любой очередной Лян Ляо, решивший производить теперь с клубничным вкусом, просто берёт готовую разработку вплоть до корпуса и мажет его клубникой со своей грядки.
А для IoT до стабилизации ещё долго.

А стабилизируется IoT — ещё что-то выползет...

Здравствуйте, Pzz, Вы писали:

Pzz>Честно говоря, нарезать видео пакетами по 300 байт — это лютая жесть. Видео даёт достаточно большой поток данных, чтобы даже при небольшой задержке на агрегацию набирать полные пакеты по полтора килобайта.

Pzz>И с учетом твоих слов, что сейчас 90% трафика — это видео (это утверждение выглядит весьма разумным), я бы предположил, что средняя длина пакета очень близка к 1.5K.

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

Ну, разделим цифры потребности на 3. Всё равно прямо сейчас постоянно утыкаемся в этот предел.

Pzz>Остальные выкладки звучат вполне разумно.

N>>Теперь корректируем на 300 байт на пакет, на 100GBit/s линк (есть и такие уже), на рост таблиц BGP (при полном переходе на IPv6 его таблица минимум удвоится, если не дойдёт до миллиона, как сейчас с IPv4). Медленно охреневаем от числовых требований и понимаем, что без подхода типа "8 параллельных процессоров на каждой сетевой карте с полным объёмом данных в собственной памяти" это не работает. А я ещё не начал считать внутренние кросс-шины, сколько и как они должны пропустить...

Pzz>Попораздирающая история

Ага, так оно и есть. А ещё если учесть, что этих раутеров не так уж много в мире, вряд ли больше сотни тысяч, а одной модели могут быть вообще тысяча-другая, поэтому ещё в цене затраты на мелкосерийный выпуск чипов, на разработку софта... тяжела и неказиста жизнь в Cisco, Juniper и прочих

Здравствуйте, Serginio1, Вы писали:

N>>Конечно, много раз. Читай профильные рассылки и отчёты, если хочешь хоть что-то знать по теме.
S> Ну в итоге полтора раза. И из-за этого сыр-бор? Понятно, что будут затраты и компенсируются они количеством железа и различными алгоритмами, в том числе балансировки.

Когда выбирают между вендорами или решениями из-за разницы в 2-5% в цене, это существенно. А таких случаев достаточно, большинство не пойдут на бо́льшую цену за туманные перспективы. За откат — пойдут, а за туман — нет.

S> И вот почему то в базах используют GUID а не long итд?

И снова путаешь тёплое с мягким.

GUID вместо long считается обязательным для случая, когда генерация id производится разными независимыми источниками, и надо обеспечить непересечение в этом случае. Вроде бы случая совпадения GUIDов (типы 1, 4, 7 — все пригодные для этого) при честном соблюдении принципов генерации ещё не было.

А если источник заполнения только один — long, int, что угодно — к вашим услугам, проще и экономнее, и таких баз полно вокруг.

Я удивляюсь, насколько ты не разбираешься технически в том, что называешь ;\

S> Прежде всего удобство использования, а скорость не первостепенна!

Не везде и не всегда. Половина дискуссии тут посвящена тому, что "случай — он разный бывает".

Здравствуйте, Serginio1, Вы писали:

S>>> Опять же посмотрим во сколько раз производительность процессоров и памяти выросла и количество ядер. При этом 64 битные процессоры массово появились относительно недавно.
S>>>И тоже крику было много. Однако живем и в мобильниках давно существует.

Pzz>>Валентин говорит, всё в память упирается. Производительность памяти совсем не так быстро растет, как производительность процессоров.

S> Ну в итоге мы теряем в 1.5 раза. Это небольшая плата за удобства.

Так нет его, реального удобства, от 128-битных адресов вместо 64-битных.

Есть обещания того, что мы ещё 50 или 100 лет не будем перестраивать сети из-за этого. Но практика показывает, что за такой срок вообще все парадигмы изменятся до неузнаваемости.

А реальные неудобства пришли с самого начала и видны сейчас.

Здравствуйте, netch80, Вы писали:

N>Да, я не смог найти данные о том, какой же реальный средний размер пакета в последнее время (и как это среднее считается — тут хорошо бы вообще табличку децилей найти).
N>Попробую ещё поискать.

Подкину тебе ище забавных наблюдений, хоть и не совсем на эту тему.

Если посылать потоком пакеты разного размера, короткие пакеты имеют тенденцию иногда обгонять более длинные. Выдимо, у кого-то traffic shaper по дороге считает в байтах, длинный пакет уткнулся в ограничение и пошел полежать в очереди, а короткий проскочил вперед.

Здравствуйте, Pzz, Вы писали:

N>>Да, я не смог найти данные о том, какой же реальный средний размер пакета в последнее время (и как это среднее считается — тут хорошо бы вообще табличку децилей найти).
N>>Попробую ещё поискать.

Pzz>Подкину тебе ище забавных наблюдений, хоть и не совсем на эту тему.

Pzz>Если посылать потоком пакеты разного размера, короткие пакеты имеют тенденцию иногда обгонять более длинные. Выдимо, у кого-то traffic shaper по дороге считает в байтах, длинный пакет уткнулся в ограничение и пошел полежать в очереди, а короткий проскочил вперед.

Да, это типовая картина.
Я на такое натыкался в варианте с туннелями. Туннель был, который не сокращает MTU для внутреннего линка, а фрагментирует внешний пакет. А приёмный хост имел почему-то проблемы с дефрагментацией, если второй фрагмент приходил вперёд первого. Потери на сборке достигали 20%, насколько помню.
Попытались урезать MTU на входе — нарвались, что из-за каких-то кривостей стека (которые исправили через год) ICMP need defrag не слался.
Картина Пикассо "Полная задница", пришлось переходить на совсем другие подходы...

Здравствуйте, netch80, Вы писали:


S>>>> Опять же посмотрим во сколько раз производительность процессоров и памяти выросла и количество ядер. При этом 64 битные процессоры массово появились относительно недавно.
S>>>>И тоже крику было много. Однако живем и в мобильниках давно существует.

Pzz>>>Валентин говорит, всё в память упирается. Производительность памяти совсем не так быстро растет, как производительность процессоров.

S>> Ну в итоге мы теряем в 1.5 раза. Это небольшая плата за удобства.

N>Так нет его, реального удобства, от 128-битных адресов вместо 64-битных.

N>Есть обещания того, что мы ещё 50 или 100 лет не будем перестраивать сети из-за этого. Но практика показывает, что за такой срок вообще все парадигмы изменятся до неузнаваемости.

N>А реальные неудобства пришли с самого начала и видны сейчас.

Вопрос такой какую часть занимает поиск Ip адреса от передачи данных? А там нет никакого кэша итд.
Во, что в итоге упираемся?
И так и не ответил, а как жили при 32 разрядных процессорах?

Здравствуйте, Pzz, Вы писали:

Pzz>Честно говоря, нарезать видео пакетами по 300 байт — это лютая жесть. Видео даёт достаточно большой поток данных, чтобы даже при небольшой задержке на агрегацию набирать полные пакеты по полтора килобайта.

Pzz>И с учетом твоих слов, что сейчас 90% трафика — это видео (это утверждение выглядит весьма разумным), я бы предположил, что средняя длина пакета очень близка к 1.5K.

Спросил тех кто прямо сейчас в теме. Ответ очень странный: большинство вендоров проверяют на https://en.wikipedia.org/wiki/Internet_Mix который не менялся существенно с ≈2013, и фиксируют результаты по нему.

А в этом источнике больше половины пакетов по объёму это 576 байт (Simple Imix) и по любому меньше 1500 (Accurate Imix).

Так что или им надо методики менять, или я оказался точнее в прогнозе, чем ты.