Как из дома управлять с латентностью <200 мс через интернет устройством на расстоянии 600 км и потоком данных 100 Мбит/с? Поделитесь опытом Опции

[bbb]

Как через интернет управлять устройством находящимся за 600 км, чтобы время передачи команд на объект было не более 100 мс и объект в ответ передавал данные со скоростью 100 Мбит/с?

Есть ли у кого опыт в создании таких распределенных систем управления?

Т.е. мне нужно, чтобы когда я посылаю команду на удаленный объект по интернету он уже через 0.1 сек получал её и начинал её выполнять. И наоборот. Когда объект что-то полсылает мне, чтобы я начинал получать это уже спустя 0.1 сек после начала передачи

При этом девайс, выполняющий команды, должен постоянно передавать мне данные со скоростью 100 Мбит в секунду (свое состояние и видеопоток с 10-ти камер).

Т.е. канал должен быть дуплексным.


В какую сторону "рыть"?
Где можно посмотреть готовые проекты такого плана?

Сообщение отредактировал bbb - Jan 30 2016, 20:22

[HardEgor]

Как через интернет управлять устройством находящимся за 600 км, чтобы время передачи команд на объект было не более 100 мс и объект в ответ передавал данные со скоростью 100 Мбит/с?

Идти к магистральным провайдерам типа Ростелеком, Транстелеком, еще у сотовых операторов есть такие каналы и покупать выделенный канал связи с гарантированной полосой и откликом.

[bbb]

А стандартных покупных решений моей задачи нет?
Ну типа покупаешь коробочку с CD-диском.
Коробочку (УСО) ставишь на объект управления.
С диска ставишь утилиту к себе на комп и управляй не хочу.

Не слышали о таком?

[Baser]

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

[mantech]

Т.е. мне нужно, чтобы когда я посылаю команду на удаленный объект по интернету он уже через 0.1 сек получал её и начинал её выполнять. И наоборот. Когда объект что-то полсылает мне, чтобы я начинал получать это уже спустя 0.1 сек после начала передачи


В какую сторону "рыть"?
Где можно посмотреть готовые проекты такого плана?

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

А решение - передача части "быстрых" функций своему устройству, а через инет только командовать...

Идти к магистральным провайдерам типа Ростелеком, Транстелеком, еще у сотовых операторов есть такие каналы и покупать выделенный канал связи с гарантированной полосой и откликом.

Так-то да, только ИМХО стоить все это будет столько, что на эти деньги проще жить в теплых странах и не париться этой ерундой

[smalcom]

и, обычно, выделенную линию не дают физлицу, только юридическому.

В какую сторону "рыть"?

только выделенный канал вам поможет.

Где можно посмотреть готовые проекты такого плана?

это как купить интернет - нигде.

[gerber]

Смотрите в сторону синхронных каналов, SDH/PDH и т. п.

[gte]

Т.е. мне нужно, чтобы когда я посылаю команду на удаленный объект по интернету он уже через 0.1 сек получал её и начинал её выполнять. И наоборот. Когда объект что-то полсылает мне, чтобы я начинал получать это уже спустя 0.1 сек после начала передачи

При этом девайс, выполняющий команды, должен постоянно передавать мне данные со скоростью 100 Мбит в секунду (свое состояние и видеопоток с 10-ти камер).

Управление сделать по радиоканалу, а обратный канал через интернет.

[syoma]

Конечно 100мс удаленно - это круто. А что это за заздача это требует, можете сказать?

А собственно по решению - может VoIP - ну или телефон обыкновенный?

[twix]

Сейчас выяснится, что ему в танчики надо играть без задержек, а в деревне интернет не очень качественный..

[bbb]

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

У меня когда-то лет 10 назад была программа которой показывала пинг до различных городов. И он вполне себе был менее 0.1 сек

[gerber]

У меня когда-то лет 10 назад была программа которой показывала пинг до различных городов. И он вполне себе был менее 0.1 сек

Дык в те времена и Ускоритель Интернета продавался на каждом углу.

