Спасибо

Маловато будет. Сегодня закончил разработку драйвера для EMAC STM32Fxxx, с опциональной/отключаемой поддержкой аппаратных сумм - сам драйвер более 4 тыс строк, с использованием RTOS. На F207@120МГц результаты такие (поток в одну сторону, iperf-ом мерялось):
С отключенными суммами (скорость указана в "полезных" байтах TCP-соединения, теоретический предел порядка 96 мбит/сек):
- прием от PC - 95.7 мбит/сек, загрузка процессора 77 процентов (23 в IDLE остается еще)
- передача на PC - 87.8 мб, загрузка процессора 59 процентов (41 в IDLE)
С включенными аппаратными суммами:
- прием от PC - 95.7 мбит/сек, загрузка процессора 55 процентов (45 в IDLE)
- передача на PC - 88.4 мб, загрузка процессора 51 процентов (49 в IDLE)


Как показывают приведенные цифры - заметная разница вылазит только на относительно больших скоростях. Ваши потоки на порядок меньше, соответственно и разница тоже на порядок меньше (22 процента разделить на 10 - пару процентов и выходит). Справедливости ради надо заметить, что я обломался с написанием обработки специфических ошибок DMA передатчика и в обоих случаях (с суммами и без) контроллер работает в режиме Store-And-Forward, этим я объясняю недостижение передатчиком теоретического максимума в 96 мбит/сек.

Я смотрю, зацепил я Вас в той теме со стеком. Цифры у Вас явно выше тогдашних, поздравляю

Что иллюстрирует следующую мысль: чтобы выжать из железа все соки, надо попыхтеть. Если эти 100 Мбит на практике не нужны, то лучше направить свою энергию в более конструктивное русло.

Ну не то чтобы зацепили, но критично на свой код посмотреть заставили




TCP/IP стек - это универсальный кубик, его можно применить в любом проекте, не ограничивая себя теми,
где "эти 100 Мбит на практике не нужны". Например этот же "кубик" у меня стоит в проекте где и гигабита маловато.

Уже польза.

Сложно серверную сторону на железе поднять?

стек вы реализовывали или готовый использовали?

Несложно, клиентскую тоже несложно. Если нужен сервер - то ждете соединение (listen), принимаете его (accept) и на новом TCP соединении просто осуществляете прием с отбрасыванием всех поступивших данных (естественно на уровне приложения, а не стека), при желании измеряете текущую скорость на стороне сервера, когда соединение закрывается - цикл можно повторить. Никаких специальных данных в потоке iperf не требует.


Реализовывал свой, ничего из готового на тот момент не устраивало.

Какие протоколы? Какие сложно реализовать?

Сложность понятие относительное, зависит от того какие опции протоколов нужны и от общей архитектуры. Если нужны только ARP/IP/ICMP/UDP без особых наворотов (без IP-опций, без фрагментирования, не заморачиваясь с фичами типа zero-copy) то можно даже не напрягаться и взять уже что-то готовое. Но мне был нужен минимальный комплект ARP/IP/ICMP/UDP/TCP/DHCP/AutoIP/DNS/HTTP/SSDP, да в разные проекты, да на долгую перспективу, да endainess-portable, да на работе вытерпели (читать - дали время, повезло мне) - поэтому решил сделать свой.
На 2008-ой год, когда писалась основная часть, изучал многие готовые стеки (uIP, lwIP, Niche, ka90, tinet, OpenTCP) . На мой взгляд самый внятный это lwIP. Поэтому если свой стек нет возможности писать - то я бы остановился на lwIP, тем более что его в последнее время развивать стали.

Уверен: великолепный опыт. Но думаю хотя бы PPP реализовывать самому - сложное занятие, так что выбираю lwIP.
Интересно, каким образом близкие к 100Mbit/s выжимали из STM32F4x7 из lwIP... Кто-нибудь может поделиться опытом? Очень интересно.