caxapa.ru :: Смотрите что происходит

Ralex (16.01.2014 14:16, просмотров: 216) ответил Mahagam на на этом стеке я лью-сливаю со скоростью ~2.6-4 мегабайта в сек.

Смотрите что происходит Здесь плата на STM32F407 с адрсом 192.168.1.101 передает на комп (192.168.1.4) файл. Если присмотреться (я выделил посылку платы и ответ ACK компа стрелочками), то комп отсылает ACK спустя аж 200мс после пакета с данными, а вот плата после приема ACK готова отдать новые данные почти мгновенно. То есть, комп просто тормозит весь процесс. Но ему можно - согласно rfc хз какому, на первый пакет данных допускается задержка ACK вплоть до 500мс. Так что еще не самый плохой случай. 200мс как раз и объясняет мою скорость 7 кб в сек - 5 раз в секунду по 1500 байт, ну плюс накладные расходы есть. Вот и получается 7кбайт. Этот стек в его таком виде не может обеспечить производительность со всеми без исключения устройствами на всех ОС тупо исходя из ограничений, накладываемых в rfc. Но для него придумали хак - дело в том что на второй пакет, следующий за неподтвержденным пакетом, устройство должно отвечать сразу, настолько быстро насколько это возможно. Вот это и используется в одном из режимов uIP - пакет бьется на два подпакета поменьше, и оба посылаются не дожидаясь ACK. И затем ловятся ACKи уже от обоих. Однако, несмотря на то что это работает, это называется переложить свои проблемы на принимающую сторону. Меня заказчик порвет, обнаружив такую особенность работы. И так как основной заказчик - провайдер, то обнаружит как пить дать. Есть ОС Nuttx, где используется часть стека uIP с надстройкой - в которой реализован механизм отложенных ACK. Пользователь сбрасывает ему порцию данных размером несколько пакетов (сколько не жалко памяти), а надстройка бьет их на подпакеты 1500 байт и организует всю кухню отложенных ACK. Проблема широко описана (c) fk0

Ответить

- а. ясно. так как у нас предполагается работа только с виндой, и только с узким количеством "допущенных" до железки компов, то мы поступили проще: Mahagam(567 знак., 16.01.2014 14:48)
  - Трэш, угар и содомия. - fk0(17.01.2014 00:16)
  - Про пару строчек в реестре можно поподробнее? - MBedder(16.01.2014 15:31)
    - вот что нарыл сходу: Mahagam(837 знак., 16.01.2014 15:41)
      - Ага, спасибо, поковыряюсь - MBedder(16.01.2014 15:59)
  - Тут Ralex(199 знак., 16.01.2014 15:10)
    - я поковырял текстовое описание этой надстройки. Mahagam(591 знак., 16.01.2014 15:32)
      - В каждом пакете с ACK (см. в википедии описание TCP протокола) говорится какой номер пакета подтверждается. Если пакет подтверждается -- значит он и все более ранние пакеты уже приняты ( fk0(802 знак., 17.01.2014 00:40)
        
        ну так логично. uIP точилась под системы без нормальных объёмов памяти. если ей наделать окон да буферов, буквочку "u" перед IP придётся убрать. и получится lwIP. - Mahagam(17.01.2014 00:44)
        
        Если система без нормальных объёмов памяти (пик контроллер проф. уровня) передаёт из файла, то окно может быть большим, если в файле можно делать seek()... Просто интерфейс сокетов этого не предусматривает. Например, при чтении из flash памяти. - fk0(17.01.2014 10:05)
        
        Логично. Но как же тогда телнет работает? Там ничего не тормозит. TCP_NODELAY? Может uIP не ставит этот бит? - fk0(17.01.2014 00:52)
        
        uIP ставит в каждом пакете бит ACK, и кроме того, принудительно ставит бит PUSH, по которому стек должен пропихнуть данные приложению - Mahagam(17.01.2014 10:12)
        
        TCP_NODELAY отключает алгоритм Нейгла, и влияет только на сборку мелких кусочков в один пакет, то есть - на передающую сторону. У нас проблема в приемной стороне - она считает ворон 200мс. Если вы пишете на клавиатуре, то с TCP_NODELAY у вас не Ralex(276 знак., 17.01.2014 03:46)
        
        См. rfc2581, раздел 4.2. "Out-of-order data segments SHOULD be acknowledged immediately..." -- возможно, это решение. - fk0(17.01.2014 10:00)
      - Угу, знакомая ситуация. Мой вин-программист не знает, как организовать выгребание данных из одного порта приходящего UDP-потока одновременно несколькими процессами. Пока костыльно извратились посредством посылания дублирующего потока в другой MBedder(47 знак., 16.01.2014 16:04)
        
        SO_REUSEADDR и multicast UDP (через IGMP) - Nick(16.01.2014 21:51, )
        
        +1 всё реально. Но девайс сразу в IGMP вещать должен. Тогда закат солнца вручную не нужен. - fk0(17.01.2014 00:16)
        
        то есть про кольцевой буфер он не знает? ) Mahagam(86 знак., 16.01.2014 16:24)
        
        Чтобы учинить кольцевой буфер в винде, нужно в драйверный уровень погрузиться, а это он не умеет :( - MBedder(16.01.2014 16:56)
        
        Это ты не знаешь, что любой fifo, unix domain socket или tcp socket дадут тот самый буфер. 4кб, 128кб и 128кб соответственно (типично). Собственно если железяка IGMP не может, то можно сделать повторитель вещающий в IGMP, а от него уже и принимать fk0(525 знак., 17.01.2014 00:21 - 00:42)
        
        У меня железка создает UDP-поток, и IGMP сделать - не проблема. Конфигурация примитивная - точка-точка, без посторонних источников и хабов/свитчей, т.е. сети как таковой нету - MBedder(17.01.2014 00:44)
        
        так в своём софте. а дальше раздавать процессам данные уже из этого буфера. - Mahagam(16.01.2014 17:05)
        
        На уровне ОС это недоступно ИМХО - MBedder(16.01.2014 17:07)
        
        А для чего такой изврат нужен - "одновременно несколькими процессами"? Даже если нужен, то это твой программист вполне логично делает. Порт открывается на прослушивание только в одином процессе. Правда может разумнее не пулять в остальные процессы Гудвин(47 знак., 16.01.2014 16:17)
        
        Кстати да. Избежать лишнего копирования больших объёмов данных вообще. В одном процессе ручками таки сделать пресловутый буфер и расшарить память между всеми процессами. Как все дочитали (или как там нужно?) каждый пинает (через мессаги и т.п.) fk0(55 знак., 17.01.2014 00:24)
        
        Фишка в том, что "главного" процесса кагбэ нету - есть отдельные самодостаточные приложения, которые могут запускаться независимо в нескольких экземплярах одновременно на одном компе - MBedder(17.01.2014 00:46)
        
        что-то мне напоминает старый добрый NetCat с "|" - Vit(17.01.2014 01:02)
        
        А поподробней можно? - MBedder(17.01.2014 02:44)
        
        оно прямоугольное. нюхает порт и когда услышит может поднять чего надо (например cmd - в виндовом nc ключик -e). ну и как обычно можно перенаправить поток нужной программе. Vit(256 знак., 17.01.2014 03:02, ссылка, ссылка)
        
        Поднять чего надо: это, скорей, inetd. - fk0(17.01.2014 09:55)
        
        А когда уже поднято? - MBedder(17.01.2014 11:18)

Средства и методы разработки