TECHNO BROTHER

Интересное это занятие — изучать историю техники, отыскивая моменты, где развитие идет по спирали. В какой-то момент времени появляются необычные технические решения, расширяется разнообразие подходов, а потом в один момент схлопывается после нахождения оптимального пути. Но спустя какое-то время, отброшенный на задворки развития подход вновь опробуется, но в этот раз развивается и становится общепринятым. Давайте в очередной раз окунемся в глубины прошлого и посмотрим, откуда растут ноги у аппаратного ускорения операций ввода-вывода, знакомого нам сегодня по высокопроизводительным сетевым картами и RAID контроллерам. Приятного чтения!

Итак, на дворе 1996 год. Появившийся совсем недавно процессор Intel Pentium Pro впервые довел IBM PC совместимые компьютеры до уровня производительности, позволяющего конкурировать с RISC системами. Но конкурировать — не значит сравниться и, тем более, не значит — быть действительно быстрым. Большинство компьютеров того времени страдали от высоких нагрузок при выполнении операций ввода-вывода: в первую очередь работу с дисками и сетью. Производительность последних также росла и требовала еще больших затрат ресурсов системы для реализации их возможностей.

Еще недавно 10 мбит сети Ethernet справлялись с большинством клиентских задач, и только серверы использовали агрегированные подключения (например, 4-портовые адаптеры Cogent). Но приход 100VG-AnyLAN и Fast Ethernet с десятикратным ростом пропускной способности и появившиеся тут же многопортовые серверные адаптеры потребовали соответствующих затрат времени CPU на работу с ними: в то время сетевые контроллеры ещё не умели забирать на себя часть нагрузки, связанной с обработкой сетевых протоколов (например, TCP Offloading). О важности разгрузки процессора при работе с сетью говорит тот факт, что даже в начале 2000-х годов много более мощные машины с процессорами Intel Pentium III заметно просаживались при активной сетевой работе, если они были укомплектованы простыми карточками с чипом Realtek RTL8139, которые не умели в Offloading, но совершенно не замечали нагрузки, если установить “умную” карту от Intel или 3Com.

Процессоры Intel Pentium Pro

Не менее серьезно обстоит ситуация и с дисковыми операциями: скорости SCSI уже достигают 40 Мбайт/с на канал, на носу обновление стандарта для поддержки вдвое больших скоростей. Набирают популярность и дисковые массивы.

С другой стороны, нарастает проблема создания драйверов под растущий зоопарк операционных систем (Windows NT, OS/2, UnixWare итд) и… (барабанная дробь)… архитектур процессоров! Середина 90х — время больших надежд на скорую смерть х86 и приход RISCового будущего (спойлер — оно не пришло, и только сейчас пока еще робко, но все увереннее, снова стучится в дверь). Windows NT выпускается для четырех (!) процессорных архитектур, поддерживаемые ею RISC-машины относительно стандартизованы и уверенно развиваются.

В такой обстановке, недавно образованная Intelligent I/O Special Interest Group (I2O SIG) публикует стандарт I2O — интеллектуального ввода-вывода. Стандарт предполагает выполнение всех операций I/O с использованием поддерживаемых устройств — сетевых карт и контроллеров SCSI — на выделенном процессоре (IOP), в качестве оного подразумевался интеловский не сбывшийся (в очередной раз) RISC общего назначения i960 в специально доработанной версии (суффиксы RD/RP/RM/RN). Процессор выпускался с частотой от 33 до 66 МГц (позднее ее подняли до 100 МГц), снабжался собственной памятью, и работал под управлением операционной системы IxWorks от компании Wind River Systems, автора известной RTOS VxWorks. На материнских платах, как правило, устанавливали два выделенных слота SIMM с поддержкой до 64 Мбайт (позднее — 256 Мбайт) оперативной памяти — этого было более чем достаточно для ОС, всех возможных программных модулей и кэширования. Существовала возможность отключения интеллектуальных функций процессора и использование его в качестве обычного PCI моста.

Модель драйверов I2O. Источник — www.ixbt.com/mainboard/i2o.html

Фактически, взаимодействие с реальным железом ложилось на плечи этой ОС, для нее создатели устройств и должны были создавать собственные драйвера (в терминах I2O — HDM, Hardware Device Module). В свою очередь IxWorks предоставляла интерфейс для взаимодействия с драйверами основной операционной системы, в данной концепции именуемыми OSM — Operating System Module. При этом появлялась унификация драйверов для всех устройств одного типа. В случае повсеместного внедрения I2O производители железа должны были разработать драйвера только для IxWorks, а WindRiver совместно с производителями ОС разрабатывала бы драйвера OSM для поддерживаемых операционных систем.

Чуть позже появилась третья абстракция — модуль обслуживания интерфейса, Interface Service Modules (ISM). ISM — выполняемая под управлением VxWorks программа, позволяющая разгрузить центральный процессор от выполнения тех или иных задач, связанных с операциями ввода-вывода. Например, столь востребованная по сей день аппаратная обработка стека протоколов IP (TCP Offloading). Помимо разгрузки ЦП от сопутствующих вводу-выводу вычислений, ISM способна обеспечивать взаимодействие нескольких процессоров ввода-вывода в одной системе.

Итак — задумка чудесная. Но раз вы узнаете о технологии из ретроспективной статьи, значит что-то пошло не так! А не так пошло почти все, что только можно. Во-первых, не было представлено особо заметного ассортимента оборудования с поддержкой I2O. Внезапно, первой выпустила материнскую плату и сервер на ее основе Supermicro. Ее модели P6DNH и P6DNH2 на основе чипсета Intel 440FX поддерживали процессоры Pentium Pro (socket 8) и соответствовали форм-фактору Full AT с дополнительными слотами PCI, обслуживаемыми IOP, расположенными в верхней части платы. Платы располагали 10 слотами памяти SIMM, 8 из которых обслуживал контроллер памяти чипсета и 2 принадлежали IOP.

