Я прочитал кучу сообщений на SO о вычислении сквозной задержки в Veins, но не нашел удовлетворительного ответа, объясняющего, почему задержка кажется слишком низкой.
Я использую:
Переключение каналов отключено.
У меня есть следующий код, отправляющий сообщение с передающего узла:
if (sendMessage) {
WaveShortMessage* wsm = new WaveShortMessage();
sendDown(wsm);
}
Принимающий узел вычисляет задержку, используя время создания wsm, но я также пытался установить метку времени на передающей стороне. Результат тот же.
simtime_t delay = simTime() - wsm -> getCreationTime();
delayVector.record(delay);
Пример вывода для вектора задержки выглядит следующим образом:
Пункт № Событие № Время Значение
0 165 14.400239402394 2.39402394E-4
1 186 14.500240403299 2.40403299E-4
2 207 14.600241404069 2.41404069E-4
3 228 14.700242404729 2.42404729Е-4
Это означает, что сквозная задержка (от создания до приема) эквивалентна примерно четверти миллисекунды, что кажется довольно низким — и намного ниже того, что обычно сообщается в литературе. Похоже, это согласуется с тем, о чем другие люди сообщали как о проблеме (например, сквозная задержка в венах).
Я что-то упустил в этом расчете? Я попытался увеличить нагрузку на сеть, добавив большое количество автомобильных узлов (21 узел в песочнице 1000x50 на прямом шоссе со средней скоростью 50 км/ч), но результат, похоже, тот же. Разница незначительна. Я прочитал несколько исследовательских работ, в которых предполагается, что сквозная задержка должна резко увеличиваться при высокой плотности движения транспортных средств.
Эта сквозная задержка является ожидаемой. Если имитационная модель вашего приложения явно не моделирует задержку обработки (например, приложением, работающим на медленном компьютере общего назначения), все, что вы ожидаете от задержки кадра, — это задержка распространения (скорость света, поэтому здесь можно пренебречь) и задержка в очереди на MAC (время от вставки кадра в очередь передачи до завершения передачи).
Например, для 2400-битного кадра, отправленного со скоростью 6 Мбит/с, эта задержка составляет примерно 0,45 мс. Вероятно, вы используете немного более короткие кадры, поэтому ваши значения кажутся разумными.
Для получения справочной информации см. Ф. Клинглер, Ф. Дресслер, К. Соммер: «Влияние блокировки начала линии в высокодинамичных беспроводных сетях» (DOI 10.1109/ТВТ.2018.2837157), который также включает сравнение теории с жилами и реальными измерениями.
Обратите внимание, что авторы цитируемой вами статьи не исследуют задержку в очереди. Скорее, они сообщают о количестве миллисекунд, прошедшем между двумя успешно полученными пакетами. Естественно, эта задержка пропорциональна скорости потери пакетов, о чем также свидетельствует соответствие 1:1 графиков задержки и PDR на рисунках 3 и 5. Обратите внимание, что на скорость потери пакетов в этом исследовании негативно влияет параметр рассогласования. выбор (в частности, только для части 11p): отсутствие повторных попыток, а также очень высокая и неадаптивная мощность и скорость передачи с полностью радиопрозрачными зданиями.
Я вижу - это не было сразу очевидно для меня. Большое спасибо за разъяснения!
Это имеет смысл. Спасибо за ответ. Таким образом, пытаясь расшифровать некоторую существующую литературу о сквозной задержке, где сообщаемые цифры обычно выше (например, jwcn-eurasipjournals.springeropen.com/articles/10.1186/…), я полагаю, что это будет при высоких нагрузках и соответствующих высоких задержках в очереди.