Задержки — камень преткновения интернета вещей



    История развития интернета, компьютеров и гаджетов неразрывно связана с уменьшением времени реакции. Загрузка сайтов, запуск программ, обработка видео — всё это с годами становилось быстрее и быстрее. Однако человек субъективно начинает воспринимать как мгновенную реакцию задержки меньше определённой продолжительности. В случае с интернетом вещей пусть и короткие, но многочисленные задержки вполне способны складываться в секунды.

    Это будет неприемлемо для пользователей и на корню погубит саму идею окружающей среды, объединённой в сеть.

    Ещё не так давно считалось, что 10 секунд для загрузки — это вполне приемлемо. Но проведённое в 2009 году исследование показало, что около 40% пользователей закрывают вкладку браузера, если сайт грузится более трёх секунд. И сейчас, шесть лет спустя, наши требования к скорости работы веба стали ещё выше.

    Но у этой тенденции есть определённая граница — наша собственная физиология. Многие процессы, выполняющиеся менее чем за одну секунду, воспринимаются нами как вполне комфортные. И не потому, что мы не в состоянии это зарегистрировать, — конечно же в состоянии, — а потому, что такое время ожидания обычно не заставляет нас прерывать мыслительный процесс. То есть мы замечаем подобные задержки, но они не лишают нас контроля над ситуацией, когда мы вынуждены слишком долго (субъективно или объективно) ждать реакции устройства или программы. А задержки менее 0,1 секунды мы уже не замечаем и воспринимаем такой уровень реакции как мгновенный.

    Постоянный рост требований к скорости реакции привёл к тому, что ни один серьёзный продукт не разрабатывается без жёсткого контроля за уровнем задержек: как в работе интерфейса, так и в выполнении заложенных функций. Многим крупным сетевым проектам удаётся достичь, условно, мгновенной скорости реакции на действия пользователя. Например, Spotify, Twitter, ряд мессенджеров и так далее. Но в сфере распределённых сетевых систем ещё есть к чему стремиться. На данный момент вряд ли технологически возможно обеспечить мгновенную скорость реакции в системах электронной коммерции или географически рассредоточенных системах. Их пользователям остаётся только мириться с этим, привычно ожидая подтверждения оформления заказов в интернет-магазинах и загрузки результатов поиска в корпоративных базах данных.



    Однако сейчас мы стоим у начала нового этапа развития технологий. Речь идёт об интернете вещей, то есть о межмашинных коммуникациях (M2M, machine-to-machine). И в данном случае мы точно не станем мириться с достаточно длительными задержками. Когда вы нажимаете выключатель лампы, то ожидаете, что свет вспыхнет или погаснет мгновенно. Кстати, вы замечали, что у энергосберегающих лампочек есть крохотная задержка в срабатывании, когда включаешь свет? Задержка совсем небольшая, но она есть, и её никак не ожидаешь в такой вещи, как лампа. И потому она вызывает подспудное напряжение, раздражение. Иными словами, когда мы взаимодействуем с материальным миром, с инструментами, предметами, приборами, то ждём от них мгновенной реакции на наши действия. Но с внедрением интернета вещей обеспечивать мгновенность реакции для пользователя будет всё труднее и труднее.

    Например, тот же выключатель уже не будет напрямую контролировать работу лампочки. Когда вы откроете дверь своего «умного» дома, то датчик отправит информацию об этом событии на управляющее устройство, оно перешлёт на удалённый сервер, а тот уже выдаст команду лампочке зажечься. Ну, или будет реализована какая-то другая схема, с несколькими промежуточными участниками, оснащёнными микросхемами и сетевыми интерфейсами. И подобных примеров усложнения простейших операций можно будет привести множество. Причём в интернете вещей речь пойдёт уже не некой распределённой системе, а о множестве систем, состоящих из множества устройств, взаимодействующих внутри и между системами множеством разных способов. Бесконечность в кубе. И всё это должно будет срабатывать моментально для пользователя, потому что для него это одно из базовых восприятий реального мира.



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

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

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



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

    Для облегчения взаимодействия между системами разных организаций можно будет использовать платформы, агрегирующие и предоставляющие распределённым сервисам необходимые данные. Вероятно, использование подобных технологий приведёт к трансформации нашего представления об IT-мониторинге. Мы перейдём от модели, в основе которой лежит устройство, сервис или приложение, к информационно-центрической модели. Упор будет делаться не на контроль работы каждого компонента, а на сбор из нужных источников достоверных и качественных данных, необходимых для работы аналитических механизмов. Которые, в свою очередь, будут играть важнейшую роль в работе служб интернета вещей, генерируя управленческие команды в реальном времени. Не говоря уже об анализе задержек post factum, ради выявления слабых мест и оптимизации.



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

    В целом, есть надежда, что сама идея интернета вещей выдержит первое соприкосновение с пользователями и не будет отвергнута ими из-за большого времени реакции. Всё-таки опыт ежедневного использования интернета приучил нас к тому, что не все сервисы и сайты реагируют мгновенно. И на этом «кредите доверия» можно будет довести задержки в интернете вещей до приемлемого уровня. Развитие технологий будет нацелено на ускорение работы приложений и постоянное снижение порога приемлемых задержек. Для этого потребуются новые высокопроизводительные инструменты в сочетании с обширными аналитическими и оптимизационными алгоритмами. Всё это, возможно, станет залогом выживания и развития интернета вещей.
    ASUS Russia
    0.00
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 23

      0
      Камень преткновения, а не краеугольный.
        0
        Логично, вы правы.
        +3
        Я так и не понял, как big data спасет от latency. Что вы хотели нам сказать?
          0
          Под большими данным подразумевается информация о генерации трафика устройствами и путях прохождения пакетов. Я считаю, что это поможет выявлять узкие места, неоптимальность распределения нагрузки, характерные особенности генерации трафика от каких-то видов устройств и т.д.
          +7
          Слишком много картинок совсем ничего не показывающих, в одном стиле «интернет вещей»-«интернет вещей»-«интернет вещей». Хоть бы котиков добавили, я не знаю…

          Соглашусь с предыдущим автором — как big data повлияет на задержку? Максимум скажет — лампочка зажигается 3секунды. Но это скорее всего означает хреновую реализацию, и в первую очередь работать надо над нормальной реализацией протоколов взаимодействий интернета вещей, а не подключением для сбора big-data и вынесения капитанских заключений.

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

          Проблема надуманна
          Удаленный сервер — лишнее звено. Я понимаю, есть редкие случаи, когда нужен удаленный сервер, но зачем это обычным людям? Ведь всё что угодно может случиться — обрыв кабеля в доме, отключение ЦОДа у этого самого удаленного сервера, «интернет не оплатил» итд итп. Пропадет связь — лампочка пусть себе работает, холодильник дальше пусть морозит, стиралка стирает, плитка готовит. Это не должно влиять на абсолютное большинство приборов, так-что при включении датчика — он максимум отправит данные на управляющее устройство, которое тут же сообщит лампочке зажечься. Задержка не думаю что будет более 0.1 секунд.

          З.Ы.: К вопросу о big data: а что, вы собрались собирать про людей кучу данных — когда он включил лампочку, когда выключил, сколько раз в день он открывает холодильник, сколько потратил киловатт на разогрев курицы, сколько воды кипятит в чайнике...? А это не нарушает чью-то частную жизнь?
            0
            К вопросу о big data: а что, вы собрались собирать про людей кучу данных — когда он включил лампочку, когда выключил, сколько раз в день он открывает холодильник, сколько потратил киловатт на разогрев курицы, сколько воды кипятит в чайнике...? А это не нарушает чью-то частную жизнь?

            Полагаю, что сбор данных будет внесён в пользовательские соглашения, которые подавляющее большинство людей подтверждает не глядя. Да, сбор статистики о пользователе, я с вами соглашусь, является вторжением в частную жизнь. Но это не сильно останавливает корпорации, которые по факту давно это делают.
              0
              На новых смартфонах до 12 различных сенсоров, которыми можно собрать множество информации в том числе и медицинского и полицейского характера. На моём смартфоне стоит CM9, сенсоры обычно отключены, обмен мобильными данными как правило выключен. Библиотеки, которые остались от производителя я дизассемблировал и просмотрел подиагоналии. Явных закладок там нет, но могут быть уязвимости. Как они могут быть и в CM9 коде.

              Есть подобные решения у коммерческих компаний.
            +1
            Мне, как обывателю не имеющему никакого отношения к интернету вещей, кажется что последовательность немного попутана. Не лучше ли вариант «нажали включатель — включилась лампа — сервер узнал о состоянии лампы? И задержка сразу же пропадает.
              +2
              тогда пропадет «умность»: ты открыл дверь, а свет «сам» включился
                0
                Датчик на двери напрямую включает свет и ставит в известность сервер уже о факте включения света?
                  +2
                  Вы так всю идею «умных домов» на нет сведете!
                    0
                    Рациональное разделение данных можно сделать. Но вначале надо приучить людей использовать автогенераторы модулей GNU/Linux на основе спецификаций железа с одной стороны и OS с другой. IMHO
                      0
                      Так пусть устройства работают в первую очередь друг с другом напрямую, когда это возможно, а не через удаленный сервер, который может и зависнуть и вообще скайнетом заразиться. Тем более, что большинство действий в умном доме не требуют вообще никаких существенных вычислительных мощностей. А запустить кондиционер при определенной температуре, выключить на улице свет с восходом солнца или в комнате при отсутствии людей — совсем не сложная задача.
                      Может лучше иметь какой-то небольшой хаб в каждой комнате, который будет обрабатывать минимальное взаимодействие модулей, собирать все данные от подключенных к нему модулей, синхронизировать эту информацию с основным сервером и при необходимости уже принимать от него задания, вроде удаленного включения кофеварки с мобилки, различных предиктивных сценариев и т.д.?
                        0
                        Такой хаб уже выпустили. Ставят его обычно в электрощитовую или на DIN рейку.

                        RT5350F-OLinuXino-EVB можно вмонтировать в стену с специальной пластиковой коробке.
                +1
                если все дома будут управляться каким-нибудь гуглом, то задержки будут не самой важной проблемой.
                  +4
                  проведённое в 2009 году исследование показало, что около 40% пользователей закрывают вкладку браузера, если сайт грузится более трёх секунд

                  Интересно, а можно ссылку на исследование? Я понимаю, если это у кого-то вызывает раздражение, но зачем вообще открывать сайт, если ты его можешь закрыть просто потому, что он долго грузится?
                  0
                  В самих MC нужно использовать 2 типа вызовов внутри общего цикла устройства. Быстрые (~50mc) и медленные (порядка секунд и более). Есть готовое решение.
                    0
                    Кстати о картинках. А где брали иконки и картинки?
                    0
                    А где грань, за которой начинается «интернет вещей»?
                      0
                      Бороться с задержками через облако это прямо как комиссия по борьбе с бюрократизмом.
                      А если серьёзно, не нравится ухудшение предсказуемости и понятности поведения «дома». Как бы не пришлось в будущем обращаться в сервис центр, чтобы заменить лампочку.
                        +2
                        Для замены аккумулятора в Форде уже предусмотрена процедура согласования и сертификатов на уровне шины обмена данных. И более того, если вы вовремя не заплатили за кредит автомобиля, он просто не заведётся. Вот поэтому всё IoT должно быть не только с открытым исходным кодом, но и открытым дизайном железа, что бы каждый мог сделать замену любого модуля. IMHO

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