DataModel over TCP/IP

writeData

виноват, хотел сказать write

Жор ядра на 100%, забита треть стомегабитного канала.

т.е. проц занят был на 100%, а канал только на треть, при этом буст канал полностью обслужил ?

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

Я привел пример с UDP-флудом, потому что проблема вставала на практике, коллеги написали флудер для тестирования железки, который работал очень медленно. Гениальный техдир, помешанный на FPGA, тогда смаху решил, что современные CPU не умеют использовать весь потенциал Ethernet-сетей и чуть было не начал проект аппаратной флудилки :) И это тоже оффтоп.

PS. Я сходу не понял как write-ом писать в QUdpSocket.

PS. Я сходу не понял как write-ом писать в QUdpSocket.

не придирайся к словам (да тут writeDatagram)

и все же без приведения кода утверждение, что qt гавно, не есть показатель грамотности специалиста

не придирайся к словам

Я не придираюсь, а пытаюсь понять какой из write-ов ты имеешь в виду. Ок, writeDatagram.

и все же без приведения кода утверждение, что qt гавно, не есть показатель грамотности специалиста

Qt не говно, сетка в нем говно. Пробуй раскочегарить:

#include<QUdpSocket>

int main(){
 QUdpSocket socket;
 QHostAddress addr("192.168.137.4");
 for(;;)
  socket.writeDatagram("Hello",6,addr,1234);
 return 0;}

Пробуй раскочегарить:

попробую, отпишусь по готовности

Отпишитесь в паблик, плз.

Я не писал что возможность отпадает, я писал про прозрачную возможность имея ввиду датастрим. (Что стандарт вроде для куте сериализации). Возможность не отпадает, но танцы с бубнами останутся.

итак: локалка, между хостами 2 хаба (типа dlink), 100 мбит; на приеме:

на размере полезных данных 6 байт - по скорости примерно одинаково: ~22000 kbs/ 45000 pps (cpu 13% у сокетов, у qt 100%)
скорость в iptraf, сильно скачет - от 16000 до 22000 (иногда 23000,24000)

на размере полезных данных 600 байт - по скорости также примерно одинаково: ~96400 kbs/ 18770 pps (cpu 13% у сокетов, у qt 100%)
скорость в iptraf, стоит _стабильно_

т.е. упираемся в pps на мелком пакете

надо в отдельный поток у qt переделать

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

В потоке sendto уменьшил потребление до 2-3%, QUdpSocket пока не поддается (надо покопаться в исходниках более плотно)

Если продолжишь ковыряться и найдешь что-то, скастуй меня пожалуйста.

qt создает неблокирующий сокет, перевел в блокирующей - стали аналогично работать оба способа

Но сам по себе неблокирующий сокет AFAIK тормозить не должен. Или должен?

блокирующий спит в ядре, когда не может отправить
неблокирующий постоянно возврат делает с кодом ошибки EAGAIN, а тут мы его циклом

Понятно, в случае полного забивания канала, логично - не спим, а долбим цикл. На каком CPU ты тестировал? У меня на работе Core2 Duo, что-то в районе 2Ггц, и канал забивается только на треть, от силы на половину.

i7-2600, забито было одно ядро