[Огурцов]

в танчики

т34, в натуральную величину ?

[smalcom]

У меня когда-то лет 10 назад была программа которой показывала пинг до различных городов. И он вполне себе был менее 0.1 сек

speedtest.net
tracert
traceroute
ping

PING moscow.ru (185.15.172.69): 56 data bytes
64 bytes from 185.15.172.69: icmp_seq=0 ttl=55 time=30,027 ms

------------------------------------
о-о-о, опять святая уверенность: "смотрите, я обманул природу". обычно очень плохо заканчивается.
вы понимаете разницу между:
1. "чуваак, не пропусти, до 100 Мбит за 2, да, разгильдяй городской, ты не ослышался - всего за два кредита в месяц... Та-дааа";
2. 24/7 64 кбит/с ?

Вероятно из-за пункта 1 и выбран предел скорости 100 МБит/с

[bbb]

smalcom
Не понял. Что Вы хотели сказать-то?
*****************
Уточню немного.
Для обратного 100 мегабитного потока видео не критично если будет небольшой джиттер задержки (0,1...0,5 сек)
А вот для обратного дампа состояния устройства желательно чтобы он доставлялся за 100мс.


В принципе система будет работать даже при Latency Time 0.5 сек. Но хотелось бы чтобы сигнал "туда и обратно" успевал "добежать" за 0.2 сек


В принципе, катастрофы не произойдет даже если команда или "обратная связь" будут "гулять по сети" 40 секунд.

Просто девайс в этом случае перейдет на дефольный алгоритм работы "нет связи с хостом".

И просто тогда про "real-time управление" будет уже нельзя говорить.

[gte]

И просто тогда про "real-time управление" будет уже нельзя говорить.

Обычный ethernet не используется для "real-time" даже в пределах цеха.

[Огурцов]

значит нужно сделать необычный

[Corvus]

Так сделали уже EtherCAT и иже с ним.

[bbb]

Мне нужно использовать WAN

[syoma]

Обычный ethernet не используется для "real-time" даже в пределах цеха.

Ну чего не используется. Уже используется. Продвинутые "цифровые" подстанции на МЭК 61850 используют Ethernet в полный рост. А протокол GOOSE как раз используется системами защиты и автоматики для посылки команд на аварийное отключение контакторов и разрыв цепей. И задержки там гораздо меньше 100мс.
Но не думаю, что ТС устроит цена данного решения.

[zltigo]

Но не думаю, что ТС устроит цена данного решения.

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

[Огурцов]

Но не думаю, что ТС устроит цена данного решения.

доллар..два ?

[bbb]

Обычный ethernet не используется для "real-time" даже в пределах цеха.

Вы жутко отстали от жизни.

Уже лет 10 как как в цеховых АСУТП в полный рост правят не просто системы жесткого реального времени. А ЧУДОВИЩНОЙ ЖЕСТКОСТИ системы реального времени на базе EtherCAT, SERCOS, PowerLink и т.п.

Когда время проверки отсутсвия "Failure" одного блока занимает наносекунды.

[gte]

Уже лет 10 как как в цеховых АСУТП в полный рост правят не просто системы жесткого реального времени. А ЧУДОВИЩНОЙ ЖЕСТКОСТИ системы реального времени на базе EtherCAT, SERCOS, PowerLink и т.п.

Внимательно читайте то, что я написал.
То о чем Вы написали это не просто Ethernet, а специально модифицированный для промышленного применения.
Почитайте условия применения EtherCAT, SERCOS, PowerLink и т.п. и напишите какой из них применим для Вас при условии, что Вы не будете "копать канаву до объекта".

[zltigo]

Когда время проверки отсутсвия "Failure" одного блока занимает наносекунды.

