[ilmarin 0]

Собственно проект: http://code.google.com/p/uhttpd-avr/ компилиурется WinAvr, прошивку можно обновлять с помощью FLIP'a через USB. Параметры сети хрянятся в EEPROM'e, можно менять через web, есть поддержка DHCP. Всё реализовано на основе uIP модифицированного для хранения данных в program memory.

 

P.S. Работает медленно

[ilmarin 0]

Неужто никому не нужно?

[mrKirill 1]

Вот этим отпугнул :)

P.S. Работает медленно

Мне лично интересно, но я пока мельком глянул.

 

PS. Не нашел кнопки в репозитории чтобы сразу архивом все файлы качнуть.

[Rst7 5]

P.S. Работает медленно

 

Дык надо uIP хачить на предмет Delayed ACK. Будет лучше :)

[ilmarin 0]

PS. Не нашел кнопки в репозитории чтобы сразу архивом все файлы качнуть.

Вот, сделал архив: http://uhttpd-avr.googlecode.com/files/uht...-2009-07-06.zip

[mrKirill 1]

Вот, сделал архив: http://uhttpd-avr.googlecode.com/files/uht...-2009-07-06.zip

Благодарю. Будем изучать :)

[ilmarin 0]

Дык надо uIP хачить на предмет Delayed ACK. Будет лучше :)

Приделал uip_split ( http://www.sics.se/~adam/uip/uip-1.0-refman/a00154.html )

заметно лучше не стало. Скорее всего из-за того что этот хак отсылает по-частям только пакеты максимальной длинны.

 

Что интересно, если сравнивать скорость загрузки страннички с динамически сгенерированной формой на винде ХП и линиксе (Ubuntu) то на линуксе существенно быстрее (и там и там Firefox 3.0.11 , без прокси ).

 

http://uhttpd-avr.googlecode.com/files/uht...-2009-07-08.zip

[Rst7 5]

Приделал uip_split заметно лучше не стало. Скорее всего из-за того что этот хак отсылает по-частям только пакеты максимальной длинны.

 

Дык захачте его, чтобы любые пакеты пилил. Либо есть другой вариант (я так делал, пока не реализовал полноценную поддержку Delayed ACK у себя в стеке) - после каждого пакета с данными посылать пакет без данных с тем же SEQ - на такое что винда, что линух мгновенно отвечает ACK'ом.

 

Что интересно, если сравнивать скорость загрузки страннички с динамически сгенерированной формой на винде ХП и линиксе (Ubuntu) то на линуксе существенно быстрее (и там и там Firefox 3.0.11 , без прокси ).

 

Дело в том, что авторы стека TCP/IP в линухе видимо писатели, а не читатели (рекомендаций в RFC), посему линух отвечает ACK'ом на каждый пакет.

[ilmarin 0]

Дык захачте его, чтобы любые пакеты пилил.

 

Пробовал ( поменял условие при котором распил происходит ) - что-то нестабильно работать стало.

[Rst7 5]

Пробовал ( поменял условие при котором распил происходит ) - что-то нестабильно работать стало.

 

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

[ilmarin 0]

В чем нестабильность выражена?

 

Связь стала случайным образом подвисать.

 

Дело в том, что авторы стека TCP/IP в линухе видимо писатели, а не читатели (рекомендаций в RFC), посему линух отвечает ACK'ом на каждый пакет.

Нашёл в интернете что в виндах таймер на ACK - 200мс, а в Линуксе - 10мс. Кстати, в виндах можно настраивать количество пакетов : http://support.microsoft.com/kb/328890 , если поставить 1 то всё работает довольно быстро.

[Rst7 5]

Связь стала случайным образом подвисать.

 

Хз, хз..

 

Кстати, в виндах можно настраивать количество пакетов : http://support.microsoft.com/kb/328890 , если поставить 1 то всё работает довольно быстро.

 

Ну это не выход. Во-первых - нарушает чи большим братьям с полновесной реализацией TCP-стеков. Во-вторых - без полноценной поддержки Delayed ACK толку от этого на медленных каналах связи не будет - каждый пакет будет передаваться за время прохода туда и обратно.

 

В принципе, можно дохачить uIP под полноценную поддержку Delayed ACK (и посылок размером в окно).

[ilmarin 0]

В общем нашёл ошибку ( надо было проверять что пакет уже ушёл, и в рассчёте размеров пакета в uip-split была ошибка). Ну и сделал отправку пустых пакетов. Теперь работает и то и другоe ( выбирается в uNetConfigure.h). Работать стало быстрее, но Линукс по прежнему опережает винду, почему то.

 

Обновлённый релиз: http://uhttpd-avr.googlecode.com/files/uht...-2009-07-09.zip

Изменено 9 июля, 2009 пользователем Ilmarin

[Rst7 5]

Работать стало быстрее, но Линукс по прежнему опережает винду, почему то.

 

Да потому, что все это - костыли. Если такое просунуть через медленный канал, будет ужасно. Надо реализовывать правильную работу с окном.

[ilmarin 0]

Да потому, что все это - костыли. Если такое просунуть через медленный канал, будет ужасно. Надо реализовывать правильную работу с окном.

 

Ну, это всё делается не для того чтобы сотню запросов в секунду обрабатывать.

Сейчас уже на мега32 память почти вся занята ( и это при том что буфер установлен в 400 байт и максимум 2 паралельных соединения):

 

AVR Memory Usage

----------------

Device: atmega32u4

 

Program: 25658 bytes (78.3% Full)

(.text + .data + .bootloader)

 

Data: 2125 bytes (83.0% Full)

(.data + .bss + .noinit)

 

EEPROM: 19 bytes (1.9% Full)

(.eeprom)