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