Стеки TCP/IP с примерами на STR912, OpenTCP, lwIP, тесты производительности Опции

[Pechka]

Здравствуйте! Понадобилось реализовать "быстрый" канал по Ethernet на str912. Нашёл много упоминаний о openTCP, lwIP, даже какие-то тестовые результаты скорости по TCP. Однако нигде не нашёл исходников используемых портов. (общий C код есть, однако хочется с примерами на конкретном железе). Кто может поделиться такими реализациями? (обязательное условие - без операционки).
Заранее благодарю.

[blackfin]

NicheLite, на ST не сгодится?

Сообщение отредактировал blackfin - Mar 25 2010, 17:38

[Pechka]

NicheLite, на ST не сгодится?

Как у него со скоростью? Может и сгодится

[scifi]

Как у него со скоростью? Может и сгодится

Скорость - понятие весьма относительное. Опишите свою задачу, тогда люди что-нибудь дельное посоветуют. Описание типа "погуще, потолще, посильнее" не годится.

[MALLOY2]

Порты относятся к опарационкам, вы же хотите без нее, так какой тут порт ?, для LWIP нужен только драйвер для MAC контроллера и все. Примеры есть на сайте ST но они не оптимизированные. И какую вы хотите скорость от STR912? 100% загрузки канала на TCP не получите, максимум 60-70% это на чистом стеке, тобиш проц ничего не делает кроме обслуживания стека и пакеты гоняет в никуда в одну сторону, чисто на чтение загрузка канала порядка 85% - 90% но принятые данные никак не обрабатываются. Также пропускная будет зависеть от количества выделенной вами для стека памяти.

[Pechka]

Порты относятся к опарационкам, вы же хотите без нее, так какой тут порт ?, для LWIP нужен только драйвер для MAC контроллера и все. Примеры есть на сайте ST но они не оптимизированные. И какую вы хотите скорость от STR912? 100% загрузки канала на TCP не получите, максимум 60-70% это на чистом стеке, тобиш проц ничего не делает кроме обслуживания стека и пакеты гоняет в никуда в одну сторону, чисто на чтение загрузка канала порядка 85% - 90% но принятые данные никак не обрабатываются. Также пропускная будет зависеть от количества выделенной вами для стека памяти.

Прошу прощения за неточность формулировки. я имел ввиду именно стэк с драйвером и всеми настройками типа DMA и т.д.

Задача проста: нужно взять из Ethernet поток и запихнуть его в EMI с максимальной скоростью... и соответственно наоборот из EMI запихнуть поток в Ethernet. Предполагаю обрабатывать пакеты в прерываниях соответствующих и заряжать там DMA. Процессор никакими рассчетами не занят, памяти тоже свободной хватает. Так что хочется найти пример максимально быстрого стека практически не замарачиваясь на ресурсы... Максимальный размер пакета в ethernet спецификации вроде 1.5к, значит на него не нужно много памяти... Обрабатывать как-то параллельно что-то или вроде того не планирую вовсе. Кроме того хочу сгребать все tcp пакеты, независимо от порта. Вобщем есть что упростить и прооптимизировать...

Из довеска к TCP нужно только DHCP.

Сообщение отредактировал Pechka - Mar 25 2010, 20:18

[aaarrr]

...хочу сгребать все tcp пакеты, независимо от порта.

Это, простите, как? TCP соединение устанавливается между двумя конкретными портами.

[Pechka]

Это, простите, как? TCP соединение устанавливается между двумя конкретными портами.

Очень просто: "слушать" сразу все порты т.е. 1024-65535 и обрабатывать их одинаково...

[aaarrr]

А смысл какой открывать до 64K соединений?

[Pechka]

А смысл какой открывать до 64K соединений?

Никто не собирается открывать 64к соединений, соединений будет не более 2х. Однако какие порты при этом будут участвовать - не важно. т.е. это будет сервер, который будет доступен по любому из портов протокола TCP.
Грубо говоря это просто некий широкий канал обмена между другими частями системы (которые висят на EMI) и PC.
При этом поскольку EMI у нас всего 1, то и соединений нам много не нужно.

