Selbstauslösung ist langsam in OMNet ++

Question

Ich erstelle meine eigenen verkabelten Simulationsmodell, wo Knoten geschichtete Architektur haben.

Anwendungsschicht erzeugt periodisch Pakete planen dann selbst

scheduleAt(simTime() + 0.00000000625,AppModuleSelfTrigger); 

Dieses Paket wird dann unter Verwendung von in der nächst niedrigeren Schicht Modul gepuffert. Das untere Schichtmodul überprüft dann diesen Puffer periodisch auf Pakete. Ich Erreichung dieses Ziels durch diese Schicht Modul Terminierung als auch mit

scheduleAt(simTime() + 0.00000000625,LowerLayerModuleSelfTrigger); 

ähnlicher Weise alle unteren Schichten, die Puffer verwendet, ich Triggern sie ebenfalls in regelmäßigen Abständen selbst auszulösen und prüfen, ob alle gepufferten Pakete zu senden.

Dieser Ansatz funktioniert gut. Wenn ich jedoch die Verzögerung (0.00000000625) weiter reduziere, dann werden die GUI-Paketflussnähte langsam (z. B. nachdem ich ein Paketflussereignis sehe, muss ich sehr lange warten, um den nächsten Paketfluss in OMNe ++ GUI zu sehen). Aber wenn ich diesen Verzögerungswert erhöhe und stattdessen einen höheren Dezimalwert verwende, z. 0,2, dann scheint das GUI-Paket fließt Ereignisse schnell (und ich muss nicht viel warten, bis das nächste Paket in der GUI zu sehen).

Aber das Problem mit der Einstellung dieser Verzögerung zu höheren Werten wie 0,2 erhöht die Paketlatenz (gemessen als simTime() - PacketCreationTime).

Also, ich bin im Zweifel, wenn ich den gesamten Prozess der Selbstauslösung richtig verwende oder ich muss einige signifikante Verbesserungen vornehmen.

Answer 1

Ein Ereignis alle 6,25-9 Sekunden einzuplanen, um Änderungen im Puffer abzufragen, erscheint als eine suboptimale Möglichkeit, ein Simulationsmodell zu strukturieren. Nimmt man sieben Schichten pro Host an, würde man über eine Milliarde Ereignisse pro Sekunde pro Host verschwenden, nur um sicherzustellen, dass der Puffer tatsächlich unverändert ist. Obwohl jedes Ereignis nur wenige CPU-Zyklen für die Verarbeitung kostet, summieren sich die Dinge schnell.

Ich würde empfehlen, Ihre Simulationsmodelle so zu schreiben, dass sie die Tatsache nutzen, dass sie kennen, wenn sich der Puffer ändert. Im Simulationsmodell muss nicht abgefragt werden.

Zum Beispiel gehen wir davon aus, eine Schicht modellieren, die 10 ms nimmt ein Paket zu verarbeiten und dass seine Pufferstaat polls alle 5 ms. Angenommen, ein Rahmen erreicht zum Zeitpunkt t = 3 ms einen leeren Puffer. Zu diesem Zeitpunkt können wir sofort berechnen, dass der Rahmen bemerkt wird, wenn der Puffer als nächstes abgefragt wird (bei t = 5 ms) und 10 ms später gesendet wird (bei t = 15 ms). Um diesen Prozess zu modellieren, muss also nur ein "Frame gesendet" -Ereignis bei t = 15 ms eingeplant werden. Wir mussten nie abfragen.