CSE 326, Winter 2001 February 25, 2001 Donald Chinn Notes Concerning Project #3 Here are a few more clarifications and ideas concerning Project #3. **** Clarifications ** Central Queues As we discussed in class, we will use infinite queues at each node to avoid deadlock. This means that there is always enough room in the central queue to accept packets from the injection queue and the in-queues. This also implies that in your implementation, you won't need to have an explicit injection queue or in-queues. Whenever a packet is injected into a node, it can go directly to the central queue. Similarly, any packet transmitted during the "Send" phase of the time step can go directly to the central queue of the adjacent node. ** Random Graphs Recall that we want to run our simulator on a variety of loads, where the load for each type of graph is defined in the handout. For random graphs, we have the problem that we don't know how the graph was generated, so we can't easily compute the probability of injection based on just on the load factor we desire. We also need the probability q that was used to generate the graph. What we do is compute the total number of edges in the graph and divide by the total possible number of edges to infer what the probability was. If d(v) is the number of edges coming out of vertex v (d(v) is called the degree of vertex v), then the sum of d(v) over all vertices v in V, divided by N(N-1) -- the total possible number of edges -- will be our estimate of q. So, to compute our injection probability p, we compute the sum of the degrees of vertices in G, divide it by N(N-1), multiply it by the load and then multiply by N. ** Implemenation Suggestions As the handout says, it is strongly suggested that you create utility routines to allow you to "see" what is going on in a node. This will help you greatly to determine that you are implementing your algorithm correctly and likely will help you figure out how to improve your algorithm. You might also want to write a routine that prints out how many packets there are in every node. Such a routine will help you determine where (and possibly why) congestion in the network is occurring. Note that for the mesh, you can print out such numbers in a square so that it graphically resembles what the network looks like. Do NOT just run your simulator on a bunch of graphs and assume that just because they finish and you get some average delivery time that you have implemented your algorithm correctly. Your numbers mean nothing if the algorithm is incorrect. Make sure packets don't disappear from your network. Make sure packets don't spontaneously appear in the network. Make sure your algorithm matches what you implemented. Finally, as mentioned in the handout, if you use Visual C++ as your main development environment, allow some time (several hours) to port it over to UNIX and compile and test it there. Make sure you get the same results on UNIX as in VC++. ** What to Turn In In the handout, it says to run your simulator on (at least) four different sized graphs. In addition, you are to run it with different loads. The handout suggests 0.2, 0.4, 0.6, 0.8, and 0.9. Instead, do all loads in 0.1 increments up to 0.9. (That is, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, and 0.9.) Explain how you were able to run your program at different loads. (Did you use a #define and recompile each time you wanted to run an experiment with a different load, or did you use a command line argument to specify what load to run your simulator? Or did you do something else?) **** Ideas ** The kinds of information to base routing decisions on You are probably wondering what sorts of information can be used to decide how to assign packets to outgoing edges for each node. Note that the basic algorithms use what is called *static* information to determine how to route packets. That is, the paths are predetermined and do not depend on *dymanic* information, such as how many packets there are in a node or how many packets there are in neighboring nodes. Static information (such as deciding on horizontal first, vertical second or breadth first search) can all be computed once the network layout has been decided. You can imagine that if there are two outgoing edges a packet can take that still bring it closer to its destination, then it might be a good idea to send it to the node that has fewer packets in it, since it presumably will have to wait less time to get out of that node. In devising your algorithms, you might consider using such information in making routing decisions. In "real life", it's reasonable to assume that a node can get such information about itself and neighboring nodes. It's a little more suspect to assume that you can get such information about nodes that are further away (at least two nodes away), because such schemes would require a way to transmit such information to nonadjacent nodes. Please keep these "real world" concerns in mind when you devise your new algorithms. Again, the three main techniques described in the handout -- multiple paths, randomness, and derouting -- are all ideas you can use. What information you use and in what combination the techniques you use are limited only by your imagination.