SuperMicro SuperServer P6DNH. Источник — www.itweek.ru/infrastructure/article/detail.php?ID=42074

На основе этих плат выпускались серверные платформы SuperServer, рассчитанные в первую очередь на поставку ОЕМ сборщикам и крупным системным интеграторам. В дальнейшем были выпущены еще две платы, уже для процессоров Intel Pentium II в конструктиве Slot1. Одна, модель 1997 года — на чипсете Intel 440LX, с поддержкой шины 66 МГц, другая, появившаяся уже в 1998 году, использовала чипсет Intel 440GX и, помимо поддержки 100 МГц и до 2 Гбайт ОЗУ, получила слот шины AGP (ее поддерживал и Intel 440LX, но на ранней модели платы поддержка не была реализована), что позволяло использовать ее не только в серверах, но в и мощных графических станциях. Эти платы использовали по 4 слота DIMM для системной ОЗУ и по 2 слота SIMM для памяти IOP.

SuperMicro P6DGH. Источник — theretroweb.com/motherboards/s/supermicro-p6dgh

Слоты памяти при этом были размещены рядом друг с другом. Когда я впервые увидел фото P6DGH, я был удивлен — зачем кому-то пришла в голову реализовывать поддержку SIMM EDO (чипсеты серии Intel 440 поддерживали как SDRAM, так и EDO) на топовой серверной плате, пока не увидел прикрытый радиатором процессора чип i960. Забавно, что встроенный контроллер SCSI Adaptec подключен напрямую к шине PCI, а не через IOP и для реализации RAID функций требует установки отдельной карты с процессором в выделенный слот.

При этом решений для 4-процессорных систем или систем на базе процессоров Intel Xeon в конструктиве Slot2 с поддержкой I2O компанией выпущено не было.

Как ни странно, вообще не отметилась в этом ряду сама Intel. Помимо SuperMicro, лишь Asus выпустила материнскую плату с I2O как отдельный продукт — модель Asus P2B-D2. Эта плата формата E-ATX поддерживала пару процессоров Intel Pentium II (Slot1) с частотой системной шины до 100 МГц и использовала чипсет Intel 440BX. В отличие от решений SuperMicro, здесь присутствует встроенная видеокарта и сетевой адаптер на основе чипа Интел. И снова встроенные устройства — и сеть, и SCSI — не подключены к IOP. Сам IOP может в свою очередь переключаться в режим PCI моста, в таком режиме установленные в управляемые им слоты PCI будут работать как обычные устройства.

Asus P2B-D2. Источник — руководство пользователя платы.

Изначально считалось, что недорогой (10-15 долларов США) процессор ввода-вывода будет интегрироваться на материнские платы или даже непосредственно на устройства для установки в PCI слот. Если в случае с первым подходом практика показала, что интеграция стоит куда дороже: процессор потребовал довольно сложной разводки, подключения к основной PCI шине и управляемым слотам PCI, и выделенных слотов памяти — то второй подход завоевал куда большую популярность и следы ее прослеживаются до сих пор.

Начнем с сетевых карт — их было выпущено… целая одна модель! Intel PRO/100 Intelligent Server Adapter, также известная как PILA8480 (две ревизии — 1997 и 1998 года).

Intel PRO/100 Intelligent Server Adapter

Как вы можете видеть, здесь присутствует IOP i960, но для память выполнена в виде двух чипов общей емкостью 1 Мбайт, расположенных на сетевой карте и расширение ее не предусмотрено. Впрочем, здесь оно уже и не требуется — HDM здесь будет выполняться только один и в отличие от обслуживания дисковых накопителей, задачи здесь не так требовательны к памяти.

Мне удалось приобрести две New Old Stock карты этой модели выпущенных в начале 1998 и конце 1999 годов. Сейчас эти карты заняли свое место в двух любимых сборках — "Dreamstation" и "Millennium Dream". В Windows 2000 уже есть драйверы для карты, для NT 4.0 пришлось потратить изрядно времени на поиск.

Контроллер RAID серии Mylex DAC960

Другое дело RAID контроллеры: на процессорах i960 их было выпущено огромное множество от разных производителей. Часть из них использовали собственные прошивки, иногда даже предоставлявшие интерфейс для операционной системы, совместимый с I2O OSM. Но несколько компаний пошли дальше — в первую очередь это была Intel, выпустившая набор для разработки RAID контроллеров под управлением IxWorks (Intel SMU22R), а также последователи — Symbios Logic (позднее LSI), AMI и DPT (позднее была приобретена Adaptec), а также использовавшие их наработки под собственным именем производители серверов, включая, например, Hewlett-Packard. Такие контроллеры часто имели на борту разъемы для установки и расширения памяти, обладали серьезной производительностью и поддерживали множество вариантов уровней RAID-массивов. Будучи включенными в режиме I2O (как правило, он выключен по умолчанию), могли использовать для работы стандартные I2O совместимые драйвера (OSM).

Одним же из выдающихся примеров реализации I2O стал контроллер HP NetRAID Integrated Controller, который поставлялся в составе серверов HP NetServer LH3 (Dual Slot1) и LH6000 (Quad Slot2). К счастью, младшая модель уже давно нашла свое место в коллекции Digital Vintage — получится более подробно познакомиться с ней.

