А вот я, кстати, не отказался бы померяться сантиметрами
Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) и выложу тут исходники? Авторы стеков напишут ответку на своих платформах и сразу будет видно - у кого скока см МБ/сек. Или может готовое приложение есть? Я смотрел на ntttcp, но MS деталей этого теста, увы, не раскрывает.
PS. Если просто по TCP слать в discard, то мой стек на LPC17@100 дает чуть более 4Мбайт/сек, но хотелось бы таки более осмысленного теста.
PPS. exe-шники для at200 и getdata, имхо, в архиве лишние, а вот исходники embpack - не помешали бы, ну и библиотек (типа cc3260.dll) к нему не хватает.

Я не знаю, что там обсуждать. Я просто в своей тестовой софтине принимаю из сокета и пишу в файл (ибо на самом деле моя тестовая софтина для получения данных с АЦП была). Сто метров с замером времени - вполне адекватный тест. Следующая серия тестов - накатываем dummy net, втыкаем очередь-задержку (можно небольшую, пара миллисекунд вполне для отсева пионерских поделок) и наслаждаемся



Положу, пардон, совсем забыл.

Так - поднял свой пыльный стек Теперь пытаюсь вникнуть в приложение на билдере. Сразу скажу, что сетевые приложения под Win32 не программировал, по этому туго. Чего там оно просит?


Можно на пальцах? Другим тоже, думаю, интересно будет.
Сокет, я так понимаю, сервером открывать?

В windows/drivers/etc/hosts добавьте запись nikee_cm3.tst с нужным Вам IP-адресом.

Да, сокет на младшем брате должен быть серверный.

Можно, например, Ethereal'ом протестировать..

Но для полноты картины хорошо бы три-четыре сокета открыть:
[attachment=59138:Ethereal.jpg]

Можно, но там нужно долго в цифры втыкать - например, смотрю - показывает что два пакета по 1460 байт принимаются с интервалом 7 мкс, хотя на скорости 100Мбпс это ну никак. Потом подумал - оно ж у меня в гигабитный свитч воткнуто, тот мог такое учудить, вполне... Не-а, даже на гигабите в 7 мкс не укладывается . У меня "продвинутый" свитч - он порт-мирроринг позволяет (только так можно помониторить свой девайс, например, к NAS-у подключенным), так на зеркальном порту тайминги вообще уезжают.

В-общем, со своего тестика тоже отряхнул пыль, прикрутил новый блочный режим TCP, который с тех времен появился, потестил - 5.8Мбайт/сек в дискард оно бросает. Анализ траффика показывает что банально недостаточные размеры буферов TCP-сокета в моем стеке не дают разогнаться (также реализован механизм предотвращения заторов, но он тут даже нормально накопить статистики не успевает ). Банально - кидаем 4К в буфер сокета TCP, оно отдает три пакета по 1460+1460+остаток и ждет ACK. Пока ACK нету - буфер полный, новые данные приложение в сокет не пишет - некуда, все стоит. Пришел ACK, буфер почистился - кидаем новые 4К данных, они тут же снова улетают - и опять ждем ACK. Вот так оно кусочками и дергается. Если выкинуть промежуточный свич (там он еще и на зеркальный порт кидает траффик) то пинг уменьшиться, и скорость еще может на пару-тройку процентов вырасти.

Надо сказать, что отправка данных по TCP у меня организована слегка неоптимально - есть копирование с одновременным подсчетом контрольной суммы TCP. Я вот жду LPC18xx - у него EMAC продвинутый, IP/TCP суммы умеет аппаратно считать, под это дело буду также учится делать отправку данных без копирования - по ссылке.

Да ладно, не переживайте..

TCP уже не модно: Cisco to cut 6,500 jobs, sell plant.

Однако я обхожусь без сей аппаратной приблуды. А скорость в два раза выше

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

Ну, допустим, не в два, а чуть больше чем в полтора . А сейчас я поигрался конфигурацией, отключил отладку - и получилось чуть более 70Мбит/сек - 16Мбайт ушло за 1910 мс. При этом потребовалось 31К кода и 16К оперативки. Так что спорить что Ваш стек самый быстрый и маленький - не буду .
Вопрос такой - я правильно понял, что источник данных кладет данные прямо в сетевой буфер эзернета в колбек-процедуре. А если требуется повторная отправка, то вызывается событие REGENERATE? Тогда получается что приложение должно само решать вопросы хранения данных у себя до подтверждения их получения удаленной стороной со стороны TCP. То есть - в-общем случае, стек буферов данных у себя не имеет, а просто сваливает проблему на приложение, отсюда и расход памяти собственно в стеке маленький.



Да я не переживаю . Rst7, конечно, выкатил свой очередной шедевр, но он как болид F1 - ездит быстро, но это машинка не на каждый день чтобы на работу добираться.


Ага, Циска от непрофильного ширпотребного производства избавляется и собирается как раз на "немодном TCP" сосредоточиться (на сетевом оборудовании).

Имеем заявленные мной 90мбит/с = 11Мбайт/с (примерно). А Вы заявляли о 5.8Мбайт/с. 11/5.8=1.9. "Маша - это Маша, а два раза - это два раза" (ЦЭ)



А теперь предлагаю вставить dummy net с задержкой пакетов на 2-3мс



Да, и смысл в этом самый глубокий. Незачем навешивать лишних буферов. Само приложение куда лучше стека знает, как работать с генератором тех данных, которые будут передаваться в сокет. Да, это усложняет написание кода, но увеличивает быстродействие. И в общем зачете уменьшает количество требуемого ОЗУ.

Я уже как-то писал об этом, повторюсь:

Неплохо, у нас тут народ пилил что-то опенсорсное, так выше 68Мбит/c забраться не удалось. Про размеры кода вообще молчу .

Их никто и не складывает. Данные идут в одном направлении, а ACK'и - в другом.
Измерение скорости в Ethereal'е нужно начинать уже после того как на PC запущено тестовое приложение и созданы сокеты. Это исключает "служебную ересь", связанную с открытием сокетов.

Сообщение отредактировал blackfin - Jul 28 2011, 04:15

Не особо. Мне только обработка прерывания EMAC интересна.

Сейчас Маша осталась Машей (с внутристековой буферизацией), но при этом 70Мбит/с .


Хотите сказать что у Вас скорость не упадет? В случае генерации псевдослучайных данных - вполне может быть, и неудивительно - тут буфера нет. А вот если передавать что-то осмысленно-реальное, то буфер все равно появится - в приложении. И как только емкость канала превысит размер этого буфера - скорость упадет как миленькая. Пример - передача файла с MMC карточки. Можно читать данные с карты в колбеке - но это некамильфо, операция долгая, мало того что делать прийдется ее в прерывании, так еще и все другие сокеты встанут, приемный буфер сети переполнится (flow control нуна доделывать ) и так далее. Поэтому буферизация тут будет нужна без вариантов.


Смотря какое приложение. Если относительно простое - то такой подход справляется. А если приложение относительно сложное - то ну его нафиг - добавлять в него еше тисипишные заморочки типа "ну не шмогла, давай повторим". А если надо наложить поверх такого TCP другой протокол со своими фреймами, типа PPTP или iSCSI, то без буферизации тут вешалка.

В-общем, реализация на колбеках любопытная, но вся работа по буферизации свалена на приложение. Если буферизация приложению не нужна - все выглядит интересно, но если приложение делает хоть шаг в сторону, то "вечер перестает быть томным" ©. Режим работы TCP с колбеками несложно добавить и в мой стек, сижу вот думаю, что оно реально может дать на моих задачах - пока выгода неочевидна.