Сообщение отредактировал Pechka - Mar 25 2010, 20:50

[aaarrr]

Никто не собирается открывать 64к соединений, соединений будет не более 2х. Однако какие порты при этом будут участвовать - не важно. т.е. это будет сервер, который будет доступен по любому из портов протокола TCP.

Сомнительное "упрощение", ну да ладно.

Грубо говоря это просто некий широкий канал обмена между другими частями системы (которые висят на EMI) и PC.
При этом поскольку EMI у нас всего 1, то и соединений нам много не нужно.

Так может и TCP не нужен, если нужна скорость, а PC рядом? Накрутите просто свой протокол поверх UDP.

[Pechka]

Свой протокол поверх UDP не хочется городить т.к. тогда понадобится писать драйвер для этого сетевого устройства, иначе программисты PC будут ругаться, плеваться и т.д. Хочется что-то стандартное, возможно упрощенное. Да и в целом TCP достаточно удобно сделан для соединений с гарантированой доставкой: вроде бы ничего лишнего. Однако в моем случае можно будет ещё упростить его тем, что пакеты будут приходить в верном порядке.

[KRS]

Так может и TCP не нужен, если нужна скорость, а PC рядом? Накрутите просто свой протокол поверх UDP.

+1
Если все происходит в одной физической локальной сети, без маршрутизаторов. TCP точно не нужен. UDP сэкономит и время и место.
В TCP много лишнего - измерение скорости канала и т.п. что в локальной сети абсолютно лишнее.

[aaarrr]

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

Если "программисты PC" плюются, когда слышат о непонятном протоколе UDP, то значит это совсем даже не программисты.

Хочется что-то стандартное, возможно упрощенное. Да и в целом TCP достаточно удобно сделан для соединений с гарантированой доставкой: вроде бы ничего лишнего. Однако в моем случае можно будет ещё упростить его тем, что пакеты будут приходить в верном порядке.

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

[Pechka]

Нет, я имел ввиду не UDP непонятный, а надстройка будет самодельная и из-за неё будут проблемы.
Ну, раз все настаивают - буду лобировать сей вопрос завтра

Но всё-таки хотелось бы получить ещё и lwIP, openTCP примеры для STR912

Сообщение отредактировал Pechka - Mar 25 2010, 21:21

[KRS]

Да и в целом TCP достаточно удобно сделан для соединений с гарантированой доставкой: вроде бы ничего лишнего.

Конечно! Если у вас пакет проходит по разнородным каналам с разной скоростью и MTU, через маршрутизаторы...
То да - ничего лишнего там нет

[zltigo]

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

Это как-бы это помягче, не упрощение, а чистый геморрой своими руками . Просто Автор имеет совсем поверхностно-идеалистические представления об TCP/IP. Для начала даже самую общую задачу не сформулировал

Нет, я имел ввиду не UDP непонятный, а надстройка будет самодельная и из-за неё будут проблемы.

Или наоборот - еще бОльшие проблемы из-за TCP.

[Pechka]

Конечно! Если у вас пакет проходит по разнородным каналам с разной скоростью и MTU, через маршрутизаторы...
То да - ничего лишнего там нет

А какими средствами достигается контроль такой сложной системы? просто номер пакета и ACK. Звучит круто, а реальных накладных расходов на это не так уж и много... Сложно следить сразу за кучей соединений и процессов, которые хотят достучаться до сети, а когда нужно соединение типа точка-точка (но, правда, через некоторое количество коммутаторов), то большинство проблем и накладных расходов не требуется...

[zltigo]

Звучит круто, а реальных накладных расходов на это не так уж и много...

... особенно, когда, например, через многие десятки секунд программисты на PC узнают, что все,что они посылали никуда не дошло.
Ну а на контроллере обратный канал будет забиваться ACK а неподтвержденные придется буферизировать и перепередавать, не забывая о том, что новые сыпятся. Для сколь-нибудь реального времени TCP это хреновое решение и даже не из-за стороны контролера (где можно поработать, хотя Вы хотите готовую халяву ), а из-за стека на PC (хоть Win, хоть Lin) и обработки ошибок на низком уровне, на которую все, начиная с разработчиков драйверов, забили - пусть TCP все разгребает, как может.

