<< Home

Analysis of simulator components and implementation vs. performance

After analyzing the performance of the simulator, we’ve concluded that we don’t need to use threads in the processing of GPS events and Cleanup events, because these operations are not computationally intensive. Another important reason for taking this decision is that are these events are not directly linked to an event coming from a certain location, so the location is irrelevant.

The GPS events are used to find out the new position of a vehicle. The GPS Event is scheduled at a regular time interval for each node thus accurately simulating the way a real VANET application collects GPS data periodically. The Cleanup events have the role of cleaning the database of records. Every car holds a trafficDB with records of the type CarInfo. Each CarInfo has an expiration time and the processing of a CleanupEvent iterates through the database and deletes the old records.

These events are processed by the main thread in the engine of the simulator.

For the other 2 types of events we use separate processing threads. These are the most numerous events and the time spent to process these events is the biggest.
The engine first starts with an empty event queue. At the moment zero a GPS event is added to the queue: eventQueue.add(new GPSEvent(0)); At the moment one a Cleanup event: eventQueue.add(new CleanupEvent(1)); Then some standard Send events are scheduled.
This is done in the initialization area so when we start the simulator there will be events to process and while processing these events new ones are generated and scheduled.

In the method playEvent the events corresponding to the current time are extracted from the queue (e = eventQueue.remove(0) ;) and then processed. The type of event is determined and specific processing is done.

For example for a GPS event we must update the information for each car and then create and schedule the next event:

Iterator<SimulatedCarInfo> it = cars.iterator();

while (it.hasNext()) {

SimulatedCarInfo r = it.next(); r.update();

} GPSEvent newEvent = new GPSEvent(crtTime + fps); schedEvent(newEvent);

Another example: when the method simulateCommunication() is called for a send event, receive events are created and scheduled for all the vehicles in the wireless range of the sender.

Generally the processing of an event consists in the determination of its type and then the execution of specific actions, followed by the creation and planning of the next events (method schedEvent).

Ideas for parallel computation

1. First, we can have a simple "work" for simulator: we said that we don't need to use threads in the processing of GPS events and Cleanup events, so we'll have a queue for these types of events. And also, it would be another 2 queues: each one for a type of event - Send Event and Receive Event.

Three queues, each queue assigned for a processor. Each queue is assigned to a processor, so we'll have 3 processors. Is a good step to divide the work, but is not enough. Presume that we have more processors, we can use them.

2. Another approach is to assign a processor to each road. In VANET simulators (and also, in real world VANETS), cars are processing messages. So, we can say that messages are computed on the road. On each road are messages interchanges and computation events. There will be as many work-pools as roads. Each work-pool will have all the messages that are computed on the same road. GPS Events and Cleanup events will be computed on another work-pool, by a single processor.

3. The third idea, and the best from all three is to assign a processor to an intersection. Most of messages interchanges are on intersections. So most of Send or Receive events will be close to intersections. So, a work-pool is assigned to each intersection. Events that happen between two intersection, will be assigned to the closest one (easy to compute that using GPS coordinates). Again, we will have a special processor for GPS and Cleanup events.