Измерение сквозной задержки с помощью примера приложения pub/sub Paho

Моя цель - измерить задержку сообщений MQTT между устройствами (а не пропускную способность), и я ищу отзывы о моих взломах кода. Настройка проста; только одно устройство, служащее двумя конечными точками (старый Linux-ПК с двумя терминальными сеансами; на одном работает подписчик, а на другом — образец приложения издателя) и брокер по умолчанию в tcp://m2m.eclipse.org:1883). Я вставил фрагменты кода, фиксирующие время, в примеры приложений публикации/подписки на языке C в папке src/samples.

Ниже приведены изменения. Пожалуйста, оставьте отзыв.

Изменения в примере приложения для подписки (MQTTAsync_subscribe.c)

Вставил строки ниже вверху функции msgarrvd (сообщение получено)

//print arrival time
struct timeval tv;
gettimeofday (&tv, NULL);
printf("Message arrived: %ld.%06ld\n", tv.tv_sec, tv.tv_usec);

Изменения в примере приложения для публикации (MQTTAsync_publish.c)

Вставил строки ниже вверху функции onSend (обратный вызов).

struct timeval tv;
gettimeofday (&tv, NULL);
printf("Message with token value %d delivery confirmed at %ld.%06ld\n",
               response->token, tv.tv_sec, tv.tv_usec);

С этими изменениями (после вычитания времени доставки сообщения подписчику из времени, когда доставка была подтверждена издателем), я получаю время где-то между 1 миллисекундой и 0,5 миллисекунды.

Вопросы

Имеет ли это смысл в качестве приблизительного ориентира по задержке?

Это время в оба конца?

Время в оба конца правильное? Должно быть меньше? более?

Это время в один конец?

Должен ли я разработать тест задержки по-другому? Мне нужны грубые измерения (сравниваю с XMPP).

Я использую значение QoS по умолчанию (1). Должен ли я изменить его?

Издателю требуется конечное время для подключения (и отключения). Следует ли их добавить?


mqtt mosquitto paho
person auro    schedule 05.08.2014    source источник
comment
Я перешел от асинхронных примеров приложений (для pub sub) к синхронным примерам приложений и увидел задержку в оба конца 200 миллисекунд. Кто-нибудь может прокомментировать этот номер?   -  person auro    schedule 06.08.2014
comment
Запустите своего собственного брокера, вы понятия не имеете, как загрузить мои изменения на m2m.eclipse.org между каждым запуском, как его средняя нагрузка может сравниться с вашим приложением и, наконец, к какому оборудованию/сети оно подключено.   -  person hardillb    schedule 15.12.2014

Ответы (1)


arrow_upward
0
arrow_downward

Задержка в 200 мс - это много! Не могли бы вы загрузить свой код сюда?

Имеет ли это смысл в качестве приблизительного ориентира по задержке?

-- Да, это имеет смысл. Но лучший подход — сделать автоматическое вычитание времени с подписанным сообщением, и оба синхронизируются с NTP.

Это время в оба конца? Это время в один конец?

-- Сообщения были опубликованы - вы получили ACK для издателя, и то же самое сообщение было передано подписавшемуся клиенту.

Время в оба конца правильное? Должно быть меньше? более?

-- Должно быть меньше.

Должен ли я разработать тест задержки по-другому? Мне нужны грубые измерения (сравниваю с XMPP).

Я использую значение QoS по умолчанию (1). Должен ли я изменить его?

- Попробуйте с QoS 0 (запустил и забыл)

Издателю требуется конечное время для подключения (и отключения). Следует ли их добавить?

-- Да. Его нужно добавить, но это время должно быть очень маленьким.

person surfnerd    schedule 14.12.2014