Bug 3024 - delay of RealtimeSimulatorImpl::Schedule() not interpreted as "realtime" delay
delay of RealtimeSimulatorImpl::Schedule() not interpreted as "realtime" delay
Status: NEW
Product: ns-3
Classification: Unclassified
Component: core
ns-3-dev
PC Linux
: P5 enhancement
Assigned To: Peter Barnes
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-11-28 12:44 EST by Taqi
Modified: 2018-11-28 12:44 EST (History)
1 user (show)

See Also:


Attachments
realtime test (1.51 KB, text/x-c++src)
2018-11-28 12:44 EST, Taqi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Taqi 2018-11-28 12:44:11 EST
Created attachment 3233 [details]
realtime test

Current realtime scheduler interrupts its sleep when new events are scheduler, it then assumes those events have passed and directly dequeues and executes the queue head.
Related is the fact that scheduling in realtime measures the delay in relation to current simulation time, but then sleeps for delay measured from initial "real" time. The issue that arises is when too much real time T has passed, after which an event is scheduled with delay t, where t < T, in this case there will be no sleeping at all, the execution of the event is thus instantaneous from the point of view of the "realtime" user.

I don't see how this behaviour could be desired, as a realtime scheduling of an event after t seconds should necessarily imply waiting for as close as possible to realtime t in all cases.

The same issue limits the usage of HardLimit mode, as a simple scheduling of events with same delay (let's say 0) would fail the assertion.

This is an issue can be tested with the attached script.
1- ./test --mode=BestEffort|HardLimit
This provides expected behavior, event schedule for 1000ms and executed after 1000ms "realtime".
2- ./test --mode=BestEffort --sleep=2000
This will schedule an event with delay of 1000ms after Simulator::run() from a second thread after sleeping for 2000ms. The event will be be executed "really" after 1000ms from its scheduling, instead its fired almost instantaneously.
In HardLimit mode, this fails miserably with "Hard real-time limit exceeded".

IMO, a solution could be to not measure scheduling delay relatively to m_currentTs but to m_synchronizer.GetRealtime() (or GetNormalizedRealtime()).