Сервер HP NetServer LH3 — в процессе реставрации, виден неоригинальный DVD-привод

LH3 и LH6000 делят между собой общее шасси и младшая модель сравнительно легко может быть обновлена до старшей — требуется заменить основную системную плату, установить дополнительное охлаждение и приклеить новый шильдик из комплекта поставки. Само шасси — огромная по нынешним меркам “тумбочка” двойной ширины с прочными колесиками. Проверено — выдерживают более 100 кг дополнительной нагрузки — пару серверов Sun и HP сходного размера.

Форм-фактор — реализация стандарта NLX в версии для мощных серверов. В настольном варианте в объединительную плату устанавливалась лишь материнка, основные слоты расширения располагались на самой объединительной плате. Здесь же она играет лишь роль распределителя питания — к ней подключаются блоки питания и система охлаждения. В два слота на ней устанавливаются материнская плата и плата ввода-вывода. Отсек блоков питания расположен сзади, в нижней части шасси. Базовой конфигурации установлен лишь один блок питания, всего же их можно установить два.

Сервер HP NetServer LH3 — материнская плата и процессоры

Материнская плата выполнена на основе популярнейшего чипсета Intel 440BX, занявшего место практически во всех сегментах рынка — от ноутбуков и настольных компьютеров среднего уровня до мощных рабочих станций и серверов. На ней расположено два разъема Slot1 для установки процессоров Intel Pentium II и Intel Pentium III с частотой шины 66 или 100 МГц. Наш экземпляр укомплектован парой Intel Pentium III 500 МГц на ядре Katmai. Процессоры оснащены пассивными системами охлаждения — как и в современных серверах поток воздуха создается вентиляторами, установленными в шасси. Также присутствует 4 слота памяти DIMM, несмотря на то что чипсет поддерживает как регистровые, так и обычные модули памяти, в данном сервере необходимо использование исключительно регистровых модулей Registered ECC SDRAM. Установлено 4 оригинальных модуля общим объемом 512 Мбайт. На задней панели платы расположены стандартные порты.

Сервер HP NetServer LH3 — плата ввода-вывода

Сама же плата при снятых крышках шасси легко извлекается из слота и достается из сервера. Бок о бок с ней находится плата ввода-вывода, несущая разъемы расширения PCI64, PCI и ISA. На этой плате расположен мост для реализации дополнительной шины PCI64. Помимо него расположен процессор ввода-вывода i960, к которому подключены два контроллера SCSI Symbios и слот памяти, несущий 16 Мбайт модуль памяти типа SIMM. Также к нему подключен выделенный RTC Dallas с памятью для хранения настроек IxWorks и настроек работы с дисковыми массивами. Набор этих элементов формирует интегрированный контроллер HP NetRAID. Казалось бы, тут уже несложно было бы подключить к IOP хотя бы пару слотов PCI для работы с сетевыми адаптерами в режиме I2O, но нет, к сожалению, этого сделано не было, хотя все возможности для этого есть.

На переднем краю платы расположена пара SCSI разъемов для подключения расположенных во фронтальной части шасси двух дисковых корзин (в нашем экземпляре установлена одна) Hot Swap. Есть возможность подключения стримера. А вот привод оптических дисков уже обычный IDE, причем прогрессивный на то время DVD-ROM, заводская опция.

Сервер HP NetServer LH3 — кнопки управления и диагностический экран

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

Сервер попал в коллекцию два года назад благодаря коллеге Артему Кашканову radiolok. Год спустя он прошел реставрацию и был доукомплектован. Лишь сейчас пришла очередь рассказа о нем — мне хотелось сделать не просто обзор сервера, но и более подробно рассказать о его особенностях, главной из которых оказалась поддержка технологии I2O. Постепенно именно сама технология стала главной темой статьи, но сервер стал единственным пока примером ее реализации, который можно было бы показать общественности. Других устройств с поддержкой I2O в коллекции Digital Vintage пока нет.

К сожалению, как часто бывает с вещами, опередившими свое время, век I2O был недолог. Немногие выпускавшиеся платы с полноценной реализацией технологии сейчас являются коллекционной редкостью класса “анобтаниум”, а немногие серверы с интегрированными дисковыми I2O контроллерами сошли с арены к концу 2002 года вместе с платформой Slot2. Куда более долог оказался век у RAID контроллеров — IxWorks переехала на архитектуру ARM и продолжила применяться в более новых SCSI и SAS устройствах. Со временем производители отказались от поддержки унифицированных интерфейсов OSM, но логика работы по сей день остается прежней — RAID контроллер полностью берет на себя выполнение операций ввода-вывода и отдает ОС уже сформированные блочные устройства. И только с приходом NVMe накопителей процессор ввода-вывода начал становится узким местом в серверных системах.

А вот в производительных сетевых картах во всю применяется разгрузка CPU от выполнения ключевых задач работы с стеком TCP/IP (тот самый TCP Offloading) и, иногда, протоколом iSCSI.

Сыграла свою роль из закрытость “клуба” I2O — благодаря усилиям Microsoft и SCO, доступ разработчиков открытых систем к спецификациям технологии был открыт уже под закат ее развития и драйверы для Linux и BSD появились с большой задержкой, а ведь эти системы тогда как раз очень сильно набирали популярность в серверном сегменте. Когда же поддержка появилась — актуальность ее была уже мала, но тем не менее, технология поддерживалась вплоть до 6 релиза RHEL, примерно в то же время, произошел отказ от поддержки и в других дистрибутивах открытых ОС.

Так замкнулся очередной виток истории ИТ. До новых встреч и до новых интересных историй, уважаемые читатели!

P.S. Пожалуйста, если вам интересна история техники и интересные экземпляры компьютерного железа, не забывайте подписываться:

• телеграм-канал: t.me/digitalvintage_ru

• зеркало в VK: vk.com/digitalvintage_ru

Еще больше новостей и статей в нашем блоге Timeweb Cloud.

Но прежде чем мы начнем - дисклеймер:

Все, о чем я пишу в данной статье основано на моем личном субъективном мнении и не претендует на истину последней инстанции. Оно может не совпадать с Вашим, однако помните, что оно основано на многолетнем опыте работы с сетями. По этому я постараюсь быть максимально объективным, но не обещаю этого. Также, данная статья не ставит собой целью очернить или опозорить какую-либо компанию или бренд, превознести одних над другими или найти идеальное и универсальное решение для всех и каждого. Каждый волен сам сделать выбор о необходимости покупки того или иного оборудования, я лишь постараюсь помочь Вам определиться с выбором и попытаюсь предсказать (на базе собственного опыта) вероятное поведение оборудования в будущем.

Также уточню, что я не буду рассматривать варианты перепрошивки устройств под альтернативные ОС по типу Open- и DDWrt, т.е. все устройства буду рассматриваться при работе "из коробки".

Также, так как статья рассчитана для "совсем новичков", я постараюсь рассказывать все простым языком, понятным большинству пользователей.

И да, я не рассматриваю роутеры по наличию/отсутствию в них возможности прокидывания через них IPTV по мультикасту.

В данной статье мы будем рассматривать условные Home (домашний) и SoHo сегмент (SoHo - Small office/Home Office - небольшой офис/домашний офис) сегменты техники, т.е. приблизительно до 10 клиентских устройств (компьютеров/телефонов/телевизоров/приставок).

Давайте начнем с самого начала. Представьте, что Вы купили/сняли/заехали в новую квартиру/дом, в котором нет абсолютно ничего кроме шнурка с интернетом от провайдера. Его на самом деле тоже может и не быть, но чтобы не утруждать себя выбором провайдера, что является выбором "на вкус и цвет", в этой статье представим что он у нас уже есть и он у нас самый-самый лучший =)

Итак, давайте начнем со схемы сети. Чтобы лишний раз не усложнять представим что сеть мы делаем комбинированную (с использованием проводного и беспроводного подключения) по следующей схеме:

У нас есть проводное подключение от провайдера до роутера, также от роутера проводом мы подключаемся к стационарному компьютеру (я вообще всем рекомендую стационарные ПК и телевизоры подключать только по проводу), мобильные же устройства (телефоны, планшеты, ноутбуки) мы подключаем по Wi-Fi.

Сразу хотелось бы обратить внимание на место установки роутера. Для этого я взял план 2-х комнатной квартиры и разметил ее цветными зонами.

Зеленые - это зоны наилучшего расположения для Вашего роутера
Красные - Расположение роутера в этих зонах нежелательно. А все вот почему.
Дело в том, что сигнал беспроводной сети имеет свойство отражаться от поверхностей, а также затухать при прохождении сквозь материал. И как раз несущие стены (так как содержат в себе металлоконструкции) обладают наибольшим коэффициентом отражения, при этом не пропуская сигнал через себя. По этому углы - это наихудшее место для расположения Вашего роутера. На практике бывает такое - вызов с проблемой - "плохо работает вайфай". Роутер находится в углу. Перемещаем роутер на полметра от угла - сигнал улучшается и стабилизируется.

Лучше всего располагать роутер ближе к центру квартиры, как можно выше к потолку (но не впритык к нему) и подальше от несущих стен. Углы для Wi-Fi - зло.

Ладненько, с местом определились. Давайте теперь выбирать сам роутер. Я разделю роутеры на несколько ценовых категорий, цены возьму из магазина DNS (не реклама) для Москвы. Также постараюсь расписать их достоинства и недостатки, акцентируясь на некоторых важных моментах, например безопасности или настройке.

Итак, начнем.

Дешевле только бесплатно (до 2000 руб.)

Tenda N301 - рогатый головастик.

По сути это брендированный китаец в фирменной коробочке. Похожие по начинке роутеры можно найти на али, алибаба и прочих сайтах.

Достоинства:

1. Дешёвый.

2. Неприхотливый.

3. Простой в настройке.

4. Относительно стабильный.

5. Неплохая сборка.

Недостатки:

1. Имеется болезнь - очень часто отваливается Wi-Fi сигнал.

2. Мощность сигнала оставляет желать лучшего.

3. Бывает, беспричинно умирают блоки питания.

4. Встроенный файрволл - это просто название. Как и большинство ультрабюджетных Тенд роутер падает при первой же DOS атаке (не говоря уже о DDOS и более квалифицированных атаках).

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

D-Link DIR-615S - Один из приемников знаменитого DIR-300.

Тоже потомственный китаец, как и в принципе все от компании D-Link. На самом деле у D-Link есть достаточно много хорошего оборудования, и этот роутер не исключение, но с некоторыми оговорками.

Достоинства:

1. Цена

2. Простота настройки

3. Он красивый

Недостатки:

1. Иногда сбиваются настройки - приходится перенастраивать. Благо это не долго.

2. Слабая связка процессор/оперативная память (580 МГц при 64 мб оперативки) - интерфейс роутера часто тупит при настройке.

3. Иногда зависает (но реже чем тенда выше).

4. Имеет болезнь - среднее время жизни роутера составляет полгода - год. После чего эти роутеры умирают с завидной регулярностью. Но если вам повезло и он не умер на этом сроке - то убить его можно будет только молотком. Или кувалдой.

