Не вижу никаких противоречий с высказыванием Серфа
Интервью с Серфом: адрес зафиксировали в 1973, 128 стран, 24 бита на сеть, 16 миллионов компьютеров на сеть - для эксперимента точно достаточно.
Документы: фиксация адреса откладывается до 1979±1 - уже не эксперимент, а крупный оборонный проект и мотив решения - скорость (не MVP для доработки). 1979 - это уже 100К продаж TRS-80 и статья о том, как военные уплотняют мультимедиа для сетей (7 аудиокодеков).
Где-то здесь ошибка.
Даже если он бы решился выбрать больше, на него бы посмотрели как на дурака: «больше 4 миллиардов дорогущих устройств?».
100К продаж с "starting price of US$600" - перспективы можно углядеть (IBM сразу углядела, до IBM PC два года).
А если на два года в прошлое (1977), то там Xerox в своём протоколе расширяет адрес до 32+48 бит (MAC-адрес). Xerox тоже что-то знал.
Никто тогда не мог составить точный прогноз. Как результат, при разработке IPv6 выкинули всё ненужное.
Это инфраструктура (вроде водопровода), тут всё-таки не важно, насколько приятно выкидывать легаси и переписывать с нуля.
Переменная длина заголовка пакета кстати тоже создаёт некоторый геморрой при обработке. В IPv6 это учли.
В IPv4+4 - тоже. Если бы продавливали решение через Options, то пакет с extra-addr-option тоже был бы фиксированной длины. Если бы совсем отбросили амбиции и попытались набирать ~14 бит через запрет фрагментации, то одинаковой длины с IPv4.
Обеспечение адресами IPv6 тех, кому не предоставляется нативный IPv6 адрес
Так речь о том, чтобы автоматически наделить владельца белого IPv4 адресами нового протокола (~2^(14..32) штук).
Средства для взаимодействия между IPv4 и IPv6. По сути это просто разновидности NAT.
В перечисленных мной вариантах это должен быть обычный NAT. И как можно было принять 464XLAT через ~15 лет после IPv6? ("Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы")
Для других протоколов получилось примерно бы тоже самое.
То есть совсем другое.
заставить работать с помощью костыля
IPv6 - сам по себе костыль, только в особом смысле - костыль из башни слоновой кости с синдромом второй системы. Он должен был дать адреса и смотреться выгоднее CGNAT'а в нулевых. Сверх этого можно давать фичи, но давать их вместо - нельзя.
Ещё из RFC1726: "4.1 Архитектурная простота. Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать". Отлично подходит к IPv6.
Они промахивались насчёт IPsec, насчёт лёгкости миграции с IPv4, насчёт связности, возведённой в абсолют, потому что из начала 90-х было трудно предсказать ситуацию через 10-20 лет - и не надо было этого делать. Надо было в соответствии с цитатой отсекать всё, что помешает полному переходу через 15 лет.
Тот же IPv4 по сути протокол лабораторный. Он не был предназначен для коммерческого использования.
Сам руководитель разработки Винт Серф признавался, что он делал протокол чисто для проверки концепций.
Банально, руководителю проекта в голову не могли прийти
Их хватило бы на все мыслимые и немыслимые эксперименты в то время.
Ага, а параллельно существует совсем другая история для взрослых, в которой за 1-2 года:
зафиксировали длину IPv4-адреса ради скорости
за кучу денег пересадили на протокол всю военку, это будет MIL-STD-1777
в журнале "Вестник компьютеризации" Computerworld пишут о годноте для бизнеса, за ваши налоги, без вендор-лока IBM, скоро в широком доступе
Собственно, история
Середина 1978: в IPv4 ещё адрес переменной длины, на месте контрольной суммы стоят длины адресов.
Конец 1979: "Vint ... cited the performance of the system as a key issue" - пора фиксировать длину адреса.
"Rosenthal recalls: ... Vint Cerf and company went off to invent TCP at the time because they got lots of DOD money to make networks work"
"Throughout 1979, Kahn and Cerf lobbied the DOD to make TCP/IP an official communication protocol standard"
"in December 1980, the DOD publicly unveiled TCP/IP"
Computerworld 1981: "May 15 ... plans to market TCP/IP as part of its VAX/VMS network software package for DEC" и пересказ остального: "на ваши налоги сделали протокол (военный стандарт) - как у IBM, только лучше и без вендор-лока, его уже тестируют на процессорах IBM, DEC, Honeywell, CDC, HP и PerkinElmer. В следующем году он будет широко доступен коммерческим пользователям".
а в протокол была заложена расширяемость (ну вдруг кто-то зачешется), спецификация требует: "each internet module must be able to parse every option [options = блок переменной длины в конце заголовка]"
IPv6 же изначально создавался для коммерческого использования.
Ещё одна былина.
"Самолёт может взлететь с авиносца А и сесть на авианосец Бэ" - Технические критерии по выбору IP нового поколения, 1994.
Он создавался как IPv4 - для всех, и для особого клиента в том числе - для родной военки.
И как раз в нём были исправлены косяки IPv4.
Присмотритесь:
из коммента выше
Перед новогодними праздниками (декабрь 1994, RFC1726): нужен протокол с безупречным планом миграции. После новогодних праздников (январь 1995, RFC1752): подписываем протокол без плана миграции, единственный из трёх.
Что последовало за этим дальновидным решением? Wikipedia / List of IPv6 transition mechanisms
Stateless IP/ICMP Translation
Tunnel broker
6rd
Transport Relay Translation
NAT64
DNS64
ISATAP
464XLAT /2013? всего на 18 лет опоздал, ну ничего/
Dual-Stack Lite (DS-Lite)
V4-via-v6 routing
MAP
4rd
NAT-PT
NAPT-PT
Это у нас архитектура, понимать надо.
Может, фильм снимем, где IETF в ушанках с балалайками и водкой заседает?
Ну, а IPv6 сейчас вполне себе жив.
Я повторюсь, он должен быть не жив, а внедрён 15 лет назад. Так в RFC написано, в предновогоднем. Там в 2010 году видят возможность для внедрения следующего протокола. Не консервативную, но и не раннюю, а в самый раз. Как раз к 1995 прошло ~15 лет после утверждения IPv4, а это ещё 15 лет.
Инженерам, которые разрабатывали IPv6, это не удалось, поэтому они решили, что раз уж ломают совместимость, поэтому сразу будут менять то, что плохо работало.
Обсуждение IPv6 всегда в эту демагогию уходит. IPv6 должен был к нулевым успешно конкурировать с провайдерским NAT. Он не смог. Значит, он неудачен, инженеры ошиблись, остальное не принципиально. Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы.
Период между принятием и предполагаемым завершением внедрения (50 лет, 1995-2045) у IPv6 как у ITER, но там чистая наука и даже внезапное закрытие проекта почти никого не затронет.
Да, совместимость не сохранить целиком, но каждое лишнее расхождение имеет цену в годах. Одно решение - плюс пять лет, другое решение - ещё плюс пять лет, так отведённые на внедрение ~15 лет и кончатся (начало 90-х - конец нулевых).
two type A records can be used to store the level 1 and level 2 parts of the 4+4 address. For example, the level 1 and 2 parts of the IPv4+4 address of the machine foo.bar.edu are stored under _l1.foo.bar.edu and _l2.foo.bar.edu. Auxiliary protocols, such as DHCP, ARP, RARP, router discovery, etc., need not be modified. IPv4+4 packets are minimally encapsulated IP packets The first three rows of fields in the IPv4+4 header are interpreted in the same manner as the IPv4 header, with the exception that the Protocol 1 field is set to a value that specifies IPv4+4 encapsulation. Upgraded NATs, called realm gateways, are integral part of the 4+4 architecture. If routers are also upgraded in an area, the special role of the realm gateways diminishes and they simply reduce to ordinary routers. There is no need for temporary transition mechanisms (such as tunneling, tunnel brokers, 6to4, 6over4 or DSTM
Поздно? Но она не на пустом месте появилась, она опиралась на предыдущие наработки. Предыдущие наработки отвергли? Ну, это была работа IETF - выбрать верное направление. Была слишком неясная ситуация? Объявить вотум недоверия всем предложениям - это тоже решение, можно потерять 5 лет, а потом сэкономить 30. Учесть неясность и уменьшить горизонт планирования - тоже решение (не пытаться предсказать будущие потребности сверх расширения адресов).
И если мы ее ломаем, то почему сразу не сделать лучше чем есть сейчас?
Потому что вопрос подразумевает академический успех и закрывает глаза на скорость внедрения.
Протокол пытались улучшить в академическом смысле, а на практике то был план, в котором бизнес оплатит издержки за неимением выбора. При создании IPv6 не допускали, что ему придётся конкурировать с NAT-на-IPv4. Поэтому казалось, что нет разницы, насколько ломать совместимость: в любом случае ломаем => надо пользоваться моментом => а добавим ещё вот это...
Любой другой протокол будет несовместим с IPv4, его просто нельзя нормально расширить. Считаете, когда проектировали IPv6, об этом не задумывались?
Конечно нет, тогда было слишком унизительно думать о расширении IPv4 "хоть тушкой, хоть чучелом". А теперь слишком унизительно вспоминать об этой возможности.
Почитайте, как процесс происходил.
В конце 1994 опубликовали RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng). В нём начали с того, что
If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it.
А продолжили тем, что нужны фичи. Нужно много фич. И нам тут из минобороны позвонили... у них вертолёты на кораблях. Да, тоже нужно - не обсуждается.
Naval surface combatants carry some aircraft (at a minimum, a helicopter or two) (the ships that move around) the ships carrying the aircraft each aircraft has its own network must be mobile internetworks There is also the requirement for dynamic mobility; a plane might take off from aircraft carrier A and land on carrier B These requirements are not limited to just the navy
Через месяц подвели итоги в RFC1752 - отбор прошли 3 протокола и, как ни странно, они все сложные.
На роль IPv6 выбрали SIPP
The biggest problem the reviewers had with SIPP was with IPAE, SIPP's transition plan. The overwhelming feeling was that IPAE [IP Address Encapsulation] is fatally flawed and could not be made to work reliably in an operational Internet.
____
Надо было начать с расширения IPv4 вправо. Это, конечно, приятно, когда органу есть что распределять, но проще автоматически сделать владельца одного IPv4 владельцем 2^(8/16/32) IPng-адресов. Владельцем обычно будет провайдер, использующий IPv4-адрес под CGNAT.
2^8, если переиспользовать поле Identification при форсировании Don't Fragment - недостаточно из-за неравномерного распределения адресов (мало IPv4 у стран Азии). Ещё 6 бит, если получится задействовать Fragment Offset.
2^16+, если заставить железо поддерживать IPv4 Options либо навсегда инкапсулировать новый заголовок (с расширенной частью адреса) в IPv4.
В этом направлении думали в EIP (1992), IPv4+4 (2002), xIP (2009), EnIP, IP45.
недавно биологи из СПбГУ открыли что художники рисуют не реальных животных, а их стилизацию под реальных
В науке всегда такое можно отыскать. Скажем, зонная теория слуха Гарбузова из 1940-х опиралась на предположение о бесконечной точности слуха. Потому что без этого чучела не хватит новизны и не получится преподносить известное как новую теорию.
не стал бы покупать овердорогой серверный Итаниум, чтобы получить производительность второго пня образца 1998
Да кто их знает, они же всё-таки купили Itanium, который изначально не впечатлял. Хотел добавить, что итаник сразу понимал SSE2, но... это ухудшало производительность, а не улучшало (обзор из начала 2001).
ixbt в 2005 тестировал Itanium2 1.3GHz/3MB. Говорит, что до третьего пня падало.
* "на уровне 2,8 ГГц процессора" ** "соответствует Pentium III 700/450 МГц" *** "примерно уровень Pentium 4 1,7 ГГц"
____ Вообще, не факт, что между аппаратным слоем совместимости и программным "IA-32 EL" из ~2004 было что-то ещё. HP'шный "overview" из 2002 мог врать.
ты точно знаешь, что, как и где можно соптимизировать знаешь, что процессор на это закономерно откликнется и покажет рост производительности
Гхм, с конца 1990-х к процессорам сбоку прикручивают SIMD-расширения, чтобы предсказуемо дробить числа - и где разница?
А там где высокоуровневая бизнес-логика с её нехорошей индирекцией, ветвлениями и промахами кэша - там на одном железе всё равно будет медленно, а в другом - всё равно быстро.
Не, аппаратной совместимостью Intel хвалится в даташите и на 1 поколение (которое "800 MHz and 733 MHz"). Эмуляция в винде там тоже должна быть, потому что про неё Microsoft в августе 2001 пишет(за год до второго итаника).
Скорее уж в Itanium 2 ничего не меняли в этом аспекте.
Из "overview of the new Itanium 2-based hp servers rx2600..."
_____
Не порядок, что бенчмарков последних итаников так и не появилось. Itanium 9500/9700.
Причём первые 2 макроса обычно не нужно было писать самому - достаточно было подключить стандартный хидер из avr-libc, написав #include <avr/io.h>
Их туда добавили, когда компилятор не распознавал идиому над "IO-доступными" адресами, и потом задепрекейтили в 2005 со словами
Cообщество AVR-GCC теперь единственное известное мне сообщество C-программистов, работающих непосредственно с железом, которое до сих пор не поняло, как работают побитовые операции в C. В списках рассылки FreeBSD я никогда не видел запросов на макрос, который заменял бы |= и &=~. [и дальше про то, что если писать макрос для себя, то сразу LED_ON и LED_OFF]
Ещё напрашивается атрибут always_inline, потому что без гарантии инлайнинга смысл меняется - через типы нельзя передать информацию, что адрес доступен в IO-пространстве и надо атомарно менять бит за одну инструкцию.
после критических ошибок стараться отдавать в read-only частично битые данные, а не притворяться кирпичом
расширить самодиагностику: прогноз по сохранности данных, доступ к "качеству поверхности" по аналогии с оптическими дисками (график ошибок ECC от адреса - LBA или физического)
кнопку "подготовить к хранению", перезаписывающую блоки, которые ниже какого-то порога (и обновляющую прогноз из предыдущего пункта)
Только зачем нужны эти фичи? Чтобы больше экономить на бэкапах. - Сделайте, чтобы я вам меньше платил... - Ваше мнение очень важно для нас!
Причём это требования к изношенному SSD (100% TBW), иногда забывают.
Заодно буду знать, на что можно рассчитывать с тем или иным диском, когда понадобятся через месяцы-годы.
Наверное, это можно узнать за день, но так не интересно. Большой кусок того стандарта - как ускорять тестирование нагревом и как хорошо ускоренный тест отражает результаты без нагрева.
но какое же тогда слово, начинающиеся на S означает "два" в SLC?
Secundus. Перепутали порядковые и количественные... /s
Судя по гуглу, иногда для ясности говорят "8-level TLC", "4-level MLC". Четырёхуровневая (да) многоуровневая (точнее, двухуровневая (то есть нет, на самом деле двухбитовая)) ячейка - всё довольно просто.
Впрочем, какой софт станет так показывать? Windows и в те времена в основном показывала гигабайты (двоичные) и глубже - байты без приставок. Двоичные килобайты (делённые пополам) будут только на этикетке диска в виде числа секторов.
Интервью с Серфом: адрес зафиксировали в 1973, 128 стран, 24 бита на сеть, 16 миллионов компьютеров на сеть - для эксперимента точно достаточно.
Документы: фиксация адреса откладывается до 1979±1 - уже не эксперимент, а крупный оборонный проект и мотив решения - скорость (не MVP для доработки). 1979 - это уже 100К продаж TRS-80 и статья о том, как военные уплотняют мультимедиа для сетей (7 аудиокодеков).
Где-то здесь ошибка.
100К продаж с "starting price of US$600" - перспективы можно углядеть (IBM сразу углядела, до IBM PC два года).
А если на два года в прошлое (1977), то там Xerox в своём протоколе расширяет адрес до 32+48 бит (MAC-адрес). Xerox тоже что-то знал.
Это инфраструктура (вроде водопровода), тут всё-таки не важно, насколько приятно выкидывать легаси и переписывать с нуля.
В IPv4+4 - тоже. Если бы продавливали решение через Options, то пакет с extra-addr-option тоже был бы фиксированной длины. Если бы совсем отбросили амбиции и попытались набирать ~14 бит через запрет фрагментации, то одинаковой длины с IPv4.
Так речь о том, чтобы автоматически наделить владельца белого IPv4 адресами нового протокола (~2^(14..32) штук).
В перечисленных мной вариантах это должен быть обычный NAT. И как можно было принять 464XLAT через ~15 лет после IPv6? ("Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы")
То есть совсем другое.
IPv6 - сам по себе костыль, только в особом смысле - костыль из башни слоновой кости с синдромом второй системы. Он должен был дать адреса и смотреться выгоднее CGNAT'а в нулевых. Сверх этого можно давать фичи, но давать их вместо - нельзя.
Ещё из RFC1726: "4.1 Архитектурная простота. Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать". Отлично подходит к IPv6.
Они промахивались насчёт IPsec, насчёт лёгкости миграции с IPv4, насчёт связности, возведённой в абсолют, потому что из начала 90-х было трудно предсказать ситуацию через 10-20 лет - и не надо было этого делать. Надо было в соответствии с цитатой отсекать всё, что помешает полному переходу через 15 лет.
Ага, а параллельно существует совсем другая история для взрослых, в которой за 1-2 года:
зафиксировали длину IPv4-адреса ради скорости
за кучу денег пересадили на протокол всю военку, это будет MIL-STD-1777
в журнале
"Вестник компьютеризации"Computerworld пишут о годноте для бизнеса, за ваши налоги, без вендор-лока IBM, скоро в широком доступеСобственно, история
Середина 1978: в IPv4 ещё адрес переменной длины, на месте контрольной суммы стоят длины адресов.
Конец 1979: "Vint ... cited the performance of the system as a key issue" - пора фиксировать длину адреса.
"Rosenthal recalls: ... Vint Cerf and company went off to invent TCP at the time because they got lots of DOD money to make networks work"
"Throughout 1979, Kahn and Cerf lobbied the DOD to make TCP/IP an official communication protocol standard"
"in December 1980, the DOD publicly unveiled TCP/IP"
Computerworld 1981: "May 15 ... plans to market TCP/IP as part of its VAX/VMS network software package for DEC" и пересказ остального: "на ваши налоги сделали протокол (военный стандарт) - как у IBM, только лучше и без вендор-лока, его уже тестируют на процессорах IBM, DEC, Honeywell, CDC, HP и PerkinElmer. В следующем году он будет широко доступен коммерческим пользователям".
а в протокол была заложена расширяемость (ну вдруг кто-то зачешется), спецификация требует: "each internet module must be able to parse every option [options = блок переменной длины в конце заголовка]"
Ещё одна былина.
"Самолёт может взлететь с авиносца А и сесть на авианосец Бэ" - Технические критерии по выбору IP нового поколения, 1994.
Он создавался как IPv4 - для всех, и для особого клиента в том числе - для родной военки.
Присмотритесь:
Перед новогодними праздниками (декабрь 1994, RFC1726): нужен протокол с безупречным планом миграции.
После новогодних праздников (январь 1995, RFC1752): подписываем протокол без плана миграции, единственный из трёх.
Что последовало за этим дальновидным решением?
Wikipedia / List of IPv6 transition mechanisms
Stateless IP/ICMP Translation
Tunnel broker
6rd
Transport Relay Translation
NAT64
DNS64
ISATAP
464XLAT /2013? всего на 18 лет опоздал, ну ничего/
Dual-Stack Lite (DS-Lite)
V4-via-v6 routing
MAP
4rd
NAT-PT
NAPT-PT
Это у нас архитектура, понимать надо.
Может, фильм снимем, где IETF в ушанках с балалайками и водкой заседает?
Я повторюсь, он должен быть не жив, а внедрён 15 лет назад. Так в RFC написано, в предновогоднем. Там в 2010 году видят возможность для внедрения следующего протокола. Не консервативную, но и не раннюю, а в самый раз. Как раз к 1995 прошло ~15 лет после утверждения IPv4, а это ещё 15 лет.
Обсуждение IPv6 всегда в эту демагогию уходит. IPv6 должен был к нулевым успешно конкурировать с провайдерским NAT. Он не смог. Значит, он неудачен, инженеры ошиблись, остальное не принципиально. Сворачивать с пути поздно, но это не мешает признавать неудачу и делать выводы.
Период между принятием и предполагаемым завершением внедрения (50 лет, 1995-2045) у IPv6 как у ITER, но там чистая наука и даже внезапное закрытие проекта почти никого не затронет.
Да, совместимость не сохранить целиком, но каждое лишнее расхождение имеет цену в годах. Одно решение - плюс пять лет, другое решение - ещё плюс пять лет, так отведённые на внедрение ~15 лет и кончатся (начало 90-х - конец нулевых).
Есть такая штука из 2002: IPv4+4:
Поздно? Но она не на пустом месте появилась, она опиралась на предыдущие наработки.
Предыдущие наработки отвергли? Ну, это была работа IETF - выбрать верное направление.
Была слишком неясная ситуация? Объявить вотум недоверия всем предложениям - это тоже решение, можно потерять 5 лет, а потом сэкономить 30. Учесть неясность и уменьшить горизонт планирования - тоже решение (не пытаться предсказать будущие потребности сверх расширения адресов).
Не тот слайд, там цены на оперативку!
По-моему, вокруг нас хватает замедляющихся экспонент. В основном в железе, но ещё в ~2000 с лёгкой руки бросили, что
А после проверки получилось, скорее, так:
Потому что вопрос подразумевает академический успех и закрывает глаза на скорость внедрения.
Протокол пытались улучшить в академическом смысле, а на практике то был план, в котором бизнес оплатит издержки за неимением выбора. При создании IPv6 не допускали, что ему придётся конкурировать с NAT-на-IPv4. Поэтому казалось, что нет разницы, насколько ломать совместимость: в любом случае ломаем => надо пользоваться моментом => а добавим ещё вот это...
Более длинный коммент рядом.
Конечно нет, тогда было слишком унизительно думать о расширении IPv4 "хоть тушкой, хоть чучелом". А теперь слишком унизительно вспоминать об этой возможности.
Почитайте, как процесс происходил.
В конце 1994 опубликовали RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng). В нём начали с того, что
А продолжили тем, что нужны фичи. Нужно много фич. И нам тут из минобороны позвонили... у них вертолёты на кораблях. Да, тоже нужно - не обсуждается.
Через месяц подвели итоги в RFC1752 - отбор прошли 3 протокола и, как ни странно, они все сложные.
____
Надо было начать с расширения IPv4 вправо. Это, конечно, приятно, когда органу есть что распределять, но проще автоматически сделать владельца одного IPv4 владельцем 2^(8/16/32) IPng-адресов. Владельцем обычно будет провайдер, использующий IPv4-адрес под CGNAT.
2^8, если переиспользовать поле Identification при форсировании Don't Fragment - недостаточно из-за неравномерного распределения адресов (мало IPv4 у стран Азии). Ещё 6 бит, если получится задействовать Fragment Offset.
2^16+, если заставить железо поддерживать IPv4 Options либо навсегда инкапсулировать новый заголовок (с расширенной частью адреса) в IPv4.
В этом направлении думали в EIP (1992), IPv4+4 (2002), xIP (2009), EnIP, IP45.
Почему не так?
2030 - 1972 [создание Си] = 58 лет.
2012 [создание Rust] + 58 = 2070 год - время перехода на убийцу раста.
Ещё добавить коэффициент, учитывающий замедление относительно разных муроподобных законов, и "ещё чего - нейронку на новый язык тренировать".
В науке всегда такое можно отыскать. Скажем, зонная теория слуха Гарбузова из 1940-х опиралась на предположение о бесконечной точности слуха. Потому что без этого чучела не хватит новизны и не получится преподносить известное как новую теорию.
Дольше СССР, однако.
Да кто их знает, они же всё-таки купили Itanium, который изначально не впечатлял. Хотел добавить, что итаник сразу понимал SSE2, но... это ухудшало производительность, а не улучшало (обзор из начала 2001).
ixbt в 2005 тестировал Itanium2 1.3GHz/3MB. Говорит, что до третьего пня падало.
SPEC CPU2000
SPECint/fp_base2000: 1017*/1979 (IA-64)
SPECint/fp_base2000: 306/170 (-70%/-91%) (HW IA-32)**
SPECint/fp_base2000: 569/530 (-44%/-73%) (SW IA-32)***
* "на уровне 2,8 ГГц процессора"
** "соответствует Pentium III 700/450 МГц"
*** "примерно уровень Pentium 4 1,7 ГГц"
____
Вообще, не факт, что между аппаратным слоем совместимости и программным "IA-32 EL" из ~2004 было что-то ещё. HP'шный "overview" из 2002 мог врать.
Гхм, с конца 1990-х к процессорам сбоку прикручивают SIMD-расширения, чтобы предсказуемо дробить числа - и где разница?
А там где высокоуровневая бизнес-логика с её нехорошей индирекцией, ветвлениями и промахами кэша - там на одном железе всё равно будет медленно, а в другом - всё равно быстро.
Не, аппаратной совместимостью Intel хвалится в даташите и на 1 поколение (которое "800 MHz and 733 MHz"). Эмуляция в винде там тоже должна быть, потому что про неё Microsoft в августе 2001 пишет (за год до второго итаника).
Скорее уж в Itanium 2 ничего не меняли в этом аспекте.
_____
Не порядок, что бенчмарков последних итаников так и не появилось. Itanium 9500/9700.
"A key feature of the Itanium architecture is IA-32 instruction set compatibility" - Intel Itanium Architecture Software Developer’s Manual.
Их туда добавили, когда компилятор не распознавал идиому над "IO-доступными" адресами, и потом задепрекейтили в 2005 со словами
Ещё напрашивается атрибут
always_inline, потому что без гарантии инлайнинга смысл меняется - через типы нельзя передать информацию, что адрес доступен в IO-пространстве и надо атомарно менять бит за одну инструкцию.Можно ещё такие фичи представить:
после критических ошибок стараться отдавать в read-only частично битые данные, а не притворяться кирпичом
расширить самодиагностику: прогноз по сохранности данных, доступ к "качеству поверхности" по аналогии с оптическими дисками (график ошибок ECC от адреса - LBA или физического)
кнопку "подготовить к хранению", перезаписывающую блоки, которые ниже какого-то порога (и обновляющую прогноз из предыдущего пункта)
Только зачем нужны эти фичи? Чтобы больше экономить на бэкапах.
- Сделайте, чтобы я вам меньше платил...
- Ваше мнение очень важно для нас!
новость появилась на HN
взлетела
значит и тут взлетит
???
profit
840 и 840 EVO. Причину* проблем не раскрывали, юзеры жаловались в основном на замедление. Решение критиковали за грубость - вроде перезаписывалось всё, без адаптивности. https://web.archive.org/web/20250413200733/http://www.anandtech.com/show/9196/samsung-releases-second-840-evo-fix
* вот что-то: "LDPC ECC ... В 840 EVO же применялась обычная коррекция ошибок BCC, а она для работы с TLC-памятью подходит не лучшим образом" - https://3dnews.ru/931062/obzor-ssdnakopitelya-samsung-750-evo-masterklass-po-tlc
Причём это требования к изношенному SSD (100% TBW), иногда забывают.
Наверное, это можно узнать за день,
но так не интересно. Большой кусок того стандарта - как ускорять тестирование нагревом и как хорошо ускоренный тест отражает результаты без нагрева.Secundus. Перепутали порядковые и количественные... /s
Судя по гуглу, иногда для ясности говорят "8-level TLC", "4-level MLC". Четырёхуровневая (да) многоуровневая (точнее, двухуровневая (то есть нет, на самом деле двухбитовая)) ячейка - всё довольно просто.
А, могу. Ёмкость покажется "честной", если на неё смотреть с малыми двоичными приставками (КиБ вместо ГиБ), где разница с десятичными меньше.
Допустим, на этикетке заявлено 40 каких-то ГБ, а реальная ёмкость:
40.96 ГБ
= 38.1 ГиБ [караул]
= 39 063 МиБ [уже лучше]
= 40 000 000 КиБ. [совсем хорошо].
Заявленные гигабайты десятичные, но не вызовут претензий, если на них смотреть через кибибайты (вместо гибибайтов).
____
Maxtor DiamondMax Plus 8.
На этикетке заявлено 40 [каких-то] ГБ и 80 293 248 секторов.
80 293 248 * 512 байт
~= 40+1.1 ГБ
~= 40-1.7 ГиБ.
Зявленные гигабайты десятичные.
А теперь:
80 293 248 * 512 байт
= 38.3 ГиБ
= 39 206 МиБ
= 40 146 624 КиБ.
@Willy64@Armitage1986
____
Впрочем, какой софт станет так показывать? Windows и в те времена в основном показывала гигабайты (двоичные) и глубже - байты без приставок. Двоичные килобайты (делённые пополам) будут только на этикетке диска в виде числа секторов.