Proteus provides support for both exact and analytical simulation of direct networks (i.e., k-ary, n-cubes, rings, etc.) and purports to support an analytical model for an indirect network which was not readily apparent to us. In this section, the network simulator module that gives the most accurate information about network activity is described to prepare the reader for a discussion of the indirect network module developed during this project.
There are three types of requests used by the network module. The first is a send which signifies that a processor is ready to inject a message into the network. The second type of request is the route request, which computes the next node for a packet and computes the arrival time of that packet at that node. The arrival time is a function of the packet length, current contention (availability) on the channel, switch and wire delays. The last type of request is the receive request which occurs when a packet reaches its destination. It's primary tasks is to dispatch the packet to the message queue of the destination processor.
The most interesting of the three requests types is the route request. The discussion here applies equally to Section 2.2, since we used some of the same ideas. In order to accurately simulate an interconnection network, contention on a particular channel must be taken into account when routing a packet that needs to use that channel. Also, in real ICNs, packet incur a delay of several cycles while cutting through a switch. It can also incur a small latency while traversing a wire. How is the exact simulation done in Proteus' network module? The individual channels (both input and output) are time-stamped by Proteus.
Figure 1: Contention at the output port of a direct network switch
Figure 1 illustrates an example. If a packet
has to be routed from processor P to OP
(to which another
processor is physically connected), it cannot
be routed immediately to that port because it is being
(solid line from IP
to OP
) used by another packet.
So, the packet will see a delay of at least 
, where
LENGTH is the length of the packet in flits, (flow control
bits [3]. Thus the packet
will reach its destination (once injected into the network)
, where 
and 
are the wire and switch latencies respectively.
As stated in an earlier section, Proteus uses an event queue to to simulate the operation of the underlying machine (i.e., communication calls, shared memory accesses, context switches, etc.). Thus, the communication event types discussed above are scheduled on the queue to run at some future time, which is dependent on the traffic in the network. From the example, a receive event would be scheduled at time T to simulate the delay seen by a packet.
In order to facilitate the rapid development of a network module, many of the ideas used the supplied module were used to build our own.