В целом неплохой аппарат для своей цены. Себе я конечно такой никогда брать не буду, но если для вас цена - это критичный параметр то это неплохой вариант, как и в принципе вся 600-я серия D-Link'ов.

Keenetic Start - бывший Zyxel, только в профиль.

Наверное, лучший представитель своего ценового сегмента.

Достоинства:

1. Цена

2. Возможности

3. Красивый

4. Отличая сборка

5. Он действительно редко тупит!

Недостатки:

1. Все-же бывает зависает

2. Настройка сложнее чем у других представителей этого ценового сегмента

3. Бывает (редко) попадаются бракованные блоки питания (быстро умирают ни с того ни с сего)

4. Бывает (еще реже чем в п.3) попадаются бракованные модули Wi-Fi внутри. В данном случае начинает зависать Wi-Fi - сигнал есть но подключиться нельзя.

5. При большом количестве настроек и клиентских устройств все-же начинает подвисать.

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

Средний ценовой сегмент (от 2000 до 5000 руб.)

Asus RT-N19 - вполне неплохая машинка.

Как и в целом все Асусы этот представитель предлагает хорошую функциональность при достаточно небольшой цене.

Достоинства:

1. Функциональность

2. Внешний вид

3. Качество сборки

4. Скорость Wi-Fi (до 600 мб/сек! Но тут есть нюанс - используется n протокол, но об этом чуть ниже)

5. Отличный интерфейс настройки - есть простой и расширенный режим.

Недостатки:

1. 64 мб оперативной памяти. Из за этого бывает зависает при большом количестве настроек.

2. Все-же, его нужно уметь правильно настраивать чтоб получить лучшую производительность (как и в принципе все асусы)

3. Всего 2 порта для проводной локальной сети. Роутер заточен больше под использование Wi-Fi

В общем, хороший роутер за свои деньги.

А теперь о нюансах. Если вы прочитали до этого момента - настоятельно рекомендую Вам ознакомиться с этой статьей на хабре. Там расписаны принципы и в целом нюансы настройки Wi-Fi.

Mikrotik hAP mini - жеребенок из рода породистых скакунов.

Самым младший из микротиков. Красивый, недорогой, предоставляющий огромный функционал...но....

Достоинства:

1. Цена для микротика просто сказка

2. Огромнейший функционал (99% функций вы в жизни не осилите, если не пройдете спец. курсы)

3. Внешний вид

4. Сборка

Недостатки:

1. Скорее всего, самостоятельно Вы сможете его настроить только через Quick Set, который сделает вам только базовые, но далеко не самые оптимальные настройки.

2. Для настройки "по уму" вам понадобится либо профессионал (еще и далеко не каждый сможет), либо навык "ГГГ" (глубокого Гугления Гугла). //Бахвальство mode on// По крайней мере пока я не выпущу статью по начальной настройке микротика //Бахвальство mode off//

3. Довольно слабый Wi-Fi конкретно у этой модели. Нет Wi-Fi 5.

4. Опять же, при скачках напряжения периодически дохнут блоки питания.

5. Всего 3 порта для Ethernet (локальной сети), один из которых вы 100% задействуете под провайдера. Так что считай - их всего 2.

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

Xiaomi Mi Router AX1800 - китайский монстр с огромным функционалом.

Сяоми ворвались на рынок роутеров с довольно неплохими, функциональными устройствами, но к сожалению, со своей, Китайской, логикой. Но ведь не может же быть бочки меда без ложки дегтя.

Достоинства:

1. Огромный функционал

2. Поддержка не только Wi-Fi 5, но и Wi-Fi 6.

3. Наличие фирменного мобильного приложения для настройки и мониторинга

4. Можно запихнуть в фирменный Сяомишный умный дом (сяохата LoL xD)

5. Качество сборки

6. Мощный проц + много оперативки

Недостатки:

1. Все-таки это Китаец

2. Если вам не повезет - вам придется его перепрошивать. Благо на 4pda есть вся информация о том как.

3. Вам придется его правильно настроить. Для этого вам нужно будет понять Китайскую (читай нелогичную) логику.

4. На ранних версиях прошивок не давал права на ошибку - при неверной настройке вис наглухо и помогал лишь резет. Не знаю, исправили ли сейчас, но вроде бы да.

5. Имхо - лично у меня нет уверенности в его безопасности - мне кажется что этот товарищ может сливать информацию большому социалистическому брату.

6. Как по мне - он все-таки очень большого размера и не в каждой квартире он будет смотреться органично.

Лично я бы не стал покупать себе данный аппарат, но это обусловлено скорее моими внутренними причинами - я бы лучше за эти деньги взял себе микротик. Но это оборудование не для всех. Если вы не боритесь Большого брата, разбираетесь в китайской логике и уважаете Xiaomi - вполне приличный аппарат в своей ценовой категории.

Huawei AX3 WS7200 - полный фарш!

Еще один Китаец, на этот раз Huawei.

Здесь полный фарш - и функционал, и процессор огонь, и платформа топовая.... но.... Китаец остается Китайцем.

Достоинства

1. Полный фарш по функционалу

2. Топовая платформа

3. Wi-Fi 5 и 6, до 2,5 Гбит/сек!!!

4. И многое другое

Недостатки:

1. Цена

2. Он реально огромный

3. Большой брат в комплекте

4. Китайская логика

5. Доподлинно не известно сколько времени это проработает

Если вы хотите себе полный фарш - берите. Следующая ценовая ступенька "фарша" находится гораздо выше.

