Есть несколько устройств (6..8 шт.) сбора данных , которые формируют и отсылают удновременно IP пакеты на линке 100Мбит/с. Канал передачи от каждого устройства загружен на 80..90 %.

Далее я планирую поставить гигобитный свич и подключить к нему все эти устройства. С другой же стороны свича будет стоять ПК. Линк между ПК и свичем 1 Гбит/с.


Вопрос следующий. Все ли пакеты будут доходить от устройства к ПК ? Если да , то с любым ли свичем такое возможно ?

А вы уверены, что Ваш ПК будет успевать обрабатывать такое количество информации?

Конечно нет. Потому что каналов без ошибок не бывает.

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

Сам сформулировал, сам и отвечаю Не будет, если ПК будет успевать обрабатывать входящие пакеты.

Приветствую!
Присоединюсь к DuHast. В действительности задача регистрации информации на ПК со скоростью 500-600 Мбит/с это уже вопрос, не говоря уже об обработке, тем более если есть задача в режиме реального времени.
Теперь на счет свича. Врать не буду, поэтому название не скажу, но точно знаю, что китайское производство способно делать относительно недорогие свичи с производительностью более 2-х Гбит/с. Видел что-то подобное в Российской компании MLink. Так что свич подобрать можно, а вот с программой для обработки информации придется попыхтеть
Моя железка с гигабитным портом (Rst в курсе ) работает с ошибками, а вот простой Asus switch у меня работает без ошибок Так что в теории BER 10е-13 возможно, а на практике бывает лучше.
Удачи!

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

Спасибо за ответы. Вопрос решен.



Согласен. Так более правильно ставить вопрос.



Да замучался я это обьяснять начальству и программерам. У них слишком бурная фантазия относительно современных ЭВМ.
Иду по пути наименьшего сопротивления Пусть пробуют захватит, посмотрим.

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

В подобных случаях частеньку вспоминаю идеи врачей и физиологов, с которыми приходилось работать в 80-х годах:"Давайте мы все сигналы, какие можем с человека снять, в компьютер загоним, а он нам диагноз пациенту поставит!". Пока, как видите, не поставил.

Вопрос всегда один, что вы собираетесь с этой лавиной информации делать?

Задачи перехвата зашифрованных потоков данных. Дешифрация небыстрое дело, его потом производят не в реальном времени. Что касается, успеет ли ПК, то для накопления данных используют не ПК а довольно мощные сервера.



Вопрос затрагивает профессиональную тайну.

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

Если это свои данные, то смысл лить их таким потоком, чтобы не успевать расшифровывать? Или так принято, месяц копим, год расшифровываем?


Я конечно знаю области, в которых такой подход имеет право на существование, например, LHC (а под расшифровкой имеется в виду математическая обработка raw-данных с детекторов). Но, что-то мне подсказывает, что тут врядли разработчики детекторов с Церна тусуются

Да , Вы правы, Нестабильные частицы , нас мало интересуют.

Впринципе верно догадались. Мы слушаем и анализируем КВ диапазон. Причем анализ проводим не в реальном времени. Дешифрованием и криптографией не занимаемся. Только анализ.

Раз зашел в эту степь разговор, то может кто посоветует кодек для сжатия подобного типа raw-данных ? Мне к сожалению такой не известен.



Да, пока еще, к сожалению, смешная идея.

Смотря по тому, какие данные и как происходит дальше анализ.

Это я к тому, что неправильным кодеком можно нужную информацию зарезать...

Пытались как-то найти консенсус, да так всё и бросили: Быстрое сжатие без потерь, реализация в FPGA

Определенно кодек нужен без потерь.
Блин для НЧ же есть такие кодеки, обезьяна например та же.


Пасиб, почитаю.

Попробуйте Ваш поток банально пожать zlib-ом.

Хотя, опять же, не зная конкретные параметры исходных данных потока, трудно что-то предложить.

Спасибо, Rst7 . Пробывали rar жать на ПК . Несжимаемый зараза.


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


Спасибо за советы, вопросов больше не имею.

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