[swampman 0]

Периодически на форуме появляются вопросы по этому стеку, их немного, поэтому просто предлагаю свалить все в кучу, возможно потом сделать FAQ.

 

У меня возникла задача закачать на устройство несколько метров данных за возможно более короткое время. На ARM7 под FreeRTOS скорость получилась ~ 1.6 МБайта/сек ~ 10МБит. Но это после того как в системе оставил только одну задачу под стек и Main Loop стека сделал без задержек. На мой взгляд препятствием к дальнейшему увеличению скорости является отсутствие так называемого алгоритма Delayed Acknowledgement, когда ACK отправляется через один пакет, по крайней мере такое я наблюдал в винде при перекачке больших файлов.

Соответственно вопрос: какую скорость обмена данными можно выжать из этого стека и как этого достичь?

[scifi 1]

У меня возникла задача закачать на устройство несколько метров данных за возможно более короткое время.

Насколько я знаю, uIP работает по схеме "пакет_данных-подтверждение-пакет_данных-подтверждение-...". Ясно, что это фундаментальное ограничение, и макс. скорость будет рассчитываться приблизительно как макс_размер_пакета/время_отклика. Если нужно быстрее, то нужен стек TCP/IP без этого ограничения. Например, lwip (кстати, автор uIP и lwip один и тот же - Adam Dunkels).

[salvian 0]

Периодически на форуме появляются вопросы по этому стеку, их немного, поэтому просто предлагаю свалить все в кучу, возможно потом сделать FAQ.

 

У меня возникла задача закачать на устройство несколько метров данных за возможно более короткое время. На ARM7 под FreeRTOS скорость получилась ~ 1.6 МБайта/сек ~ 10МБит. Но это после того как в системе оставил только одну задачу под стек и Main Loop стека сделал без задержек. На мой взгляд препятствием к дальнейшему увеличению скорости является отсутствие так называемого алгоритма Delayed Acknowledgement, когда ACK отправляется через один пакет, по крайней мере такое я наблюдал в винде при перекачке больших файлов.

Соответственно вопрос: какую скорость обмена данными можно выжать из этого стека и как этого достичь?

какой протокол используется для передачи?

на мой взгляд, для передачи данных проще всего использовать какую нибудь легковесную реализацию протокола tftp.

[swampman 0]

В общем я прихожу к выводу, что одними средствами uIP большой скорости не получить: либо серьезно править стек, либо использовать UDP и прикручивать что-то сверху него. Сейчас разбираюсь с lwIP, посмотрим на что он способен.

Изменено 12 августа, 2009 пользователем vladik

[salvian 0]

В общем я прихожу к выводу, что одними средствами uIP большой скорости не получить: либо серьезно править стек, либо использовать UDP и прикручивать что-то сверху него. Сейчас разбираюсь с lwIP, посмотрим на что он способен.

скорость ещё от железа зависит. к тому же протокол TCP довольно сложный как в теории так и на практике, по крайней мере если сравнивать с UDP. кстати, TFTP реализуется как раз поверх UDP.

 

а по поводу uIP vs lwIP, то как говорит сам автор обоих стеков, uIP проще чем lwIP и основное различие между ними в том что lwIP поддерживает несколько сетевых интерфейсов и может между ними пакеты роутить, поэтому если поддержка нескольких интерфесов не нужна то проще использовать uIP. раньше uIP ещё и UDP не поддерживал, но теперь держит.

 

http://www.sics.se/~adam/mobisys2003.pdf - тут табличка сравнительная есть.

[Rst7 5]

основное различие между ними в том что

 

Основное различие в том, что lwIP поддерживает опережающую передачу. То, что называется Sliding window.

 

Вообще-то мне не понятна фраза

Also, uIP does not buffer sent packets and a sliding window implementation that does not buffer sent packets will have to be supported by a complex application layer.

 

Слухи о сложности сильно преувеличены. Я у себя в стеке реализовал без особых проблем. Кстати, достаточно легко это допиливается исходя из такого требования к уровню приложения:

As uIP does not keep track of packet contents after they have been sent by the device driver, uIP requires that the application takes an active part in performing the retransmission. When uIP decides that a segment should be retransmitted, it calls the application with a flag set indicating that a retransmission is required. The application checks the retransmission flag and produces the same data that was previously sent.

 

Т.е. в любом случае, уровень приложения должен уметь сформировать такой-же пакет. А от этого один шаг к поддержке опережающей передачи. У меня для уровня приложения есть 3 события по передаче - сгенерить не более стольки-то новых данных (каждый вызов приводит к генерации следующей порции), откат на состояние последних подтвержденных данных и подтверждение стольки-то уже переданных данных.

[salvian 0]