[aaarrr]

...из-за стека на PC (хоть Win, хоть Lin) и обработки ошибок на низком уровне, на которую все, начиная с разработчиков драйверов, забили - пусть TCP все разгребает, как может.

Это да. Помнится, лет восемь назад мне очень изрядно попортила кровь реалтековская сетевая карта со своими замечательными драйверами - внутри ethernet-фреймов периодически проскакивали пары нулей: <данные пакета><00 00><продолжение данных пакета>. Стоит ли говорить, что причину возникновения этих нулей я очень долго пытался найти у себя. Случайно только обнаружил, что при подключении к этой карте другого компьютера на нем подозрительно начинает ползти счетчик ошибок контрольных сумм TCP-пакетов.

И ведь действительно разгребает и вытягивает

[Pechka]

Вы хотите готовую халяву

Я хочу не найти готовую халяву, а взять "стартовую точку" повыше... Естественно придётся всё самому дорабатывать и корректировать, онако с чего-то начинать нужно.

[zltigo]

Я хочу не найти готовую халяву, а взять "стартовую точку" повыше...

Тут, эээ...., дело такое, чем выше точку возьмете, тем в большем количестве мусора придется разбираться, сносить, выносить сор....
Вам хочется быстрее устроить "праздник первого пинга"? Ну так возьмите первое попавшееся под руку.
А для приличного, по любому начинать придется медленно и печально с того-же железа, ибо, не знаю, правда, какая ситуация с STR9xx, но по ~20летнему опыту работы с разнообразнейшии MACами, 99:1, что ничего приличного для высокопризводительных решений, даже для уровня драйвера в интернете нет .

[Pechka]

Тут, эээ...., дело такое, чем выше точку возьмете, тем в большем количестве мусора придется разбираться, сносить, выносить сор....
Вам хочется быстрее устроить "праздник первого пинга"? Ну так возьмите первое попавшееся под руку.
А для приличного, по любому начинать придется медленно и печально с того-же железа, ибо, не знаю, правда, какая ситуация с STR9xx, но по ~20летнему опыту работы с разнообразнейшии MACами, 99:1, что ничего приличного для высокопризводительных решений, даже для уровня драйвера в интернете нет .

Я себе всё примерно так и представляю, однако, ввиду малого опыта конфигурирования STR912 (а на мой взгляд конфигурирование у него до жути корявое), мне нужно что-то на чём всё править. Т.е. собираюсь взять готовый драйвер, готовый стек (хоть сколько нибудь пригодный для правок), запихнуть в уже существующую программу. Далее первый этап оптимизации - изменение драйвера на свой толк: DMA, прерывания по фрэймам и т.д.
Если при этом у меня не будет стека будут трудности с проверкой этого дела. Снифер конечно поможет, но всё-таки могут выясниться попутно какие-то ограничения на переделку драйвера. Вобщем хотелось бы править "на живую", чтобы не пришлось потом всё переделывать, когда в конце пути выяснится, что изначально в концепции была ошибка где-то...

[KRS]

А какими средствами достигается контроль такой сложной системы? просто номер пакета и ACK. Звучит круто, а реальных накладных расходов на это не так уж и много...

Так это только оверхед по данным в пакете!!!
По такому подходу вы и можете сделать протокол повер UDP - и все будет просто и бытсро работать!
А в TCP все намного сложнее почитайте про -
медленный старт
алгоритм нагла
выбор размера окна...
таймеры, которые использует TCP

[Pechka]

Так это только оверхед по данным в пакете!!!
По такому подходу вы и можете сделать протокол повер UDP - и все будет просто и бытсро работать!
А в TCP все намного сложнее почитайте про -
медленный старт
алгоритм нагла
выбор размера окна...
таймеры, которые использует TCP

Пожалуй соглашусь всё-таки... буду делать свой протокол поверх UDP. Всем спасибо!