измерение задержки между процессами на окнах

Question

Я встраиваю измерение задержки в промежуточное ПО связи, которое я строю.У меня это работает так, что я периодически отправляю пробное сообщение из моих издательских приложений.Подписывающиеся приложения получают этот зонд, кэшируют его и отправляют эхо-сигнал обратно в любое время по своему выбору, отмечая, сколько времени сообщение находилось «в режиме ожидания».Подписывающееся приложение получает эти данные и рассчитывает задержку как (now () - time_sent - time_on_hold) / 2.

Это работает, но цифры сильно отличаются (3х), когда «время ожидания» больше, чем0. Т.е., если я немедленно возвращаю сообщение, я получаю около 50 мсек в моем dev-окружении, и если я жду, затем отправляю сообщение назад, время переходит к 150 мс (хотя я не принимаю во внимание то время, которое было на удержании).Я использую QueryPerfomanceCounter для всех измерений.

Все это в одной коробке Windows 7.Что мне здесь не хватает?

TIA.

Answer 1

Немного больше информации. Я использую следующее для измерения времени:

   static long long timeFreq;

   static struct Init
   {
      Init()
      {
         QueryPerformanceFrequency((LARGE_INTEGER*) &timeFreq);
      }
   } init;

   long long OS::now()
   {
      long long result;
      QueryPerformanceCounter((LARGE_INTEGER*)&result);
      return result;
   }

   double OS::secondsDiff(long long ts1, long long ts2)
   {
      return (double) (ts1-ts2)/timeFreq;
   }

На стороне публикации я делаю что-то вроде:

Probe p;
p.sentTimeStamp = OS::now();
send(p);
Response r = recv();
latency=OS::secondsDiff(OS::now()- r.sentTimeStamp) - r.secondsOnHoldOnReceiver;

А на стороне получателя:

Probe p = recv();
long long received = OS::now();
sleep();
Response r;
r.sentTimeStamp = p.timeStamp;
r.secondOnHoldOnReceiver = OS::secondsDiff(OS::now(), received);
send(r);

Answer 2

Хорошо, я отредактировал свой ответ, чтобы отразить ваш ответ: извините за задержку, но я не заметил, что вы уточнили вопрос, создав ответ.

Похоже, что функционально вы не делаете ничего плохого.

Я думаю, что когда вы распространяете свое приложение вне условий локального хоста, дополнительные 100 мкс (если оно действительно приблизительно постоянное) станут незначительными по сравнению со средней задержкой работающей сети.

В целях ответа на ваш вопрос я думаю, что существует проблема планирования потоков / прерываний на стороне сервера, которую необходимо исследовать, так как вы, похоже, не делаете на клиенте ничего, что не учитывается.

Попробуйте следующий тестовый сценарий:

• Отправьте два зонда клиентам A и B. (все localhost)
• Отправьте зонд «Клиенту Б» через одну секунду (или Х / 2 секунды) после того, как вы отправите зонд клиенту А.
• Обеспечение того, что «Клиент А» ждет две секунды (или Х секунд), а «Клиент Б» ждет одну секунду (или Х / 2 секунд)

Идея состоит в том, что, как мы надеемся, оба клиента отправят свои тестовые ответы примерно в одно и то же время и оба после сна / ожидания (выполняя действие, которое выявляет проблему). Цель состоит в том, чтобы попытаться получить ответ одного из клиентов, чтобы «разбудить» издателя, и посмотреть, будет ли следующий ответ клиента обработан немедленно.

Если один из этих возвращенных зондов не показывает аномалию (скорее всего, второй ответ), это может указывать на тот факт, что поток издателя выходит из цикла ожидания (в первом ответе) и немедленно доступен для обработки второго ответа.

Опять же, если окажется, что задержка в 100 мкс примерно постоянна, она составит + -10% от 1 мс, что является периодом, подходящим для условий сети реального мира.