[VslavX 0]

А че он самый быстрый то? С чем сравнивалось?

У мя тоже есть свой стек :rolleyes: правда в LPC я не силен :) Но есть SAM7X... Как нить измерю сантиметры

А вот я, кстати, не отказался бы померяться сантиметрами :)

Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) и выложу тут исходники? Авторы стеков напишут ответку на своих платформах и сразу будет видно - у кого скока см МБ/сек. Или может готовое приложение есть? Я смотрел на ntttcp, но MS деталей этого теста, увы, не раскрывает.

PS. Если просто по TCP слать в discard, то мой стек на LPC17@100 дает чуть более 4Мбайт/сек, но хотелось бы таки более осмысленного теста.

PPS. exe-шники для at200 и getdata, имхо, в архиве лишние, а вот исходники embpack - не помешали бы, ну и библиотек (типа cc3260.dll) к нему не хватает.

[Rst7 5]

Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32)

 

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

 

а вот исходники embpack - не помешали бы, ну и библиотек (типа cc3260.dll) к нему не хватает.

 

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

[prottoss 0]

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

 

if ((he=gethostbyname("nikee_cm3.tst"))==NULL)
        {
                ShowMessage("Error: gethostbyname failed!");
                return;
        }

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

Сокет, я так понимаю, сервером открывать?

[Rst7 5]

Чего там оно просит?

 

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

 

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

[blackfin 31]

А вот я, кстати, не отказался бы померяться сантиметрами :)

Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) и выложу тут исходники? Авторы стеков напишут ответку на своих платформах и сразу будет видно - у кого скока см МБ/сек.

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

 

Но для полноты картины хорошо бы три-четыре сокета открыть:

 

[VslavX 0]

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

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

 

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

 

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

 

[blackfin 31]

Я вот жду LPC18xx - у него EMAC продвинутый, IP/TCP суммы умеет аппаратно считать...

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

 

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

[Rst7 5]

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

 

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

[Rst7 5]

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

 

Но для полноты картины хорошо бы три-четыре сокета открыть:

 

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

[VslavX 0]

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

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

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

 

 

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

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

 

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

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

[Rst7 5]

Ну, допустим, не в два, а чуть больше чем в полтора

 

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

 

А сейчас я поигрался конфигурацией, отключил отладку - и получилось чуть более 70Мбит/сек - 16Мбайт ушло за 1910 мс.

 

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

 

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

 

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

 

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

У меня в стеке есть три callback'а для режима передачи

 

SEND - сгенерить новых данных для передачи (не более стольки-то) и вернуть количество сгенеренных данных.

REGENERATE - откатиться на точку последнего подтверждения

ACK - переместить точку последнего подтверждения на сколько-то байт.

 

char *out;
char *ack;

SEND(p,max)
{
   len=max;
   memcpy(p,out,len);
   out+=len;
   return len;
}

REGENERATE(p,max)
{
   len=max;
   memcpy(p,ack,len);
   out=ack;
   return len;
}

ACK(len)
{
   ack+=len;
}

 

В начале out и ack указывают на начало буфера передачи.

 

На самом деле в реальности там нет memcpy. Это псевдокод для иллюстрации. На самом деле там какой-то циклический буфер, или железка, или еще чего - например, http-сервер в виде машины состояний, который непосредственно печатает в p, а ack и out для него - не более чем состояние.

[halfdoom 0]

Ну вот теперь, собственно, за скорость. По TCP - 90Мбит/с.

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

[blackfin 31]

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

Их никто и не складывает. Данные идут в одном направлении, а ACK'и - в другом.

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

Изменено 28 июля, 2011 пользователем blackfin

[andrewlekar 0]

А что, собственно стек не интересен?

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

[VslavX 0]

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

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

 

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

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

 

Да, и смысл в этом самый глубокий. Незачем навешивать лишних буферов.

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

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

 

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