Думаю на сегодня все. Конечно, я не могу рассмотреть абсолютно все устройства всех ценовых категорий, я постарался выделить лишь те, которые достойны внимания. Если фирмы которая вам нравится здесь нет (например того-же Mercurus), это не значит что он плохой - это значит что я просто с ним не работал, и не могу сказать ничего о нем.

Посмотрим, возможно чуть позже мы рассмотрим устройства ценового сегмента чуть выше - от 5000 руб. Ну а так пока, до новых встреч.

За ошибки извините, я не Граммар-Наци.

Время неумолимо бежит вперед: выходят новые гаджеты, постепенно заменяя старые, превращая их в тыкву или в лучшем случае, в «тапочек» для звонков. Сейчас смартфоны стали практически одинаковы во всем: дисплей на всю площадь передней панели, почти полное отсутствие аппаратных кнопок, беспроводная зарядка… Это всё, конечно, здорово, но ведь иногда так хочется взять в руки старый, но такой необычный в наше время QWERTY-смартфон и попытаться его использовать как основной, да и цены на них могут приятно удивить: БУ девайс можно купить за несколько сотен рублей (~5-10$). Одна проблема — клиенты приложений на версии Android 1.6-2.0 безбожно устарели и давно не работают. Но иногда желание воскресить старый девайс превыше потребительского качества и тут я пришёл к мысли… а почему бы не написать с нуля свои клиенты популярных приложений? ВК с музыкой, YouTube, трекинг посылок. Так я и сел писать необходимые в повседневной жизни приложения, с нуля, на голом API Android, без каких либо фреймворков (и даже AppCompat). Получилось ли у меня это? Узнаем в статье!

Мотивация

На самом деле копаться в старых девайсах и пытаться найти им применение — это очень интересное и затягивающее дело. Ведь зачастую попытки оживить девайс заключаются в прочтении большого количества мануалов, документации, копании в терминале, а иногда даже компиляции загрузчиков/ядер! И подобные занятия интересны на всех уровнях: хардварный, системный, прикладной и пользовательский. В предыдущих статьях мы с вами моддили девайсы на всех этих уровнях: ремонтировали «железные» болячки, написали несколько статей о системном моддинге и компиляции загрузчиков под неизвестные китайские устройства, а также узнавали о пользовательском опыте установки готовой кастомной прошивки на 7-летнее устройство.

Но до сегодняшнего дня мы с вами обходили прикладной уровень моддинга устройств: т. е. написание самых обычных, повседневных программ, без которых сложно представить жизнь современного человека. Ещё во времена выхода первого Galaxy S в 2010 году, многие из нас уже сутками красноглазили в Java версии «аськи», кто-то уже сидел в ВКонтакте, хоть и большинство не заглядывали в смартфон каждые пару минут для проверки нотификаций.
К 2012 году смартфонная жизнь уже стала похожа на ту, к которой мы привыкли сейчас — соц. сети, мессенджеры, пуши, потоковое видео — многие из нас успели привязаться к такой жизни и… к конкретно тем самым девайсам!

2012 год давно миновал, тенденции в разработке приложений кардинально поменялись, а учитывая, что многие мои читатели не любят выбрасывать девайсы в мусорку (и правильно делают), наверняка кто-то регулярно заглядывает на полочку к своим пыльным «бывшим» гаджетам и рассматривает их с теплотой… но с сожалением понимает, что их время прошло. Или не прошло? :) Ну, тут как посмотреть. Если есть навыки и огромная мотивация, то программер может многое, в том числе и запилить все самые необходимые приложения сам!
Я давно лелеял эту идею, подумывая, как бы лучше её реализовать. Да и почти всю свою жизнь, я писал на C#, практически не «щупав» API Android и его UI фрейморк. В один день у меня очень сильно зачесались руки написать что-нибудь эдакое под него и причём сразу — весьма серьёзное!

Всем этим устройствам более 10 лет. Самым молодым из них является реплика Lumia 1020, которую мы тоже успели замоддить!

Так и родилась идея написать клиент YouTube. А потом и ВК. Ну и трекинг в придачу. Ну а чего б и нет, на всё про всё я выделил себе неделю: за это время я должен успеть закончить пусть и сыроватые, но вполне юзабельные клиенты для моих любимых сервисов. И я начал думать…

Планирование

Написание приложений под старые мобильные ОС, как и под любые другие платформы, требует планирования того, что и как будет работать с учётом ограничений целевой платформы. У меня было сразу несколько ограничений, что только раззадоривало пыл:

• В большинстве своём, на старых версиях Android работают одноядерные чипсеты, а значит, лимитированная многопоточность. Никакой работы в UI-потоке кроме обновления интерфейса, а поскольку в первых версиях этой системы интерфейс менее отзывчив, чем в более свежих — нужно сохранять баланс между функционалом, симпатичностью и скоростью работы. Мои приложения должны оптимально работать в следующих условиях: 256мб ОЗУ, из которых свободно в среднем 30-40мб (Сбер, привет тебе с вылетами на 2гб ОЗУ), 1 ядро ~600мгц, видео-ядро уровня Mali300-Malii400. Негусто? Ну, нам сойдет.

• Вторым ограничением стало тотальное устаревание корневых сертификатов, а как многие из нас знают, просто так их на мобильных системах не обновить. Поэтому придётся идти на хаки — делать сервер-реле, который преобразует трафик из https в http там, где нельзя просто отключить проверку верификации SSL (это как раз кейс с API VK). Решено — отдельный сервер-реле, который отправляет запрос на сервер ВК и обратно возвращает нам обычный результат в JSON.

