QUOTE
Надо зарытую собаку искать, поэтому тут не тока спортивный интерес с моей стороны.
Ну когда найдете, то будем считать, что публикация моего стека Вам тоже пригодилась, хоть и опосредованным способом
Полная версия этой страницы: Самый быстрый и самый маленький TCP-стек.
Ну когда найдете, то будем считать, что публикация моего стека Вам тоже пригодилась, хоть и опосредованным способом
Цитата(Rst7 @ Jul 30 2011, 18:50) 
Ну когда найдете, то будем считать, что публикация моего стека Вам тоже пригодилась, хоть и опосредованным способом
Да она в любом случае пригодилась (и не только мне) - всегда приятно на такое посмотреть, ну и пообщаться по-поводу
Прекращаете троллить Rst7 - он же не написал что его стек мегабыстрый, мегауниверсальный и вообще лучше всех. Посмотрите стартовое сообщение.
QUOTE
При приеме я сталкивался с реализациями TCP где FR реализован весьма своеобразно - например в QNAP NAS (на базе линуха). Вот он фигачит поток на все окно, невзирая на то как там приходят ACK-и, есссно, пакеты начинают "по дороге" пропадать (не всякий свич спокойно пропускает 125Мбайт/сек), и если не реализован SACK, то наступает зопа.
Кстати, еще раз о FR. Вообще-то в линухах он вполне адекватно работает. А можете лог wireshark'а от такой сессии состряпать?
QUOTE
Прекращаете троллить Rst7 - он же не написал что его стек мегабыстрый, мегауниверсальный и вообще лучше всех.
Толсто
Плохой у нас из админа форума тролль 
Я, правда, тоже долго название топика выбирал, дабы вызвать побольше флуда. Но вышло вполне конструктивное обсуждение
Цитата(Rst7 @ Jul 30 2011, 19:10)
Кстати, еще раз о FR. Вообще-то в линухах он вполне адекватно работает. А можете лог wireshark'а от такой сессии состряпать?
Могу, но чуть позже - той платы под рукой нету. И оно большое - там гигабитный поток на пару секунд - под гигабайт лог, и, надо сказать, не очень адекватный, через Port-Mirroring (потому как прямой линк девайс-NAS - нету компа между ними) снималось - он немного пакеты тасует. Но факт такой - если его исходящий пакет пропадает, то невзирая на толпу ответных обычных ACK-ов с одинаковым ACKNO этот NAS сначала шлет все мегабайты что у него попросили по искази, а потом еще и виснет на 200мс с тайм-аутом. В итоге в потоке имеем простои под 200мс - неприятно. Вопрос открытый , все руки не доходят - работа с этим NAS-ом редкий случай, а с Windows оно нормально общается. Надо сказать, что QNAP все исходники выложил, и техподдержка нормальноая - если что, можно и их попинать.
QUOTE
Надо сказать, что QNAP все исходники выложил, и техподдержка нормальноая - если что, можно и их попинать.
Как Вам там хотели? "Покрутить лицо ногами"? Я думаю, самое оно именно так "попинать"
Цитата(Rst7 @ Jul 31 2011, 00:34)
Допилил свой стек до Release.В THUMB показывает в среднем на нескольких прогонах 10000 кбит/сек. Интересно, на сколько производительней кортекс, и конкретно STM32 по сравнению с ARM7 и конкретно AT91SAM7.
Сразу предупреждаю, что не хочу открывать вторую линию фронта по поводу атмелов, стм-ов, кортексов и арм-ов. Вопрос только к Rst7. Есть ли возможность потестить на AT91SAM7 Ваш стек. Я, честно, говоря, не сильно смотрел Ваше произведение - только одним глазком. И не сравнивал - своими мыслями голова забита.
Цитата(prottoss @ Jul 31 2011, 15:21)
...Есть ли возможность...
Наверное фигню сморозил - проще, может быть, портировать самому Ваш стек на свою платку 
Как нить возьмусь. Просто, ради интереса
QUOTE
Наверное фигню сморозил - проще, может быть, портировать самому Ваш стек на свою платку
Если мне не изменяет память, то там придется потрудиться, ибо в Atmel'овском EMAC'е по 128 байт кусочки пакетов. Но решаемо, в принципе, тоже без копирования.
Кроме того, рекомендую собирать в ARM-режиме, будет эффективнее. Единственный минус - довольно накладная процедура переворота байт в длинном слове, которая htonl/ntohl. Однако, ее необходимо инлайнить в любом случае, иначе будет плохо.
У меня, к сожалению, нет подходящей железки для порта. Кроме того, рекомендую подождать чуть-чуть, я таки сделаю вынос работы с железом и добавлю возможность отложенных обработок колбеков в менее приоритетных задачах.
Цитата(Rst7 @ Jul 31 2011, 16:58)
Если мне не изменяет память, то там придется потрудиться, ибо в Atmel'овском EMAC'е по 128 байт кусочки пакетов. Но решаемо, в принципе, тоже без копирования.
Не изменяемые кусочки тока на прием. На передачу можно размер буферов регулировать в некоторых пределах, хотя я не вижу смысла отказываться от размера в 128 байт на блок. Достаточно оптимально... Ой, наверное сейчас кто-то даст по шее...Цитата(Rst7 @ Jul 31 2011, 16:58)
Кроме того, рекомендую собирать в ARM-режиме, будет эффективнее. Единственный минус - довольно накладная процедура переворота байт в длинном слове, которая htonl/ntohl. Однако, ее необходимо инлайнить в любом случае, иначе будет плохо.
Интересно, но в ARM-режиме производительность немного ниже чем в THUMB.Для организации переворота
пользуюсь макросами Код
#define MAKEUINT16(byte_h, byte_l) ((UINT16)((((UINT16)(byte_h)) << 8)|(UINT16)(byte_l)))
#define HIBYTE(word) ((UINT8)(((UINT16)(word)) >> 8))
#define LOBYTE(word) ((UINT8)(word))
#define MAKEUINT32(word_h, word_l) ((UINT32)((((UINT32)(word_h)) << 16)|(UINT32)(word_l)))
#define HIWORD(dword) ((UINT16)(((UINT32)(dword)) >> 16))
#define LOWORD(dword) ((UINT16)(dword))
#define SWAP16(word) (MAKEUINT16(LOBYTE(word), HIBYTE(word)))
#define SWAP32(dword) (MAKEUINT32(SWAP16(LOWORD(dword)), SWAP16(HIWORD(dword))))
#define HIBYTE(word) ((UINT8)(((UINT16)(word)) >> 8))
#define LOBYTE(word) ((UINT8)(word))
#define MAKEUINT32(word_h, word_l) ((UINT32)((((UINT32)(word_h)) << 16)|(UINT32)(word_l)))
#define HIWORD(dword) ((UINT16)(((UINT32)(dword)) >> 16))
#define LOWORD(dword) ((UINT16)(dword))
#define SWAP16(word) (MAKEUINT16(LOBYTE(word), HIBYTE(word)))
#define SWAP32(dword) (MAKEUINT32(SWAP16(LOWORD(dword)), SWAP16(HIWORD(dword))))
Цитата(Rst7 @ Jul 31 2011, 16:58)
...рекомендую подождать чуть-чуть...
Да я и не спешу
QUOTE
Интересно, но в ARM-режиме производительность немного ниже чем в THUMB.
Я проверял, код намного более эффективный в данном случае.
QUOTE
Для организации переворота пользуюсь макросами
Есть намного более оптимальный проворот 32хбитного числа.
Цитата(Rst7 @ Jul 31 2011, 17:14)
Есть намного более оптимальный проворот 32хбитного числа.
Не сомневаюсь услышать это от Вас. Поделитесь секретной информацией?
QUOTE (prottoss @ Jul 31 2011, 13:17)
Не сомневаюсь услышать это от Вас. Поделитесь секретной информацией?
Например:
CODE
19 __arm ulong htonl( ulong n )
20 {
21 ulong t;
22
23 t = n ^ ( (n << 16) | (n >> 16) );
24 t &= ~0x00FF0000;
25 n = ( n << 24 )|( n >> 8 );
26 n ^= ( t >> 8 );
27
28 return( n );
\ htonl:
\ 00000000 601820E0 EOR R1,R0,R0, ROR #+16
\ 00000004 FF18C1E3 BIC R1,R1,#0xFF0000
\ 00000008 2114A0E1 LSR R1,R1,#+8
\ 0000000C 600421E0 EOR R0,R1,R0, ROR #+8
\ 00000010 0EF0A0E1 MOV PC,LR ;; return
29 }
20 {
21 ulong t;
22
23 t = n ^ ( (n << 16) | (n >> 16) );
24 t &= ~0x00FF0000;
25 n = ( n << 24 )|( n >> 8 );
26 n ^= ( t >> 8 );
27
28 return( n );
\ htonl:
\ 00000000 601820E0 EOR R1,R0,R0, ROR #+16
\ 00000004 FF18C1E3 BIC R1,R1,#0xFF0000
\ 00000008 2114A0E1 LSR R1,R1,#+8
\ 0000000C 600421E0 EOR R0,R1,R0, ROR #+8
\ 00000010 0EF0A0E1 MOV PC,LR ;; return
29 }
Заинлайнить само собой тоже можно.
QUOTE
Например:
Оно самое. В контексте рассматриваемого стека инлайнить их обязательно. Иначе появятся стековые переменные, код превращается в неприятное глазу унылое гуано.
zltigo, Rst7
Поднял производительность на целыx полтора килобита
В общем нуно потестить стек от Rst7.
Поднял производительность на целыx полтора килобита
В общем нуно потестить стек от Rst7.
QUOTE (prottoss @ Jul 31 2011, 14:16)
Поднял производительность на целыx полтора килобита
Дежавю
http://electronix.ru/forum/index.php?showtopic=41413QUOTE
Дежавю
О блин, плохо дело с портом на SAM7. Это придется все структуры в невыровненном режиме хранить. Ну или копировать к себе заголовки. Пока не готов сказать, какой способ будет эффективнее. Надо все-таки покурить даташит. Но выглядит это очень уныло.
Цитата(Rst7 @ Jul 31 2011, 17:46)
О блин, плохо дело с портом на SAM7. Это придется все структуры в невыровненном режиме хранить.
Можно хранить и в выравненном - для SAM7X можно задать начальное смещение по приему - например в 2 байта и все будет OK.
Upd: судя по моим исходникам - в EMAC_NCFGR - поле RBOF (блин, смотрю на свои тексты как баран - давно дело было)
QUOTE
Можно хранить и в выравненном - для SAM7X можно задать начальное смещение по приему - например в 2 байта и все будет OK.
Это радует, я уж думал - зопа
Цитата(zltigo @ Jul 31 2011, 20:29)
Даааа.... Тока в 2008 все заработало Млин. А я уже забыл. Это был первый опыт одновременного освоения ARM7, RTOS (ucOS-II) и сетевых протоколов... Брррр...
Собрал версию 1318 на LPC1769 @ 100 Mhz.
Тест скорости показывает 91929...94360 Kbit/s. На более ранних версиях (1315 например) такой стабильности не было - скорость плясала от 40000 до 90000 Kbit/s практически случайным образом. EMAC: LAN8720A-CP.
Тест скорости показывает 91929...94360 Kbit/s. На более ранних версиях (1315 например) такой стабильности не было - скорость плясала от 40000 до 90000 Kbit/s практически случайным образом. EMAC: LAN8720A-CP.
Цитата(VslavX @ Jul 30 2011, 18:38)
Будет время - я попрофайлю свой стек, потому как не совсем понятно куда время процессорное ушло.
Много времени прошло
Прикрутил к своему стеку ответную часть к iperf (теперь все цифры показывает iperf, довольно точно совпадает с внутренней измериловкой), сделал рефакторинг подсистемы аллокации/освобождения буферов, еще всякие мелочи
Достижения для LPC1768@100 такие (полезного TCP потока, из теоретически возможных ~96Mbps):
- передача на удаленный хост 88.8Mbps при 75-процентной загрузке проца
- прием от удаленного хоста 79.1Mbps при 85-процентной загрузке проца
На все сетевые буфера взято 16К памяти. Отключение контроля IP/TCP сумм дает примерно 20 процентов процессороного времени - на STM32F2xx с аппартными суммами станет полегче с загрузкой.
MPC8347@533MHz с гигабитным портом на оптимизацию кода отреагировал значительно более бурно,
было 398Mbps на прием, и 280MBps на передачу при ~100-процентной загрузке, после оптимизации
- передача на удаленный хост 343Mbps при 60-процентной загрузке проца
- прием от удаленного хоста 832Mbps при 70-процентной загрузке проца
Предположительно передатчик тормозится системой предотвращения заторов - наверное буду еще разбираться.
Да, все фреймы обычные - 1518 байт, на Джумбе должно быть еще немного веселее
Доброго здравия всем!
Что тема старая - вижу, но вдруг...
Упёрся в ограничение скорости примера от ST , поиск навел на этот топик. Как подключен физический уровень в вашем случае? У меня STM32F407 -> RMII -> SMSC LAN8720A . И как-то не даётся скорость в 3 Мбита. Какая скорость вообще достижима в такой связке? Тема для меня новая, поэтому может и лопухнулся где, но пока не нашёл.
Что тема старая - вижу, но вдруг...
Упёрся в ограничение скорости примера от ST , поиск навел на этот топик. Как подключен физический уровень в вашем случае? У меня STM32F407 -> RMII -> SMSC LAN8720A . И как-то не даётся скорость в 3 Мбита. Какая скорость вообще достижима в такой связке? Тема для меня новая, поэтому может и лопухнулся где, но пока не нашёл.
Не важно, как подключен. 100М вполне достижимая скорость.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.