Dingo (18.01.2016 15:23, просмотров: 301) ответил SciFi на Гугл говорит, что кто-то разгонял TCP до 92 Мбит/с. Естественно, зависит от того, что с этими данными делаете, ведь там тормозов помимо lwip можно понаделать. Опять же, если сделано через #опу и кривыми руками, как это часто бывает на всяких-
- У ТСП есть такой параметр как количество данных, отправленных без подтверждения. То есть стек может ждать подтверждение на каждый пакет и только потом отправлять следующий пакет. А может сразу запузырить дюжину пакетов и ждать подтверждение на них ASDFS(238 знак., 18.01.2016 15:40)
- Там внутре lwip много ручек покрутить можно. Нужно, чтобы затыков при выделении памяти не было. А память там выделяется в разных местах по-разному, и объёмы буферов настраиваются отдельно. Без поллитры не разберёшься. - SciFi(18.01.2016 15:46)
- А ведь написали! В общем, опция #define MEMP_OVERFLOW_CHECK сильно тормозит выделение и освобождение памяти. Dingo(154 знак., 04.02.2016 12:22)
- Поскольку мне подтверждение не нужно по той простой причине, что мне не где держать такие буфера на случай повторной отправки, то (пока?) остановился на UDP. - Dingo(18.01.2016 15:45)
- Для UDP достаточно uIP. Он проще на 2 порядка. - SciFi(18.01.2016 15:46)
- Его рекомендуете? или "ручки крутить" у LwIP? Источник данных - "внешняя память" на CPLD. - Dingo(19.01.2016 05:06 - 06:34)
- Для UDP достаточно uIP. Он проще на 2 порядка. - SciFi(18.01.2016 15:46)
- Там внутре lwip много ручек покрутить можно. Нужно, чтобы затыков при выделении памяти не было. А память там выделяется в разных местах по-разному, и объёмы буферов настраиваются отдельно. Без поллитры не разберёшься. - SciFi(18.01.2016 15:46)
- У ТСП есть такой параметр как количество данных, отправленных без подтверждения. То есть стек может ждать подтверждение на каждый пакет и только потом отправлять следующий пакет. А может сразу запузырить дюжину пакетов и ждать подтверждение на них ASDFS(238 знак., 18.01.2016 15:40)