Карманный Groupware-сервер: оценка производительности

    Интернет пришел в Россию в 1995-96гг. Среднестатистическим компьютером тогда был AMD 486DX150 или Intel Pentium100 с RAM 4-8 Mb и HDD 100-400 Mb. Как раз тогда появился Windows 95, и именно новая ОС и потребовала апгрейдов железа до указанных величин, т.к. на типичных для 94го года компьютерах 486 SX25 или DX66 с 2-4 Mb Win95 еле ворочался. Интернет-серверами и роутерами у провайдеров в те годы были точно такие же машины, или даже более слабые, т.к. Linux тогда еще вполне комфортно себя чувствовал на 2 Мб (без GUI), сайты были в основном статическими, и почтового спама еще не было. Доступ к интернету имел в лучшем случае один на тысячу человек — по нескольку сотен человек в среднем российском областном центре, и все они работали через единичные провайдерские почтовые и веб-серверы. То есть один сервер указанной ничтожной по современным меркам конфигурации обслуживал примерно столько человек, сколько сейчас интернет-пользователей в довольно крупном предприятии. И справлялся…

    Есть ли сейчас компьютеры сопоставимой мощности (если слово мощность еще применимо к такому железу), и как они используются? Есть. Нет, это не роутеры и тем более не смартфоны — те и другие заметно производительнее, даже если рассматривать только домашние роутеры и самые простые телефоны. Роутеры легко прокачивают 100Мбит, а телефоны легко крутят видео, да и память у телефонов на сотни мегабайт — ничего такого и близко не было в 96м году. Надо искать более слабые процессоры сопоставимые с Pentium100, то есть около 100МГц или до 200 DMIPS…



    Самый близкий кандидат для сравнения — микроконтроллер ARM Cortex-M3 или -M4. У первого частота чуть меньше 100МГц, у второго чуть больше, декларируемая производительность 125-210 DMIPS (2.19 CoreMark/MHz — 1.25 DMIPS/MHz — как раз как у Пентиума в 96м). Встроенная SRAM контроллера всего около 100Кб, но к контроллеру можно подключить мегабайты внешней SDRAM, работающей как раз на той же частоте, что у первых Пентиумов. Итого получим примерный эквивалент материнской платы тех лет, но размер всей платы будет меньше сокета Пентиума, и потребляемая мощность на порядок меньше тогдашних (всего 10-Ваттных!) Пентиумов.

    Как и что будем сравнивать, и главное зачем. Будем измерять производительность Cortex-M3 на нетипичных для него сетевых задачах. Ethernet-контроллеры во многих Cortex-M3 есть, причем в вариантах фирмы TI даже с встроенным PHY (т.е. не требует никаких внешних чипов, подключается сразу к MagJack'у RJ45), но считается, что использоваться это должно либо для промышленной автоматизации — гонять по сети команды управления/мониторинга, либо в быту — сетевые счетчики потребления коммунальных услуг, управление «умным домом» и т.п., т.е. задачи важные, но совсем «из другой оперы». Но раз по предполагаемой производительности он соответствует серверам, которые в прошлом «сервировали» целые города, то может не стоит ограничиваться этой традиционной нишей и имеет смысл оценить применимость контроллера для серверных задач? Не в масштабах интернета, а для локальной сети. Во времена, когда космические корабли бороздят просторы Вселенной, а ИТ-отделы предприятий аутсорсят свои внутренние задачи во внешние облака, задача поставить реальный сетевой сервис на машину, которая в сотни или тысячи раз медленнее обычного офисного ПК, может показаться бессмысленной. Но с другой стороны, если контроллер (вдруг) справится с поставленной задачей, то не делает ли это бессмысленной аппаратную «гонку вооружений» при решении этой конкретной задачи? И не в этом ли и состоит наша инженерная работа в конечном итоге — повышении эффективности работы, в т.ч. и за счет уменьшения затрат на производство? Чтобы либо (1) производилось больше за те же деньги, либо (2) столько же работы, но за меньшие деньги. Мы будем выяснять пределы наших возможностей по второму варианту.

    Теперь о выборе тестовой задачи. Есть одна ИТ-задача, в которой объемы операций постоянны во времени, потому что ограничиваются не возможностями техники, а производительностью самого медленного участника техпроцессов — человека. Причем выключить это слабое звено из процесса в данном случае не получится к сожалению (или к счастью), потому что этот процесс самый человеческий — процесс принятия решений! — его человек предпочитает не поручать пока технике, т.к. техника с такими возможностями может принять решение, что человек не нужен… В чем состоит суть процесса: человек анализирует текущую ситуацию (по доступной ему информации) и решает, что делать дальше, фиксируя это решение либо в непосредственных физических действиях, либо в изменении внутреннего состояния («теперь я знаю что делать» или «я подумаю об этом завтра...»). Если не считать мелких автоматических решений, принимаемых на автопилоте — куда поставить ногу или из какого кармана достать телефон — а считать только осознанные решения, требующие фиксации внимания, то «тактовая частота» человека составляет не больше 200-300 решений в день. Если же человеку приходится синхронизировать все свои решения с другими людьми, т.е. совместно одновременно решать общие задачи, то индивидуальная производительность падает на порядок — едва ли можно провести более 20 совещаний в день, а ведь еще нужно время на подготовку информации и на претворение решений в жизнь (лично или поручив другому, что тоже требует синхронизации)… Компьютерные Groupware-системы (GWS) призваны повысить эффективность совместной работы, и сделать это они могут только превращением синхронных событий в асинхронные, исключая блокировки и ожидания между людьми: после решения/выполнения очередной задачи человек должен тут же получать от GWS полную информацию для принятия следующего решения. GWS при этом работает подобно планировщику задач в операционной системе, а люди работают подобно кассирам в супермакетах — каждый выполняет свою работу на пределе своих собственных возможностей (если к нему очередь покупателей, т.е. «задач»), работая только со своей очередью, не отвлекаясь на взаимодействие с коллегами (любое такое взаимодействие типа обращения к соседнему кассиру «Лена, разменяй 5тыщ» тут же заметно стопорит сразу две очереди), коллеги должны работать асинхронно — обеспечить запасы разменной монеты, кассовых лент, товаров на полках, покупателей в зале и т.д.

    Таким образом в GWS можно оценить требуемую максимальную производительность системы: 200 умножить на количество пользователей системы. На практике, конечно, такие параметры потребуются только в очень хорошо проработанных организационных процессах. Типичным для небольшого офиса или предприятия (до 100 человек) будет скорее 200-300 решений в день на всех, тем более что далеко не все события находят отражение в GWS. Будем считать, что несколько тысяч в день закрывает (с запасом) все текущие потребности типичного офиса — для почти любой отрасли и независимо от развития технологий вокруг.

    Если вы еще здесь, то начинаем переводить это в компьютерный язык. Что представляет собой событие или задача в GWS? Сообщение электронной почты, событие в календаре, задача в трекере, заявка/счет на сайте и т.п. В большинстве случаев такой файл или запись в БД имеет размер от единиц до десятков КБ. Я посчитал средний размер задачи в наших календарях (ics-файлы формата VCALENDAR с задачами VTODO или событиями VEVENT внутри) за несколько лет — 700 байт. Сообщение форума — полтора КБ. Страница внутренней wiki — 4 Кб. Письмо в техподдержке — 12 КБ (часто с прикрепленными файлами, т.е. средний размер собственно текста намного меньше). При таких размерах можно оценить объем новой информации для одного сотрудника в 1МБ в день и не более 50МБ в день для всего офиса (с учетом того, что многие элементы GWS адресованы нескольким получателям). Если объёмы выше, то значительная часть задач не будет выполнена никогда — просто физически не успеют обработать — будут удаляться без прочтения или висеть вечно (или автозакрываться/архивироваться «за давностью», что то же самое). При таких объемах информации GWS-сервер на базе современного ПК может кэшировать в RAM задачи за несколько месяцев, может «отгружать» все задачи одного сотрудника за день менее чем за одну секунду, хранить в оперативном доступе на диске все задачи всего офиса за несколько лет, и т.д. Понятно, что в зависимости от форматов баз данных, используемых протоколов, используемого серверного и клиентского ПО эти параметры могут варьироваться в широких пределах, различаться на порядок, но также понятно, что мощности обычного ПК для этих задач хватает с огромным запасом. Значит можно попробовать выполнять ту же задачу на менее мощном железе.

    Производительность сервера при таких небольших объемах и применении кэширования можно считать не ограниченной в случае ПК, а для контроллера числа такие: Cortex-M3 на 80МГц копирует SDRAM-память со скоростью 16 МБ/с (средствами процессора, без использования DMA), отправляет TCP/IP-данные через 100 Мбитный встроенный Ethernet-контроллер со скоростью 4-5 МБ/с (тоже без использования DMA, т.е. есть резервы оптимизации). Выходит, что в идеале контроллер синхронизирует все календари за считанные минуты, причем для отдельного пользователя это можно сделать вообще за секунду. Но на практике все обычно очень далеко от идеала, зависит от протоколов и сценария работы.

    Предположим, что для работы с событиями/задачами пользователи используют календарные-клиенты с протоколами WebDAV/CalDAV (Outlook, Evolution, SunBird, Thunderbird+Lightning и т.п. на настольных ПК, iCAL на iPhone/iPad, и т.д.), а сервер соответственно любой веб-сервер с поддержкой этих протоколов. Но мы будем тестировать не производительность клиентского ПО (ясно, что она достаточна на современных ПК), и не производительность конкретных моделей GWS (ясно, что они тормозят в широких пределах), а соотношение сил контроллера и ПК в сетевой работе на задаче этого типа. При синхронизации календарей клиентское ПО использует несколько HTTP/WebDAV-команд — OPTIONS, PROPFIND, GET, PUT — основное время проводя в команде PROPFIND, которая выбирает из списка событий на сервере подмножество, удовлетворяющее заданным критериям. Принцип примерно как при получении почты — выясняется «что нового» и скачивается новое, плюс (в отличие от почты, но подобно например новостям NNTP) выясняется, чего нет на сервере, и передается командой PUT. Мы для упрощения будем на первом этапе тестировать только GET, программой ApacheBench. Запустим множество параллельных отдельных коротких соединений с одиночными GET-запросами, имитируя неоптимальных клиентов, получающих по одной задаче. Запустим длинные соединения с несколькими GET в режиме Keep-Alive, имитируя PROPFIND с multiget'ом внутри. И будем получать в каждом тесте по нескольку сотен коротких файлов, имитируя сеансы синхронизации отдельных пользователей, получающих все задачи за один или несколько дней.

    Железо. Будем сравнивать офисный ПК на экономном процессоре AMD E350 (потребляемая мощность близка к первым Пентиумам или современным Atom'ам, а производительность на два порядка выше первых Пентиумов и заметно выше, чем у Atom'ов) с 4GB RAM и коробочку 6x6 см HonixBox с ARM Cortex-M3 (TI LM3S9B95) и 8 MB RAM внутри. Они подключены к одному и тому же 100Мбитному коммутатору в одном кабинете и отделены еще двумя коммутаторами (гигабитными) от компьютера в том же офисе, на котором запускается ab, имитирующий клиентов.

    Софт. На ПК работает Windows 8 beta 64bit, в качестве сервера nginx/1.0.14 (текущая стабильная сборка) для Windows. На HonixBox — самодельный веб-сервер на самодельной ОС, скомпилированных самодельным компилятором (никакой спец.оптимизации под эту задачу — сервер был написан для выдачи сетевой статистики, основной «профессии» HonixBox'а; на ассемблере во всей системе написано около 500 байт кода, все остальное написано на Форте без какой-либо оптимизации, т.к. исходная задача HonixBox'а была предельно проста, почему и была реализована на контроллере).

    Тестируем. Сначала я хотел запрашивать "/" на HonixBox (небольшой скрипт, выдающий страницу с текущими настройками HonixBox и суммарной статистикой), а на nginx запускать PhpInfo(), но PHP под Windows в FastCGI-режиме не доживает под управлением nginx до 500 запросов — слетает. Не стал пока разбираться (первый раз в жизни запускал nginx), переключился на статические файлы, тем более что календари под WebDAV — наборы статических файлов.

    ab -n 500 -c 100 192.168.0.156/favicon.ico (единственный файл на HonixBox'е, по размерам близкий к VTODO; а на nginx запрашиваем более короткий index.html) — имитируем получение 500 отдельных задач сотней клиентов одновременно.

    Результат nginx:
    Time taken for tests: 1.994990 seconds
    Complete requests: 500
    Failed requests: 0
    Write errors: 0
    Total transferred: 181000 bytes
    HTML transferred: 75500 bytes
    Requests per second: 250.63 [#/sec] (mean)
    Time per request: 398.998 [ms] (mean)
    Time per request: 3.990 [ms] (mean, across all concurrent requests)
    Transfer rate: 88.22 [Kbytes/sec] received

    Результат HonixBox:
    Time taken for tests: 10.466127 seconds
    Complete requests: 500
    Failed requests: 0
    Write errors: 0
    Total transferred: 211500 bytes
    HTML transferred: 159000 bytes
    Requests per second: 47.77 [#/sec] (mean)
    Time per request: 2093.225 [ms] (mean)
    Time per request: 20.932 [ms] (mean, across all concurrent requests)
    Transfer rate: 19.68 [Kbytes/sec] received

    Пятикратное превосходство ПК над контроллером. Обращаем внимание на низкую итоговую скорость передачи в обоих случаях — всего 20-90 КБ/с. Скорее всего скорость ограничена в основном задержками на установку/разрыв множества TCP-соединений (стороны ожидают подтверждений друг от друга). Но к-во запросов в секунду вполне соответствует типичной скорости синхронизации календарей или получения email.

    Убираем -c, добавляем -k (Keep-Alive) — Nginx ускоряется до 259 запросов в секунду, HonixBox до 52, т.е. однопоточный вариант (отдельный клиент получает 500 задач за 2с с Nginx и за 10с с HonixBox). Добавляем -c 10 (10 клиентов получают по 50 задач каждый одновременно) — Nginx ускоряется до 424 з/с, а HonixBox остается на 52, проигрывая в этот раз восьмикратно.

    Результаты хуже, чем я ожидал — даже закрались подозрения, что что-то не то с ApacheBench под Windows — но итоговое соотношение сил ПК и контроллера наверняка от «ab» не зависит. И оно показывает, что ограничивающим фактором является не скорость процессора, а сеть (хотя по FTP между этими двумя машинами скорость 11МБ/с — в 100 раз больше, чем типичная скорость в приведенных выше тестах) и еще более схема работы — множество мелких объектов, получаемых отдельными HTTP-запросами. Ну а самое главное — разница в скорострельности ПК-сервера и контроллера-сервера всего 5-8-кратная, а не хотя бы 50-кратная, как можно было ожидать, и при этом у софта на контроллере еще непаханное пространство оптимизации, и у ПК огромный резерв неиспользованной мощности — Nginx в этом тесте напрягаться не пришлось, он в основном находился в ожидании в/в. Но и в текущем варианте оба сервера выдают данные как раз с такой скоростью, какая (или даже более низкая) обычно наблюдается при работе например в Lightning с реальным WebDAV-сервером. Т.е. пользователь вряд ли заметит разницу. Тем интереснее будет сравнить ПК и контроллер в реальной работе в режиме Groupware. Этим займемся в следующий раз, если кому-нибудь кроме меня тоже интересно.
    Share post

    Comments 40

      +1
      Эм. Я правильно понял, что вы сравниваете компьютер с 1,6 ГГц x86_64 процессором и 4 Гб памяти внутри и некое устройство с 80 МГц ARM процессором и 8 Мб памяти? Так всего лишь восьмикратный проигрыш — это вполне нормально.
        +1
        Правильно поняли. Почему нормально? Разница частоты 20, два ядра, т.е. уже 40, плюс суперскалярность x86 — уже 80, а не 8. А если учесть, что Форт-код здесь ничуть не оптимизирован, то надо умножать разницу еще в 5-10 раз, т.е. 400-800.

        А 5-8 — это скорее на разницу в цене этих процессоров похоже, а не на разницу производительности :)
          +1
          Я просто не понимаю смысла в таком сравнении. Любому с первого взгляда будет понятно, что HonixBox в качестве HTTP-сервера проигрывает даже Pentium 2 с LAMP-сервером на борту.
            0
            Смысл в том, что конечный пользователь этого не заметит. Значит мы можем решать задачу оптимальнее в десятки раз по питанию, по размерам, и в разы по цене.
              +1
              «С первого взгляда» я лично ожидал хотя бы 50-кратной разницы. Но оказывается не все так очевидно.
            0
            Мм есть вай роутеры с ними можно потягаться
            wiki.openwrt.org/toh/tp-link/tl-wr703n

            Чем не карманный сервер при цене за 20-25$ за штуку:)
            USB Флешку воткнуть мини сервак готов=)
            Atheros AR7240 CPU (400Mhz)
            Atheros AR9331 Chipset (integrated wireless)
            802.11 b/g/n 150Mbps (130Mbps real)
            wireless power output 20dBm — 100mW
            4 MB flash memory
            32 MB RAM
            USB 2.0 port
            Powered via micro-USB socket
            Tiny form factor: 5.7cm x 5.7cm

              +1
              Отличная вещь! И плата похожа на HonixBox :) Но роутеры и смартфоны я отверг во втором абзаце ;) Причины там описаны.

              HonixBox
              image
              wr703
              image
                +1
                Да, кстати к вопросу о «графической подсистеме» (TimID указывал ниже). К HonixBox'у экран подключить можно — через разъем справа (у надписи Honix), есть готовые совместимые. Или туда же датчики (к комментарию lehha про Arduino ниже). А указанный TpLink более узко заточен на одну задачу.
                  0
                  Меня привлек набор пакетов…
                  Перл полный, Питон полный,

                  Сеть ipv6 / gw6c / ipsec strongswan и много другого…

                  На одном из таких роутеров сделал сетевой USB диск через Samba server;)

                  меня привлек форм фактор и совмстимость с линуксом и перспектива доставлять систему на внешний носитель.
                    0
                    Да, на роутерах сейчас много интересного делают.
              +1
              Странно, конечно, что Вы взяли ngix под Win8 для сравнения с самописным сервером, но явно не имеющим графической подсистемы.
              Попробуйте все же поставить хотя бы связку LAMP из UbuntuServer. Так сравнение будет корректнее.

              Но можно ли попросить исходники для Вашего контроллер-сервера опубликовать? Данный проект очень интересен.
                +2
                Nginx как-то тормозится из-за GUI Win8? В Убунте она ему не мешает? Но сравнить с линуксом, особенно на той же машине, конечно будет интересно. И мне скорее всего далее и придется так поступить, т.к. со скриптами у Nginx+PHP под виндой явно что-то не то.

                Исходники выдам, если вы обещаете изучить Форт для их чтения ;) Там ни буквы на Си. Ни в сервере, ни в трансляторе.
                  +2
                  Win8 имет в разы больше фоновых задач чем голый линукс сервер. Отсюда более частое переключение контекста и прочее. Так, что да. Тест не адекватный.
                    +1
                    Форт, это, конечно, печально (для меня). Учить времени нет.
                    Но может как раз в нем проблема?
                    Не попадался ли Вам пример веб-сервера для такого контроллера?
                      +1
                      Есть штатные примеры от TI (у них на сайте доступны) — на базе свободных lwIP и т.п. микро TCP/IP-стеков. Но они совсем игрушечные. Есть несколько RTOS со своими серверами. Но можно поставить и облегченный Linux — ucLinux.

                      > Но может как раз в нем проблема?

                      Какая в нем проблема?
                        0
                        Ну, согласно принципам построения трансляторов с Форта, полученный (машинный) код — это последовательность вызовов процедур с глубокой степенью вложенности. А значит очень велики накладные расходы на работу со стеком.
                        То есть если попробовать написать «плоский» код — может получиться гораздо более эффективный сервер.
                          +1
                          Да, про неоптимальность кода, порождаемого ЭТИМ транслятором я честно написал, а в зрелых фортах, в т.ч. нашем spf.sf.net есть оптимизаторы (автоматические), дающие вполне сравнимый с Си код.

                          Но раз даже в текущем виде этот встроенный форт на слабом процессоре отстает от самого быстрого в мире веб-сервера nginx на процессоре, который быстрее на два порядка, всего в 5-8 раз, то оптимизация форт-кода будет преждевременной оптимизацией, которая скорее всего заметной разницы не даст, т.к. задержки здесь (и тем более у nginx) явно не в коде.
                      0
                      Было бы любопытно взглянуть. Форт изучал, даже писал свой транслятор FORTH-83 на ASM 8080. Ну и в nnCron использовал по мелочи. Честно говоря, думал, что язык практически мёртв или just for fun.
                        0
                        Ладно, тогда следите за iron.snop.ru — туда положу, когда причешу для публикации.

                        Форт ничуть не мертв. Если знаете nnCron, то наверняка знаете и о Eserv (на том же трансляторе Форта сделан) — www.eserv.ru — регулярно выпускаются новые версии. Исходники тоже доступны.
                        0
                        Nginx под windows работает медленно о чем написано в документации:
                        nginx.org/ru/docs/windows.html
                      0
                      Был подобный интерес по Arduino+Ethernet Shield v2:
                      встроенный сервер обрабатывал 20 запросов в секунду, выдавая состояния 2х аналоговых входов.

                      Если же отключить чтение входов, то скорость возрастала до 100 запросов в секунду.
                        +1
                        У Arduino ограничение на к-во одновременных коннектов (в ethernet-контроллере, который там аппаратно реализует tcp/ip), а собственной памяти arduino не хватит на реализацию никакого традиционного сетевого сервиса, кроме собственно выдачи значений датчиков, а внешнюю RAM не подключить. Ну и собственно по условиям эксперимента, которые я поставил в начале текста, он не подходит, т.к. не похож по параметрам на те компьютеры, которые в середине 90х «сервировали города». Он даже и до серверов ARPANET'а из 70х не дотягивает, по-моему.
                        0
                        только непонятно почему интернет в 95-м пришел? Я как частное лицо в 92-м подключился и был даже не в первой сотне, а в столицах наверняка все еще раньше началось. А организации — еще раньше.
                          +1
                          Вы знаете хотя бы один русский сайт 92го года? В 92м был «Релком». Интернет-email, но без онлайн-доступа (ftp-mail не в счет). Ну и FIDO :)

                          В 95м интернет окончательно перестал быть военно-академической штучкой, а стал применяться коммерческими структурами и частными лицами.
                            0
                            ну русских сайтов-то не было конечно и да — в основном почта, но буржуйских сайтов все же было много и поисковики даже. И несколько браузеров, которые картинки показывали и еще несколько, которые не показывали. Другое дело что стоило оно вменяемых денег только с доступом к почте — полный интернет в релкоме был в районе 4-х долларов в минуту, а спринт и роспак еще дороже (к 94-му снизилось до 70 центов), а основная структура повторяла все то же fido — рассылки всякие по темам обсуждений. Но все равно было удивительно что почта куда-нибудь в Австралию может идти не неделю, а пару минут :)
                              0
                              В нашей провинции интернет был $6/минута в 1996м году. А до этого года только почта.
                          +1
                          486DX150 — разве не Intel?
                            +2
                            Аналог интела от амд тех времен.
                            image
                              0
                              image
                                0
                                Ах, боже мой, как он «гнался»! Иногда до 180 МГц!
                              –1
                              Бывает и AMD.
                                0
                                У меня (в 94м) был от AMD, у интела на тот момент такого не было, по-моему. Зато уже был Пень.
                                  0
                                  Уточнение: AMD 486DX133, у всех без проблем разгонялся до 150. У некоторых умельцев и до 160.
                                    –1
                                    Вроде сама intel ограничилась DX4@100 в принципе, и то на самом деле они были DX3@99
                                      0
                                      Да нет, вроде, базовая частота была 25 МГц для DX4.
                                      Помнится, мы еще упражнялись выставляя для них базовую (шины) частоту в 30, и получали 120й камень.
                                        +1
                                        Вроде реальное учетверение частоты было только у Am5x86 (133), а что у интеловских, что у амдшных DX4 было утроение. 120 получали из 100 выставляя 40 вместо 33 (платы на 486 до 50 тактовую держали).
                                          0
                                          Действительно, я немного запутался (давненько это было).
                                          Ведь был же еще Cyrix 5x86 с ограниченной поддержкой инструкций Pentium.

                                          Но, черт возьми, они же с пассивным охлаждением часто работали!

                                          Вот, кстати, нашел подтверждение, что не только у наших умельцев 160МГц было на AMD — они штатно такими выпускались:
                                          image
                                            +1
                                            > не только у наших умельцев 160МГц было на AMD

                                            Ну, это было уже несколько позже, чем 95-96 год. Они у наших умельцев узнали, что можно гнать, и перемаркировали :)
                                              0
                                              > Но, черт возьми, они же с пассивным охлаждением часто работали!

                                              Да. Я по этой причине тогда долго не хотел на пень переходить. Кстати, современный AMD E350 тоже может работать с пассивным охлаждением — греется до критических для него 90 градусов, но живёт.
                                    0
                                    Всё возвращается на круги своя. Старое доброе железо, старые добрые скрипты и языки. Пассивное охлаждение возвращается, в том числе на новых платформах, заточенных под «Ультра» БУКИ. Сравнение с ардунито правильно, но форт для него пока не видел ( а может прост потому, что на ардунито пока пару устройств делал). Но, поражен. Если неоткомпиленный код под Windows 8 дал такие результаты, то перекомпиленный на С Он даст совсем другие результаты. Готов вспомнить форт ради перекомпилирования)

                                    Only users with full accounts can post comments. Log in, please.