Основное различие в том, что lwIP поддерживает опережающую передачу. То, что называется Sliding window.

Не считаю что этот механизм есть основное различие хотя и не маловажное, но это имхо.

 

Вообще-то мне не понятна фраза

В связи с тем что стек этого не умеет реализуйте это сами на уровне приложения, так чтоли? :)

 

Слухи о сложности сильно преувеличены. Я у себя в стеке реализовал без особых проблем. Кстати, достаточно легко это допиливается исходя из такого требования к уровню приложения:

 

Т.е. в любом случае, уровень приложения должен уметь сформировать такой-же пакет. А от этого один шаг к поддержке опережающей передачи. У меня для уровня приложения есть 3 события по передаче - сгенерить не более стольки-то новых данных (каждый вызов приводит к генерации следующей порции), откат на состояние последних подтвержденных данных и подтверждение стольки-то уже переданных данных.

Не знаю, спорить не буду, может быть по TCP и можно добиться хорошей скорости передачи используя какую нибудь реализацию опережающей передачи, но по моему опыту передать файл по TFTP получается в разы быстрее.

[Rst7 5]

В связи с тем что стек этого не умеет реализуйте это сами на уровне приложения, так чтоли?

 

Я немного некорректно выразился. Фраза мне понятна. Мне не ясно, почему так автор так боится "complex application layer" - хотя, некоторые шаги он от этого уровня требует (это я чуть ниже изложил).

 

Не знаю, спорить не буду, может быть по TCP и можно добиться хорошей скорости передачи используя какую нибудь реализацию опережающей передачи, но по моему опыту передать файл по TFTP получается в разы быстрее.

 

Гм. Насколько я понимаю в гинекологии, TFTP - там банальная система "посылка-подтверждение", т.е. пока нет подтверждения, следующий пакет не посылается. Как же такая конструкция может обогнать вменяемую реализацию TCP?

[salvian 0]

Гм. Насколько я понимаю в гинекологии, TFTP - там банальная система "посылка-подтверждение", т.е. пока нет подтверждения, следующий пакет не посылается. Как же такая конструкция может обогнать вменяемую реализацию TCP?

на железках с малым количеством мегагерцев TCP очень трудоёмким выходит, но опять же я имею ввиду не lwIP а более примитивный стек.

 

vladik, был бы очень признателен за предоставленные результаты по скорости закачки с использованием lwIP.

[Rst7 5]

на железках с малым количеством мегагерцев TCP очень трудоёмким выходит,

 

Вы заблуждаетесь :) Пройдемся по пунктам:

 

1. Размер заголовков немного больше, чем в UDP. Но разницы особой нет, что 8 байт, что 20.

2. Лишняя математика представляет из себя всего-лишь

a) Вычитание 2х 32хбитных чисел (SEQ и ACK) (реально используется при приеме пакета 2 раза)

б) Увеличение 32хбитного числа на N (реально используется при приеме пакета 2 раза (один раз увеличить ожидаемый в следующий раз SEQ согласно принятому количеству данных, один раз увеличить наш SEQ согласно подтвержденному количеству данных; при передаче используется один раз - увеличить SEQ из области данных сокета на количество уже переданных байт).

3. Всякое обрамление типа таймеров, открытия/закрытия соединения на скорость самого соединения не влияют.

 

Все пункты не могут создать многократного проигрыша. Один/два процента просада производительности - вот максимум. Но это только в том случае, если уровень приложения, пользующийся UDP, сам реализует всяческие фичи типа опережающей передачи, банальная система "пакет-подтверждение" проигрывает в хлам вменяемой реализации TCP.

[salvian 0]

...банальная система "пакет-подтверждение" проигрывает в хлам вменяемой реализации TCP.

Возможно так и есть, спорить бессмысленно, проверить надо (мне как раз в скором времени lwIP прикручивать к проекту).

Может быть мною использовался не совсем вменяемый стек, разбирать функцию которая принимала TCP пакеты я не стал, но жрала она, надо вам сказать, огого, видимо автор не запарился на оптимизацию. Вообщем, будем тестить скорость на lwIP'ном стеке.

[Nidanilov 0]

Интересная тема... решил разобраться в исходниках uIP, кот есть в атмеловских примерах на evalboard sam7x. Хотелось бы поднять простой стек без OS, так как кроме ethernet других интерфейсов не нужно, обмен должен идти по UDP... Вот тут не все понятно, во первых в статье автора mobisys2003 не стоит "+" на UDP, в другой статье пишется что UDP реализован "в рудиментарном состоянии", здесь пишется что UDP уже есть. Сам пытаюсь разобраться в исходном коде, но пока безуспешно :( , Подскажите можно ли отправить UDP сообщение используя uIP? Если да то на коротком примере...