Answer: We expect the group members work together and discuss the specific implementation of the algorithm for the project problem. There should be a common part in the report explaining the approach used to solve the problem. This part will be graded adding to the score of both group members.
All the remaining data, that is, implementation details, source code, demo performance and simulation results will be graded separately for each group member.
What is the 'running times' mentioned in the simulation results?
Question: What do you mean by collecting running times for the tellers. Is it logical or physical time?
Answer: The running time of a simulation is the physical hardware time that is elapsed between the inialization of the tellers, until successfull termination. You can take the average of all tellers for a run.
There is a java.lang.System.currentTimeMillis() function in Java to get the system time, similar functions exist for other programming enviroments. Also the time command in UNIX measures the running time of its argument, e.g. 'time java Teller'.
What is the point in measuring times for variable number of tellers and accounts?
Question: Isn't it obvious that the more tellers we have the longer the running time? And it seems like having different number of accounts will not effect the performance of my algorithm. Then why run these simulations?
Answer: By running the program with variable parameters we seek to understand the scalability of the solution that we have provided to the problem. Assuming a real world scenario, we have to test our solution to see the time complexity of our algorithm.
The nature of the problem is such that increasing the number of tellers and the number of accounts may have impact on the performance of the system. If your results does not show any advantages, you can discuss what changes to the algorithm might have improved the performance in the parameter studies conducted. Particularly there exist ways to improve the performance of this problem with a modification of Lamport's algorithm.
Note about grading: Showing improved performance or discussing ways to do it will add up to the quality of your report, but no specific points are allocated for it. However, you will be graded for providing simulation results.
When is the code freeze?
Question: When is the last date to change the code?
Answer: At your scheduled demo time, you are responsible for the code contained in the hardcopies you have turned in with the report. In case you have made changes since then, you should provide a changes report at demo time.
Where should we keep the source code?
Question: Is there a special place that we have to put the source files of the code, or do we have to set file permissions for the TA to read our files?
Answer: No. The TA will take a copy of your source files during the demo.
How to create random transactions?
Question: Is it ok if I make input files containing random transactions for this part? I don't want to change my program.
Answer: No. Simulation results will not be relevant if you use input files. This is because they contain scheduled times for each transaction.
However, it is actually straightforward to create random transactions. You just have to create transactions one after the other in a loop, for example ten times. You have to randomly determine the accounts to execute the transaction and an amount to transfer. You don't have to create timestamps for transactions. Especially, your program should not have idle waits.