caxapa.ru :: ну тут я вижу три решения, два из них уже слиты и осмотрены.

Mahagam (11.03.2012 18:04, просмотров: 90) ответил lentjaj2 на Что касается скорости, на этом стеке без серьёзных переделок на TCP далеко не уедешь. Сам посчитай, послал фрейм, ждёшь ACK, опять послал. А чтоб быстрее надо окно и/или фрагментация.

ну тут я вижу три решения, два из них уже слиты и осмотрены. а) разбивать пакет на две половинки, то есть вместо килобайта отсылать два по 500 (в uip-split сделано уже) б) посылать пакет с нулевой полезной длиной (какой-то чёрт это реализовал и проверил) в) посылать ещё один полезный пакет (это вот придётся дотачивать самому) но даже без всего этого, если настроить винду так, чтобы она отвечала на каждый пакет ACK`ом, то uIP у меня обгоняет lwIP, и ещё есть что точить на скорость

Ответить

- не понял о чём это, если про скорость, то можно попробовать по UDP быстро передавать с этим стеком, но придётся самому городить надстройку с очередями пакетов. lentjaj2(50 знак., 11.03.2012 18:23, )
  - всё просто. по рекомендациям RFC подтверждение ACK отправляется не на каждый пакет. а uIP ждёт ACK для отправки следующего пакета. и если ничего не предпринимать, то ACK приходит через 200ms, таким образом отправляется 5 пакетов в секунду по ~1400 Mahagam(92 знак., 11.03.2012 18:28)
    - Методы лечения не помогут, если медленный пинг. Если пинг - не проблема, тогда флаг в руки. - 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 контроллеры