#omnet #inet
#omnet #inet
Вопрос:
Я использую omnetpp 5.6.2 и inet 4.2.0 и некоторый самописный код для имитации алгоритмов затопления и сравнения их с простым затоплением. Для этого я настроил исследование параметров с сетками хостов в диапазоне от 3×3 до 9×9. Однако, когда я настраиваю пакетное выполнение, которое выполняется через все три алгоритма, все сетки и разное количество соседних узлов плюс пять разных начальных значений для генератора случайных чисел, файлы результатов начинают путаться.
Я запускаю симуляцию самостоятельно со следующими параметрами: Маршрутизация: многоточечная ретрансляция Расстояние между узлами: 700 м Размер сетки: 8×8 Начальный набор: 0
Я измеряю максимальную задержку между отправленным кадром и последним получившим его узлом, которая должна составлять около 200 мс, учитывая, что каждый узел повторно отправляет со случайной задержкой от 0 до 15 мс.
Я получаю следующий вывод в файле .sca:
attr seedset 0
param **.IIntelliFloodModule.typename ""MultipointInria""
param **.separationX 700m
param **.separationY 700m
...
scalar EightByEight.globalSeqNumListener #maxDelayMs 208.496
Однако, если я запускаю ту же самую симуляцию в пакете симуляций, это дает мне следующие цифры:
attr seedset 0
itervar Routing ""MultipointInria""
itervar netw EightByEight
itervar sepX 700m
itervar sepY 700m
param **.IIntelliFloodModule.typename ""MultipointInria""
param **.separationX 700m
param **.separationY 700m
...
scalar EightByEight.globalSeqNumListener #maxDelayMs 285916.716
Что вообще не имеет смысла, поскольку в сетке 8×8 кадр должен проходить с максимальными 15 узлами до последнего, что, даже если каждый узел передает после максимального времени ожидания 15 мс, будет 15×15 мс = 225 мс.
Вся остальная статистика в этом файле полностью перепутана и не имеет смысла. Каждый пакетный запуск запутывается подобным образом, и всегда есть по крайней мере двадцать или около того запусков, которые вообще не имеют смысла. Однако, если я запускаю их по отдельности, числа снова приобретают смысл.
TL; DR Запуск моделирования в пакетах приводит к путанице с выводом.
Я ничего не нашел по этому вопросу в Интернете, я прочитал руководство и руководство пользователя вверх и вниз, и я действительно надеюсь найти ответ на этот вопрос здесь, поскольку мне нужно это моделирование для моей бакалаврской диссертации, а выполнение 210 запусков по отдельности — невыполнимая задача. Разделение на более мелкие прогоны также невозможно, поскольку способ, которым я намерен оценивать данные, займет намного больше времени.
Комментарии:
1. Совместное использование воспроизводимого примера может помочь сообществу помочь вам.
2. Я ценю ответ, однако проект состоит из множества файлов, и я не знаю, в чем именно заключается проблема. Каждый файл зависит друг от друга и от среды inet. Поможет ли это поделиться всем проектом или .ini и . Файлы Ned или чем я мог бы поделиться, чтобы помочь делу?
Ответ №1:
Пакетные симуляции — это не что иное, как отдельные симуляции, выполняемые одна за другой, поэтому теоретически шаг в пакете должен генерировать точно такой же результат, как при выполнении только этого сценария моделирования.
Теперь я сказал в теории. В целях оптимизации несколько шагов могут выполняться последовательно, но в ОДНОМ и ТОМ ЖЕ процессе (чтобы избежать накладных расходов на запуск процесса. Это может быть полезно при выполнении большого количества коротких симуляций), однако при этом предполагается, что имитационная модель не содержит ошибок. никаких утечек, неинициализированной памяти и т. Д.
Если у вас неинициализированная переменная, вы можете получить сбой или полностью мусорный вывод.
Если вы работаете с opp_runall
, попробуйте указать -b 1
в командной строке принудительное выполнение каждого запуска в отдельный процесс.