• Ну а третьим ограничением стал сам Android. targetSDK = 5 (Android 1.5 Cupcake), никакого AppCompat (кушает драгоценное свободное место), никаких сервисов Google (их тут нет лет 5 уже). Всё на чистом API системы, почти в тех же условиях, в каких 13-14 лет назад писались первые приложения для Android.
  
  

  
  Если я его раздобуду когда-нибудь, то в лепешку расшибусь, но портирую на него свои приложения. Тогда я с гордостью скажу, что мои приложения работают на 100% Android устройств %)

  
  Полный энтузиазма я сел писать код. Основную часть статьи я решил поделить на каждое приложение отдельно с конкретными объяснениями: где, что и как я делал. Хочется заранее сказать — я не особо давно пишу под Android, зато много писал под WinForms, поэтому какие-то решения могут показаться странными. А некоторые решения обусловлены версией Android. Например, нотификации в первых версиях Android не было Notification.Builder, а сам Notification был больше похож на структуру. Приложения, конечно же, мы будем писать на Java.
  
  

ВКонтакте

Первым делом я начал писать клиент ВК и сразу определился со своими хотелками, которые были весьма скромными: возможность листать диалоги, читать сообщения и отправлять их (с полной поддержкой QWERTY-клавиатур, т. е. отправка на Enter), плюс возможность слушать музыку без ограничений. На ВК бочку ни в коем случае не гоню, просто публичного API совсем нет, даже с ограничениями, хотя было бы здорово…

Мне снова хотелось почувствовать те эмоции, которые я когда-то ощущал от прослушивания музыки будучи школяром со своим первым Android-смартфоном. В 2013 году я прилетал со школы и слушал плейлист на практически таком же девайсе с идентичным железом и версией Android. Я хорошо помню, как пользовался прелестями многозадачности Android на 2G интернете (3G чипсет просто не поддерживал): одну песню слушаешь, поставил вторую качаться, пока песня доиграет — уже и вторая скачалась. :)

Итак, хотелки выбраны, пора начинать писать приложение. Для дебага у меня было 3 устройства: Galaxy S4 (Android 4.2 JB), китайский Galaxy S3 Mini I9300 (Android 2.2, на фото выше) и Samsung Galaxy S I9000 (Android 2.3), ну и конечно же эмулятор с 4.4 KitKat. Android Studio и сейчас умеет без проблем собирать приложения вплоть до версии Android 2.2 даже с последними Build Tools и Target SDK — главное выкинуть appcompat, androidx, и юнит тесты из build.gradle. Без каких-либо проблем он цепляет и сами устройства по adb. Даже отладчик без проблем работает.

Первым делом я начал писать активити (полноэкранная форма в терминологии Android, или «экран» приложения) с диалогами — он должен раз в n секунд подгружать данные и строить «морду» для всего этого. По сути, почти весь код клиента — это получение ответа от API ВК, разбор JSON на датасет и визуализация этого датасета на экран. Для этого я ввёл два объекта: VK, который делает асинхронные запросы на сервер, оборачивает работу с сервером-реле и парсит JSON и VKObjectProcessor (это скорее всего отрефакторится до VKDataSet чуть позже).

Архитектура приложения получилось довольно простой и примитивной. При старте активити авторизации проверяет данные приложения (PersistStorage) на наличие API-токена и при его отсутствии запрашивает авторизацию. Как это уже стало классическим среди различных «самопальных» клиентов, мой клиент «прикидывается» официальным приложением ВК — для этого используется связка app_id и app_secret приложения ВКонтакте для Android.

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

При этом сообщения реализованы схожим образом — на данный момент возможности горячей подгрузки сообщений «сверху» нет, поэтому обновляются последние 50 сообщений скопом и сразу. Шустро ли всё это работает? Вполне неплохо. Конечно, основное процессорное время уходит на разбор тяжелых JSON, но тут отчасти вина ВК — мало того, что кастрировали функционал getHistory в последних версиях API, так ещё и нет возможности возвращать только те поля, которые нужны.

Как же я поступил с аудиозаписями? Музыка через API — настоящая заноза для разработчиков клиентов, с которой пришлось «подолбаться». Правда, недолго — раз у нас для основных запросов уже есть сервер-реле, то почему бы не сделать ещё и для музыки? Суть обхода простая: если сгенерировать специальный API-токен, то можно свободно обращаться к методам, связанным с музыкой без необходимости притворяться официальным клиентом и «подписывать» запросы md5 ключом. Примитивный PHP-скрипт как раз и предоставляет такую возможность, позволяя получить доступ к базе музыки ВК, однако ограничение типичное — у пользователя должны быть открыты аудиозаписи:

Тут был код на пхп, о его скушал пикабу!

По итогу у меня получился рабочий плеер с поиском музыки и добавленными треками. Опять же — производительность остаётся отличной! Ссориться с ребятами из ВК не хочу, поэтому добавлять возможность качать треки пока не стал — но вам стоило бы быть подружелюбнее к разработчикам кастомных клиентов! :)

Что мы получили по итогу? Довольно простенький клиент ВК, который практически не потребляет ОЗУ и шустро работает. Да, здесь не хватает кучи различных фич — как минимум, прсомотра ленты и стены. Но ещё успеется — если проект будет интересен не только мне, то продолжим наращивать фишечки потихоньку! Уже ближе к релизу я слегка причесал клиент, добавив более «вкшный» дизайн и приделал анимированное боковое меню. Про Animation ещё кто-то помнит? :)

YouTube