Феерически! Наносекунды. А как быть с тем печальным фактом, что только задержка в витой паре на уровне 30 наносекунд на метр. Какие-то совсем уж карманного размера системы АСУТП у Вас . Идем дальше. Начинаем учитывать скорость передачи. В Ethernet бегают фреймы имеющие не нулевой размер, посему еще появляется задержка равная отношению размера фрейма к скорости передачи, что уже совсем никак не сотносится со словом "наносекунды". Это я пока про чисто физические ограничения говорю и не затрагиваю вопрос времени обработки информации.
Осетра урежьте ©

[bbb]

Я имел в виду, что слЭйф формирует ответ за наосекунды в суммарном фрейме

И как не крути за 30 мкс опросить 1000 девайсов....
Ещё лет 10 назад это казалось несбыточной фантастикой

[smalcom]

smalcom
Не понял. Что Вы хотели сказать-то?

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

[bbb]

А есть ли какие либо эволюшн платы, KiT-ы и т.п. по указанной в заголовке тематике?

[smalcom]

есть, конечно.
недорого, для начинающих: http://server-unit.ru/catalog/servery/serv...alnogo-urovnya/
это по желанию, в зависимости от абонентской линии http://gsc.com.ua/xdsl-koncentratory/adsl-shdsl-dslam/

[zltigo]

И как не крути за 30 мкс опросить 1000 девайсов....
Ещё лет 10 назад это казалось несбыточной фантастикой

Как и сейчас в сколь-нибудь реальных условиях, а не иделистических их рекламных проспектов.

[dimka76]

А если так.
Есть некий сайт. На нем HTML страница и какой-то текстовый файл. Страница по кнопке пользователя, размещенной на этой странице, записывает команду в файл. Управляемое устройство непрерывно читает этот файл и как только обнаруживает в нем команду исполняет ее.

[smalcom]

так будет работать. и даже очень быстро. тем быстрее, чем быстрее видеокарта. ведь именно она рисует кнопку.

[Quasar]

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

Вам выше smalcom показал задержку в 30,027 ms, я сейчас в Москве и мои железки в Новосибе имеют пинг порядка 60 мс, но это же все нестабильно. Сегодня 60 мс, а завтра 600 мс. Короче, как у радиолюбителей, все будет зависеть от текущего прохождения, что бы иметь гарантированные параметры идите в Ростелеком и арендуйте канал с гарантированными параметрами предоставления услуг связи.

[bbb]

Вам выше smalcom показал задержку в 30,027 ms, я сейчас в Москве и мои железки в Новосибе имеют пинг порядка 60 мс, но это же все нестабильно. Сегодня 60 мс, а завтра 600 мс. Короче, как у радиолюбителей, все будет зависеть от текущего прохождения, что бы иметь гарантированные параметры идите в Ростелеком и арендуйте канал с гарантированными параметрами предоставления услуг связи.

Ну и ладно. Я уже писал выше. Что в девайсе будет предусмотрен режим "нет связи с хостом". Вопрос теперь один: где купить готовый KiT: железяку (удаленное УСО) с диском, на котором записана утилита управления этим УСО с моего компа через инет

[Студент заборстр...]

На прохождение 600 км "туда и обратно" свет тратит примерно 4 мс.
Так что, в принципе, это возможно

[Aner]

На прохождение 600 км "туда и обратно" свет тратит примерно 4 мс.
Так что, в принципе, это возможно

Пока в фантастических романах, в прямом луче; так как "туда и обратно" свет "тормозится" в среде распространения, включая обработчики.

[Студент заборстр...]

свет "тормозится" в среде распространения

В воздухе? На доли процента

[Aner]

В воздухе? На доли процента

Какой еще воздух? Как это на 600Км? И чем?
По оптике с переходом на медь и так нескоько раз к 40...60мс и придёте, в лучшем случа, на некоторое время в имеющемся интернете

[mantech]

В воздухе? На доли процента

Ну дак и тяните свою оптику на 600км, в чем проблема? Тогда все задержки будут только на распространение света в волокне, переходные процессы в репитерах, а их будет немало и все!

[Студент заборстр...]

переходные процессы в репитерах, а их будет немало и все!

Ошибаетесь