VslavX 0 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба А че он самый быстрый то? С чем сравнивалось? У мя тоже есть свой стек :rolleyes: правда в LPC я не силен :) Но есть SAM7X... Как нить измерю сантиметры А вот я, кстати, не отказался бы померяться сантиметрами :) Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) и выложу тут исходники? Авторы стеков напишут ответку на своих платформах и сразу будет видно - у кого скока см МБ/сек. Или может готовое приложение есть? Я смотрел на ntttcp, но MS деталей этого теста, увы, не раскрывает. PS. Если просто по TCP слать в discard, то мой стек на LPC17@100 дает чуть более 4Мбайт/сек, но хотелось бы таки более осмысленного теста. PPS. exe-шники для at200 и getdata, имхо, в архиве лишние, а вот исходники embpack - не помешали бы, ну и библиотек (типа cc3260.dll) к нему не хватает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) Я не знаю, что там обсуждать. Я просто в своей тестовой софтине принимаю из сокета и пишу в файл (ибо на самом деле моя тестовая софтина для получения данных с АЦП была). Сто метров с замером времени - вполне адекватный тест. Следующая серия тестов - накатываем dummy net, втыкаем очередь-задержку (можно небольшую, пара миллисекунд вполне для отсева пионерских поделок) и наслаждаемся :) а вот исходники embpack - не помешали бы, ну и библиотек (типа cc3260.dll) к нему не хватает. Положу, пардон, совсем забыл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prottoss 0 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Так - поднял свой пыльный стек :) Теперь пытаюсь вникнуть в приложение на билдере. Сразу скажу, что сетевые приложения под Win32 не программировал, по этому туго. Чего там оно просит? if ((he=gethostbyname("nikee_cm3.tst"))==NULL) { ShowMessage("Error: gethostbyname failed!"); return; } Можно на пальцах? Другим тоже, думаю, интересно будет. Сокет, я так понимаю, сервером открывать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Чего там оно просит? В windows/drivers/etc/hosts добавьте запись nikee_cm3.tst с нужным Вам IP-адресом. Да, сокет на младшем брате должен быть серверный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 23 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба А вот я, кстати, не отказался бы померяться сантиметрами :) Может быть, обсудим методику тестирования производительности TCP и я напишу ответное тестовое приложение (под Win32) и выложу тут исходники? Авторы стеков напишут ответку на своих платформах и сразу будет видно - у кого скока см МБ/сек. Можно, например, Ethereal'ом протестировать.. Но для полноты картины хорошо бы три-четыре сокета открыть: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Можно, например, 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 23 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Я вот жду LPC18xx - у него EMAC продвинутый, IP/TCP суммы умеет аппаратно считать... Да ладно, не переживайте.. TCP уже не модно: Cisco to cut 6,500 jobs, sell plant. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Я вот жду LPC18xx - у него EMAC продвинутый, IP/TCP суммы умеет аппаратно считать, под это дело буду также учится делать отправку данных без копирования - по ссылке. Однако я обхожусь без сей аппаратной приблуды. А скорость в два раза выше ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Можно, например, Ethereal'ом протестировать.. Но для полноты картины хорошо бы три-четыре сокета открыть: Только еще бы выделить чистый траффик по полезной нагрузке, ибо как-то в общую сумму складывать ACK'и и вообще служебную ересь нехорошо. Банальное чтение данных из сокета на большом брате и измерение времени - самое то. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Однако я обхожусь без сей аппаратной приблуды. А скорость в два раза выше ;) Ну, допустим, не в два, а чуть больше чем в полтора ;). А сейчас я поигрался конфигурацией, отключил отладку - и получилось чуть более 70Мбит/сек - 16Мбайт ушло за 1910 мс. При этом потребовалось 31К кода и 16К оперативки. Так что спорить что Ваш стек самый быстрый и маленький - не буду :). Вопрос такой - я правильно понял, что источник данных кладет данные прямо в сетевой буфер эзернета в колбек-процедуре. А если требуется повторная отправка, то вызывается событие REGENERATE? Тогда получается что приложение должно само решать вопросы хранения данных у себя до подтверждения их получения удаленной стороной со стороны TCP. То есть - в-общем случае, стек буферов данных у себя не имеет, а просто сваливает проблему на приложение, отсюда и расход памяти собственно в стеке маленький. Да ладно, не переживайте.. Да я не переживаю ;). Rst7, конечно, выкатил свой очередной шедевр, но он как болид F1 - ездит быстро, но это машинка не на каждый день чтобы на работу добираться. TCP уже не модно: Cisco to cut 6,500 jobs, sell plant. Ага, Циска от непрофильного ширпотребного производства избавляется и собирается как раз на "немодном TCP" сосредоточиться (на сетевом оборудовании). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 27 июля, 2011 Опубликовано 27 июля, 2011 · Жалоба Ну, допустим, не в два, а чуть больше чем в полтора Имеем заявленные мной 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 28 июля, 2011 Опубликовано 28 июля, 2011 · Жалоба Ну вот теперь, собственно, за скорость. По TCP - 90Мбит/с. Неплохо, у нас тут народ пилил что-то опенсорсное, так выше 68Мбит/c забраться не удалось. Про размеры кода вообще молчу :). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 23 28 июля, 2011 Опубликовано 28 июля, 2011 (изменено) · Жалоба Только еще бы выделить чистый траффик по полезной нагрузке, ибо как-то в общую сумму складывать ACK'и и вообще служебную ересь нехорошо. Их никто и не складывает. Данные идут в одном направлении, а ACK'и - в другом. Измерение скорости в Ethereal'е нужно начинать уже после того как на PC запущено тестовое приложение и созданы сокеты. Это исключает "служебную ересь", связанную с открытием сокетов. Изменено 28 июля, 2011 пользователем blackfin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewlekar 0 28 июля, 2011 Опубликовано 28 июля, 2011 · Жалоба А что, собственно стек не интересен? Не особо. Мне только обработка прерывания EMAC интересна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VslavX 0 28 июля, 2011 Опубликовано 28 июля, 2011 · Жалоба Имеем заявленные мной 90мбит/с = 11Мбайт/с (примерно). А Вы заявляли о 5.8Мбайт/с. 11/5.8=1.9. "Маша - это Маша, а два раза - это два раза" (ЦЭ) Сейчас Маша осталась Машей (с внутристековой буферизацией), но при этом 70Мбит/с . А теперь предлагаю вставить dummy net с задержкой пакетов на 2-3мс Хотите сказать что у Вас скорость не упадет? В случае генерации псевдослучайных данных - вполне может быть, и неудивительно - тут буфера нет. А вот если передавать что-то осмысленно-реальное, то буфер все равно появится - в приложении. И как только емкость канала превысит размер этого буфера - скорость упадет как миленькая. Пример - передача файла с MMC карточки. Можно читать данные с карты в колбеке - но это некамильфо, операция долгая, мало того что делать прийдется ее в прерывании, так еще и все другие сокеты встанут, приемный буфер сети переполнится (flow control нуна доделывать ;)) и так далее. Поэтому буферизация тут будет нужна без вариантов. Да, и смысл в этом самый глубокий. Незачем навешивать лишних буферов. Само приложение куда лучше стека знает, как работать с генератором тех данных, которые будут передаваться в сокет. Да, это усложняет написание кода, но увеличивает быстродействие. Смотря какое приложение. Если относительно простое - то такой подход справляется. А если приложение относительно сложное - то ну его нафиг - добавлять в него еше тисипишные заморочки типа "ну не шмогла, давай повторим". А если надо наложить поверх такого TCP другой протокол со своими фреймами, типа PPTP или iSCSI, то без буферизации тут вешалка. В-общем, реализация на колбеках любопытная, но вся работа по буферизации свалена на приложение. Если буферизация приложению не нужна - все выглядит интересно, но если приложение делает хоть шаг в сторону, то "вечер перестает быть томным" ©. Режим работы TCP с колбеками несложно добавить и в мой стек, сижу вот думаю, что оно реально может дать на моих задачах - пока выгода неочевидна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться