Сообщение Re[14]: Разумность 16 байтных IP-адресов - ведь глупость сде от 12.11.2024 22:08
Изменено 13.11.2024 7:24 netch80
Re[14]: Разумность 16 байтных IP-адресов - ведь глупость сделали
Здравствуйте, B0FEE664, Вы писали:
S>>Скорости всегда мало — представь что запросов миллионы в секунду. И каждый IP нужно как-то обработать. Естественно нейтивно поддерживаемый процессором тип будет на порядки быстрее.
BFE>Ответ от ChatGPT:
BFE>
ChatGPT такой ChatGPT
Этот ответ не учитывает, что поиск по такой памяти чудовищно дорогой по энергии.
CAM — это, не считая мелких деталей, как L1 кэш в обычном процессоре, который полноассоциативный. Почему размер L1 кэша только-только перевалил за 64KB и подходит к 128? Причём это строками по 64 байта (стандарт сейчас почти везде), то есть это 2048 строк? Потому что если её увеличивать, то процессор закипит к хренам и расплавится. И это при поиске по длине ключа, например, 44-6=38 бита (если длина физического адреса 44 бита). А при 64? 128?
Фактически, в линейном процессоре одной карты в раутере объём той CAM это единицы тысяч строк. Дальше идут, опять же упрощая, аналоги следующих уровней кэша, как L2 и L3 (у которых уже нет полной ассоциативности), и процессорные блоки, которые их перезаполняют.
А основная засада тут в том, что в отличие от кэша для обычных процессорных задач, тут сильно меньше временно́й локальности (temporal locality), без которой кэш вообще бесполезен. Когда процессор ползёт по странице кода исполняя программу, там одна строка содержит десяток команд. Когда TLB miss вызывает поиск по иерархии page tables, там одним махом сразу решается 4KB (минимум для x86). Когда у тебя через один раутер ползёт сотня тысяч видеопотоков, каждый из которых это один IP пакетик раз в 10 или 20 мс, всей этой системе тупо плохо.
Фактически, нужные количественные характеристики достигаются там жёсткой параллельностью плюс скоростью памяти (DRAM уже непригодна).
И это ещё и усложняется тем, что запись такого кэша должна содержать не только целевой интерфейс, а ещё и довески в виде можно/нельзя, меток, и прочего.
Cisco свой CEF тут вылизывала несколько лет, прежде чем он надёжно заработал, а до того админы старались его выключать.
BFE>От себя добавлю, что если для поиска использовать B-Tree с ключом в байт, то разница между 8-байтовым адресом и 16 байтовым адресом будет всего 8 операций сложения и 8 операций сравнения, что не выглядит чем-то из-за чего стоит переживать.
Что-то очень странное и неадекватное говоришь.
Во-первых, в B-Tree ключи используются полной длины. Ты с Trie не перепутал? Там частичные ключи таки структурированы мелкими порциями, по биту или байту.
Во-вторых, 8 дополнительных лукапов на скорости нормального современного магистрального раутера могут уложиться в доступные временны́е рамки только при определённых ограничениях, из которых чуть ли не первое это неиспользование DRAM. Возьми ценник на память, умножь на 10 (объективно за счёт того, что на 1 бит не 1 транзистор, а почти десяток) и ещё на 3 (накрутка производителя раутера), посмотри, сколько её нужно на современные потребности (меньше 128MB не рассматриваем) и оцени, сколько нефти придётся выложить провайдеру на такую железяку.
И тогда пролетавшие тут рядом цены типа 47 миллионов деревянных перестают удивлять.
S>>Скорости всегда мало — представь что запросов миллионы в секунду. И каждый IP нужно как-то обработать. Естественно нейтивно поддерживаемый процессором тип будет на порядки быстрее.
BFE>Ответ от ChatGPT:
BFE>
BFE>6. Алгоритм CAM (Content-Addressable Memory)
BFE> CAM — это специальная память, используемая в маршрутизаторах для поиска совпадений в один такт, что делает её крайне быстрой.
BFE> Адрес назначения пакета вводится в CAM, и она сразу возвращает префикс с наибольшей длиной совпадения.
ChatGPT такой ChatGPT
Этот ответ не учитывает, что поиск по такой памяти чудовищно дорогой по энергии.
CAM — это, не считая мелких деталей, как L1 кэш в обычном процессоре, который полноассоциативный. Почему размер L1 кэша только-только перевалил за 64KB и подходит к 128? Причём это строками по 64 байта (стандарт сейчас почти везде), то есть это 2048 строк? Потому что если её увеличивать, то процессор закипит к хренам и расплавится. И это при поиске по длине ключа, например, 44-6=38 бита (если длина физического адреса 44 бита). А при 64? 128?
Фактически, в линейном процессоре одной карты в раутере объём той CAM это единицы тысяч строк. Дальше идут, опять же упрощая, аналоги следующих уровней кэша, как L2 и L3 (у которых уже нет полной ассоциативности), и процессорные блоки, которые их перезаполняют.
А основная засада тут в том, что в отличие от кэша для обычных процессорных задач, тут сильно меньше временно́й локальности (temporal locality), без которой кэш вообще бесполезен. Когда процессор ползёт по странице кода исполняя программу, там одна строка содержит десяток команд. Когда TLB miss вызывает поиск по иерархии page tables, там одним махом сразу решается 4KB (минимум для x86). Когда у тебя через один раутер ползёт сотня тысяч видеопотоков, каждый из которых это один IP пакетик раз в 10 или 20 мс, всей этой системе тупо плохо.
Фактически, нужные количественные характеристики достигаются там жёсткой параллельностью плюс скоростью памяти (DRAM уже непригодна).
И это ещё и усложняется тем, что запись такого кэша должна содержать не только целевой интерфейс, а ещё и довески в виде можно/нельзя, меток, и прочего.
Cisco свой CEF тут вылизывала несколько лет, прежде чем он надёжно заработал, а до того админы старались его выключать.
BFE>От себя добавлю, что если для поиска использовать B-Tree с ключом в байт, то разница между 8-байтовым адресом и 16 байтовым адресом будет всего 8 операций сложения и 8 операций сравнения, что не выглядит чем-то из-за чего стоит переживать.
Что-то очень странное и неадекватное говоришь.
Во-первых, в B-Tree ключи используются полной длины. Ты с Trie не перепутал? Там частичные ключи таки структурированы мелкими порциями, по биту или байту.
Во-вторых, 8 дополнительных лукапов на скорости нормального современного магистрального раутера могут уложиться в доступные временны́е рамки только при определённых ограничениях, из которых чуть ли не первое это неиспользование DRAM. Возьми ценник на память, умножь на 10 (объективно за счёт того, что на 1 бит не 1 транзистор, а почти десяток) и ещё на 3 (накрутка производителя раутера), посмотри, сколько её нужно на современные потребности (меньше 128MB не рассматриваем) и оцени, сколько нефти придётся выложить провайдеру на такую железяку.
И тогда пролетавшие тут рядом цены типа 47 миллионов деревянных перестают удивлять.
Re[14]: Разумность 16 байтных IP-адресов - ведь глупость сде
Здравствуйте, B0FEE664, Вы писали:
S>>Скорости всегда мало — представь что запросов миллионы в секунду. И каждый IP нужно как-то обработать. Естественно нейтивно поддерживаемый процессором тип будет на порядки быстрее.
BFE>Ответ от ChatGPT:
BFE>
ChatGPT такой ChatGPT
Этот ответ не учитывает, что поиск по такой памяти чудовищно дорогой по энергии.
CAM — это, несколько упрощённо, как L1 кэш в обычном процессоре, который полноассоциативный. (Упрощение потому, что в обычном кэше всегда одно совпадение по адресу, а тут может быть несколько, из них берётся лучшее.) Почему размер L1 кэша только-только перевалил за 64KB и подходит к 128? Причём это строками по 64 байта (стандарт сейчас почти везде), то есть это 2048 строк? Потому что если её увеличивать, то процессор закипит к хренам и расплавится. И это при поиске по длине ключа, например, 44-6=38 бита (если длина физического адреса 44 бита). А при 64? 128?
Фактически, в линейном процессоре одной карты в раутере объём той CAM это единицы тысяч строк. Дальше идут, опять же упрощая, аналоги следующих уровней кэша, как L2 и L3 (у которых уже нет полной ассоциативности), и процессорные блоки, которые их перезаполняют.
А основная засада тут в том, что в отличие от кэша для обычных процессорных задач, тут сильно меньше временно́й локальности (temporal locality), без которой кэш вообще бесполезен. Когда процессор ползёт по странице кода исполняя программу, там одна строка содержит десяток команд. Когда TLB miss вызывает поиск по иерархии page tables, там одним махом сразу решается 4KB (минимум для x86). Когда у тебя через один раутер ползёт сотня тысяч видеопотоков, каждый из которых это один IP пакетик раз в 10 или 20 мс, всей этой системе тупо плохо.
(Раньше сильно любили кэшировать характеристики конкретного flow, который определялся и парой IP, и портами. Но это работает на уровне ну до 1000 клиентов, и то не очень.)
Фактически, нужные количественные характеристики достигаются там жёсткой параллельностью плюс скоростью памяти (DRAM уже непригодна).
И это ещё и усложняется тем, что запись такого кэша должна содержать не только целевой интерфейс, а ещё и довески в виде можно/нельзя, меток, и прочего.
Cisco свой CEF тут вылизывала несколько лет, прежде чем он надёжно заработал, а до того админы старались его выключать.
BFE>От себя добавлю, что если для поиска использовать B-Tree с ключом в байт, то разница между 8-байтовым адресом и 16 байтовым адресом будет всего 8 операций сложения и 8 операций сравнения, что не выглядит чем-то из-за чего стоит переживать.
Что-то очень странное и неадекватное говоришь.
Во-первых, в B-Tree ключи используются полной длины. Ты с Trie не перепутал? Там частичные ключи таки структурированы мелкими порциями, по биту или байту.
Во-вторых, 8 дополнительных лукапов на скорости нормального современного магистрального раутера могут уложиться в доступные временны́е рамки только при определённых ограничениях, из которых чуть ли не первое это неиспользование DRAM. Возьми ценник на память, умножь на 10 (объективно за счёт того, что на 1 бит не 1 транзистор, а почти десяток) и ещё на 3 (накрутка производителя раутера), посмотри, сколько её нужно на современные потребности (меньше 128MB не рассматриваем) и оцени, сколько нефти придётся выложить провайдеру на такую железяку.
И тогда пролетавшие тут рядом цены типа 47 миллионов деревянных перестают удивлять.
S>>Скорости всегда мало — представь что запросов миллионы в секунду. И каждый IP нужно как-то обработать. Естественно нейтивно поддерживаемый процессором тип будет на порядки быстрее.
BFE>Ответ от ChatGPT:
BFE>
BFE>6. Алгоритм CAM (Content-Addressable Memory)
BFE> CAM — это специальная память, используемая в маршрутизаторах для поиска совпадений в один такт, что делает её крайне быстрой.
BFE> Адрес назначения пакета вводится в CAM, и она сразу возвращает префикс с наибольшей длиной совпадения.
ChatGPT такой ChatGPT
Этот ответ не учитывает, что поиск по такой памяти чудовищно дорогой по энергии.
CAM — это, несколько упрощённо, как L1 кэш в обычном процессоре, который полноассоциативный. (Упрощение потому, что в обычном кэше всегда одно совпадение по адресу, а тут может быть несколько, из них берётся лучшее.) Почему размер L1 кэша только-только перевалил за 64KB и подходит к 128? Причём это строками по 64 байта (стандарт сейчас почти везде), то есть это 2048 строк? Потому что если её увеличивать, то процессор закипит к хренам и расплавится. И это при поиске по длине ключа, например, 44-6=38 бита (если длина физического адреса 44 бита). А при 64? 128?
Фактически, в линейном процессоре одной карты в раутере объём той CAM это единицы тысяч строк. Дальше идут, опять же упрощая, аналоги следующих уровней кэша, как L2 и L3 (у которых уже нет полной ассоциативности), и процессорные блоки, которые их перезаполняют.
А основная засада тут в том, что в отличие от кэша для обычных процессорных задач, тут сильно меньше временно́й локальности (temporal locality), без которой кэш вообще бесполезен. Когда процессор ползёт по странице кода исполняя программу, там одна строка содержит десяток команд. Когда TLB miss вызывает поиск по иерархии page tables, там одним махом сразу решается 4KB (минимум для x86). Когда у тебя через один раутер ползёт сотня тысяч видеопотоков, каждый из которых это один IP пакетик раз в 10 или 20 мс, всей этой системе тупо плохо.
(Раньше сильно любили кэшировать характеристики конкретного flow, который определялся и парой IP, и портами. Но это работает на уровне ну до 1000 клиентов, и то не очень.)
Фактически, нужные количественные характеристики достигаются там жёсткой параллельностью плюс скоростью памяти (DRAM уже непригодна).
И это ещё и усложняется тем, что запись такого кэша должна содержать не только целевой интерфейс, а ещё и довески в виде можно/нельзя, меток, и прочего.
Cisco свой CEF тут вылизывала несколько лет, прежде чем он надёжно заработал, а до того админы старались его выключать.
BFE>От себя добавлю, что если для поиска использовать B-Tree с ключом в байт, то разница между 8-байтовым адресом и 16 байтовым адресом будет всего 8 операций сложения и 8 операций сравнения, что не выглядит чем-то из-за чего стоит переживать.
Что-то очень странное и неадекватное говоришь.
Во-первых, в B-Tree ключи используются полной длины. Ты с Trie не перепутал? Там частичные ключи таки структурированы мелкими порциями, по биту или байту.
Во-вторых, 8 дополнительных лукапов на скорости нормального современного магистрального раутера могут уложиться в доступные временны́е рамки только при определённых ограничениях, из которых чуть ли не первое это неиспользование DRAM. Возьми ценник на память, умножь на 10 (объективно за счёт того, что на 1 бит не 1 транзистор, а почти десяток) и ещё на 3 (накрутка производителя раутера), посмотри, сколько её нужно на современные потребности (меньше 128MB не рассматриваем) и оцени, сколько нефти придётся выложить провайдеру на такую железяку.
И тогда пролетавшие тут рядом цены типа 47 миллионов деревянных перестают удивлять.