С разработкой клиента YouTube были свои особенности: во-первых, в отличии от клиента ВК, видео через реле просто так не загрузишь, слишком много трафика, а во-вторых, YouTube уже не «отдаёт» видео в форматах, которые поддерживают старые устройства — в основном, это h263 до 720p. К сожалению, потоковое видео с софтовым декодированием уложит на лопатки большинство «одноядерников» тех лет.

Ситуация осложнялась тем, что ни VideoView, ни стандартные плееры всех смартфонов, на которых я отлаживал приложение, не умели игнорировать ошибки SSL и просто валились с ошибкой. Пришлось что-то придумывать: ведь видосики хочется смотреть на крутейшем AMOLED дисплее Galaxy S!

Посидел я, подумал и придумал. Для поиска по базе YouTube, получения информации и прямых ссылок на видео я решил использовать альтернативный фронтэнд YouTube, который называется Invidous API — крутая штука со своим API, которая сама распределяет пул токенов самого ютуба и отдаёт ответы в виде JSON. Форматы запросов очень простые: <url инстанса Invidous>/api/v1/метод, например «search?q=test&region=RU&hl=ru» — выдаст нам результат поиска «test» в Российском регионе. Очень удобно, да? А ещё Invidous — не какой-то отдельный сервис, а целая сеть т. н. инстансов — какой хочешь, такой и юзай! Поскольку большинство инстансов «прячется» за свежими сертификатами, пришлось идти на довольно известный костыль с отключением верификации хостнеймов у HttpUrlConnection:

А туть был костыль на Java.

А поскольку у нас нет возможности воспроизводить потоковое видео онлайн, то я решил его просто предварительно загружать через собственный менеджер закачек, с возможностью последующей очистки кэша. Поскольку таким устройствам 2060p качество не нужно, я выбираю 240p-360p mp4 в avc кодеке, в среднем ролики по 30 минут весят около 30-40 мегабайт. При HSDPA+, загрузка подобного видео займет около минуты-двух — не так уж и много, можно и подождать. Закинул тестовую версию в беседу любителей ретро-мобилок — люди были в восторге. ;)

Поскольку Invidous отчасти строится на анонимности — авторизации тут нет. Однако свою задачу посмотреть видосики он выполняет нормально — поэтому весь UI приложения я поделил на 4 вкладки: тренды, популярное, история и поиск. Подписки, как и историю можно реализовать на стороне клиента — для некоторых такой подход покажется плюсом, для кого-то — нет, однако минимальный задел для клиента уже есть — мы можем смотреть видео!

А где скачать?

Приложения и бэкэнд полностью открытые, исходный код доступен по лицензии GPLv3. Следить за статусом проекта можно на моём GitHub!
Последние версии можно скачать в релизах проекта.

Из текущих хотелось:

• Портировать на Android 1.6. Несмотря на то, что приложение в целом имеет targetSDK = 5, на 2.1 оно работать отказывается. В Android, после 2.1, слегка поменялся бинарный формат xml разметок, из-за чего приложение на старых системах вылетает с исключением. Но это решаемо: eclipse adt в зубы, импортируем проект и вперед! ;)

• Кроме того, я экспериментировал с попытками как можно сильнее уменьшить нагрузку как на сеть, так и на процессор путём облегчения датасетов. Если один JSON от ВК весит в среднем 30-60кб (который 1 ядерный чипсет частотой 600мгц может «долго» жевать, негативно сказываясь на UI), то примитивный KeyValue формат, который содержит только нужные поля умещается в 5-6-7кб в текстовом виде и благодаря своей примитивности (весь парсинг — два substring, один indexof и поиск ключа по хешмапе) совсем не «налегает» на процессор. Благодаря этим наработкам, я запилил и примитивный клиент ВКшечки для j2me.
  
  В целом, можно сделать единый формат датасетов для мессенджеров, а на бэкэнде реализовывать всё что угодно — Telegram, ВК, да хоть личные сообщения на хабре, а для платформ только делать «морды»: так можно завести современные мессенджеры и на Sailfish, и на J2ME, и на Symbian, и на WinMobile, практически без пота и крови :)

• Полная адаптация под кнопочное управление. Сейчас с клиента можно без проблем писать сообщений с любой клавиатуры, в том числе и QWERTY. Однако основной интерфейс всё ещё не полностью адаптирован под кнопки и требует выполнения некоторых действий пальцем.

Заключение

Как по мне — получилось вполне неплохо. Да, приложения кое-где сыроваты и явно не дотягивают по функционалу до их больших версий. Но кое в чем они всё таки выигрывают: они лёгкие и быстрые, а самое главное — ещё могут продлить жизнь любимого девайса для кого-то. И я считаю — это классно! Среднее потребление ОЗУ обеими клиентами: 5-10мб. Вес APK: 30-50кб на момент выхода статьи. Вот что значит писать под голое API без модных фреймворков! ;)
Что до остального функционала — кое-что в Android продолжает неплохо работать и в наше время. Например, DLNA-стриминг в доме, E-Mail клиент или банкинг через смски. Я уверен, это покрывает 80% потребностей большинства пользователей — так разве после этого можно назвать старые смартфоны бесполезными?

Я писал эту статью с целью показать вам, что старые девайсы отнюдь не тыква, если есть щепотка энтузиазма в глазах и любовь к гаджетам, а заодно и поделиться с вами своими приложениями. Часто в комментариях мне пишут, что хотели бы пользоваться своими смартфонами и дальше, если бы не устаревающие версии Android. А вы как считаете? Жду ваше мнение в комментариях.

Статья подготовлена при поддержке компании TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи про девайсы каждую неделю! А ещё не забудьте проставить плюсик на хабре, если статья вам понравилась - это поможет с финансированием и выходом новых статей!