caxapa.ru :: всё просто. по рекомендациям RFC подтверждение ACK отправляется не на каждый пакет. а uIP ждёт ACK для отправки следующего пакета. и если ничего не предпринимать, то ACK приходит через 200ms, таким образом отправляется 5 пакетов в секунду по ~1400

Mahagam (11.03.2012 18:28, просмотров: 90) ответил lentjaj2 на не понял о чём это, если про скорость, то можно попробовать по UDP быстро передавать с этим стеком, но придётся самому городить надстройку с очередями пакетов.

всё просто. по рекомендациям RFC подтверждение ACK отправляется не на каждый пакет. а uIP ждёт ACK для отправки следующего пакета. и если ничего не предпринимать, то ACK приходит через 200ms, таким образом отправляется 5 пакетов в секунду по ~1400 байт полезной нагрузки. что, конечно же, ужасно. лечится это методами перечисленными выше.

Ответить

- Методы лечения не помогут, если медленный пинг. Если пинг - не проблема, тогда флаг в руки. - SciFi(11.03.2012 18:31)
  - да хрен с ним, с пингом. как сделать красиво что бы и данные в кэшируемой области были, и кеш не весь сбрасывать.. - Mahagam(11.03.2012 18:39)
    - можно не весь кэш сбрасывать, а только нужные адреса. копать в сторону сопроцессора CP15 в ARM926EJ-S. там есть команды для сброса/синхронизации отдельной линни кэша (32 байта) - "Invalidate TLB entry, selected by MVA, using CP15 register 8". Koshak(88 знак., 11.03.2012 20:46)
      - ну вот я там циклом после сброса кэша в память инвалидирую его всего. - Mahagam(11.03.2012 21:09)

ARM, RISC-V контроллеры