Различия в частоте кадров и соединения UDP

Question

Я пишу приложение Kinect WPF на C # для отправки команд жестов приложению aLinux C ++.

Моя проблема в том, что когда частота кадров приложения Linux падает ниже Kinect (25fps), он начинает регистрировать команды невероятно медленно,Ротация произойдет примерно через 5 секунд после отправки информации.Исходя из этого, я чувствую, как будто он очищает некоторые очереди пакетов очень медленно, так как они создаются для резервного копирования.

Частота кадров падает из-за повышенной сложности модели, отображаемой на стороне Linux.

ВВ каждом кадре рендеринга я проверяю, были ли получены какие-либо пакеты в течение примерно 1 мс через select () и recvfrom (), а затем анализирую его.Затем обновляется сценарий для всего мира.На стороне Kinect при скорости 25fps отправляются пакеты данных жестов по мере их распознавания.

Почему существует серьезная задержка, поскольку Linux FPS

Кроме того, каковы возможные решения для уменьшения этой задержки?

Я думаю, что задержка вызвананеспособность Linux обрабатывать все отправляемые пакеты, поэтому пакеты помещаются в очередь.Однако я не уверен, почему до сих пор не происходит никаких обновлений в течение нескольких секунд, несмотря на то, что он технически считывает 1 пакет на кадр.

Вот фрагмент кода.

(выполняется один раз для каждого кадра)

  tv.tv_sec = 0;
  tv.tv_usec = 1*1000

      //BLOCKING 1ms  
  retval = select(sfd+1, &fds, NULL, NULL, &tv);

  if (retval < 0) {
     perror("select");
  } else if (retval) {
     int n = recvfrom(sfd, recvbuf, 1024, 0, (struct sockaddr *)&caddr, &len);
     parse_command(recvbuf);
  }

// После этого он начинает обновлять / преобразовывать мир / сцену

Спасибо!

Answer 1

Каковы возможные решения для уменьшения этой задержки?

Очень простой способ - использовать пакеты подтверждения. Отправьте кучу сообщений (до выбранного порога, например, за 1 секунду). Пока пакеты подтверждения получены, вы будете продолжать отправлять пакеты данных о том, что происходит на Kinect. Если вы не получите никаких подтверждений (так что ваше приложение Linux немного отстает), то вы будете отбрасывать данные до тех пор, пока они не нагонят (и вы узнаете об этом из-за пакета ACK).

Почему существует серьезная задержка, поскольку Linux FPS

Это связано с тем, как ваш код и как вы его выполняете. Без какой-либо информации о вашей функции parse_command() мы не будем знать, что. Да, вы выполняете все команды, но вы выполняете их слишком долго. При 25 кадрах в секунду у вас есть 40 мс, прежде чем вы начнете видеть отставание. В течение этого времени вам нужно выполнить всю вашу работу, разбирать, обрабатывать и ваши команды.

Я думаю, что задержка вызвана неспособностью Linux обрабатывать все пакеты отправляются, поэтому пакеты ставятся в очередь. Однако я не конечно, почему до сих пор нет нескольких секунд обновлений технически чтение 1 пакета на кадр.

Пожалуйста, не делайте предположений о программном обеспечении (или вообще о чем-либо), не проводя каких-либо исследований и не предоставляя убедительных доказательств. Linux вполне способен получать большие объемы данных по сети. На самом деле, он очень производительный и может получать гигабиты данных одновременно. Проблема в коде на стороне клиента, а не в ядре.