Всем привет.

Стоит вопрос выбора промышленного компа с минимальными техническими характеристиками (для минимального энергопотребления) необходимыми для получения сетевого потока 300мбит/сек, буферизации и записи на диск.

Есть реализация ПО, "прототип", который на стареньком i5 650 легко хавает и 600мбит/сек, но как это поведет себя на атоме или селероне - большой вопрос.

Кто-нибудь сталкивался с подобным? На вскидку, какая мощность процессора для этого нужна?
Можно ли здесь применить какую-то "формулу"?
Хватит ли для такой задачи одного из Intel atom? или минимум мобильная серия i3?

Leonid Kudryavtsev,
Диск - SSD подключенный по USB 3.0, отличный от системного.
300мбит/сек - это 37мбайт/сек, если писать в один поток (что реализовано в софте), то это плевое дело и для USB2.0

Эх... притащил коллега из дома старенький 330й atom, неттоп, 2 ядра, 4 потока
при получении UDP в один поток, начинают пакеты не доходить после скорости 23мбит/сек
2 потока - 45мбит/сек (~23мбит/сек на поток)
3 потока - 65мбит/сек (~22 на поток)
4 потока - 87мбит/сек (~22 на поток)
5 потоков и далее - хуже оба показателя
в общем по тестам далее, надежно ловит не более 22мбит/сек на поток, или суммарно не более 85мбит/сек, при этом проц грузится в среднем на 55%.

можно конечно пинять, на что ОС Windows 7, среда .NET, но что-то мне подсказывает что переписывание на Linux и С больше 15..20% профита не даст.

оптимизировать уже некуда, профайлер показывает 93% на системную функцию Recieve
только если есть какой-то способ получать не пакетами а пачками пакетов (

похоже таки процессор важен (
и надо пробовать i3

alexeyvgНа это может ответить только программист этой проги.
Но неизвестная прога для неизвестно какой обработки потока в 300 мбит/сек может требовать неизвестно каких ресурсов.
Может, там на каждый принятый байт создаются классы, выделяется память менеджером, вызываются сборщики мусора и т.д.? :-)

Я как программист этой проги, могу сказать что кроме буферизации ни какой обработки там нет. И даже если выключить буферизацию и запись на диск - те же самые проблемы с потерей UDP пакетов на сокете.

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

alexeyvg...на каждый принятый байт создаются классы... И вообще, тут известная штука - нужно посчитать, что дешевле, нанять нормального программиста или купить i7 вместо Atom-а
ну вот так и есть, на каждый байт - 4 класса. сейчас считаем, то ли взять комп мощнее, то ли мне увольняться Х)

ТиФорсмой современный чайнафон за $50 работает шустрее
Добавлю... а вы присядьте, и гляньте цены на "промышленные компьютеры", и стоимость флеш дисков предназначенных для работы от -20°С. Я вот тоже думаю, какого черта? за что такие бабки? даже в 5-ти летнем смарфоне больше мощностей чем у компа кириосити. Почему на смартфонах не добавят пару гигабитных сетевых разъемов, не выведут на корпус всяких RS232, и желательно чтоб все разъемы были выведены в в rugged исполнении. Да, и чтоб чанафон запускался смело в -20°С. Ну и чтоб... годика два работал "наверняка".
И чтоб не один Rugged ethernet разъем стоил 50 баксов, а весь комп )))

ТиФорсих даже НАСА использует для управления спутниками.
Да да, именно спутниками!!! знаю, известная тема в НАСА, у всех стоит на смартфонах!!! )))))

miksoftКифирчик,
А пакеты какого размера используются?
256 пакетов по 4 байта и один размером 1 КБайт - сильно разные вещи.
пакеты чуток меньше MTU
по вопросам программирования меня здесь воспитывают ))) присоединяйтесь )

Как я понимаю, на больших потоках потери UDP не избежать.
Оптимизацией удалось снизить потери пакетов до ~15% на 175мбит/сек (на атоме).

Подозреваю чтоб наверняка понять нужно переходить на TCP и копать исходники протокола NFS.

miksoftКифирчиккопать исходники протокола NFS.Если вы можете использовать NFS, так, может, на него и перейти?

У нас как-то была попытка теста 10-гигабитного интерфейса. При закачке файлов по NFS при фактическом потоке 5 Гбит/с средненький i3 напрягался не так чтобы сильно и, по ощущениям, вытянул бы все 10 гигабит. А вам нужно в 15 раз меньше.

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

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

В другой ветке форма, мне накидали тесты на максимальную скорость для UDP и TCP протокола, результаты на картинке.
Среднее по трем замерам. Размер отправляемого пакета - 1024 байт.
Компы стоят рядом соедены через гигабитный свитч.
Еще можно добавить, что самый свежий атом E3815 (одно ядро), который быстрее чем 330й, на UDP тесте был загружен на 100%, 330й-менее 30%.

Тесты максимально простые, задействованы только функции приема пакетов.

По поводу NAS пообщался с коллегами...
есть гипотеза, что в NAS ставятся "нормальные" сетевые контроллеры, на плате, которые берут на себя заметную часть обработки пакетов, а если сетевуха встроенная - то от части используется процессор. И на слабых компах это может быть очень заметно.
Утвреждают что нормальная PCI-E сетвуха от Intel очень заметно разгружает процесор в системах где гоняется много сетевого трафика. То есть во многом рулит сетевой контроллер.

Также есть подозрение, что NFS (который юзается при копировании файлов по сети), может использовать какие-то хитрые функции ОС/железа перекладывая данные на диск с высокой скоростью минуя процессор.

Еще, есть сомнения, что те кто будет в итоге писать программу, будут искать и использовать "технологии" NFS, и будут как в этих функциях работать с TCP сокетом и буферизацией в памяти. То есть для таких технологий, производительность на приведенном железе можно считать потолком, и для этой задачи (получение 300мбит/сек) нужна платформа на базе не менее чем i3 5хххU, а лучше i5 5xxxU