Code
Code resides in assign+ branch of the repository, in assign+ folder. There are three files:
- assign+
- PURPOSE: reads resource requirements and available resources and finds an allocation with minimum interswitch bw use
- INPUT: two command line arguments ptopfile and topfile. These files are usually produced in the process of resource assignment by assign_wrapper, now called mapper. There are a few other command line options, that should be self-explanatory when you run the code. If you want very verbose output run it with -d.
- OUTPUT: textual output denoting nodes and links and their assignments that can be passed further to resource allocation
- getptopdetail.pl
- PURPOSE: parse a ptopfile into something human-readable. Assign+ also uses this output.
- INPUT: ptopfile
- OUTPUT: human-readable summary of ptopfile
- gettopdetail.pl
- PURPOSE: parse a topfile into something human-readable. Assign+ also uses this output.
- INPUT: topfile
- OUTPUT: human-readable summary of topfile
Testing
Testing code resides in assign+ branch of the repository, in assign+/test folder. There are several files that jointly perform tests that compare performance of assign and assign+.
- removefixed.pl
- PURPOSE: Remove fixed nodes from a topfile
- INPUT: topfile
- OUTPUT: topfile in correct format minus lines that talk about fixed nodes
- makefixed.pl
- PURPOSE: Make a topfile with fixed nodes taken from the output of assign or assign+
- INPUT: output-file-of-assign-or-assign+ topfile
- OUTPUT: topfile in correct format plus lines that enforce fixed nodes and fixed interfaces for links
- parseinfo.pl
- PURPOSE: measure performance of assign or assign+
- INPUT: a file containing output of assign or assign+
- OUTPUT: success or failure of allocation, time the allocation took, number of nodes and interswitch links allocated
- runtests.pl
- PURPOSE: run a number of tests with assign and assign+. The tests we run are the following:
- t1. assign with given ptopfile and topfile
- t2. assign+ with given ptopfile and topfile
- t3. assign with given ptopfile and modified topfile to remove fixed nodes
- t4. assign+ with given ptopfile and modified topfile to remove fixed nodes
- t5. assign with given ptopfile and modified topfile to remove fixed nodes, and then include fixed nodes and fixed interfaces from the output of assign+ in step t4
- INPUT: a file containing lines with ptopfile and topfile
- OUTPUT: file testresults that contains performance of these two allocation algorithms for each line of input
- processresults.pl
- PURPOSE: process the results file generated in the previous step
- INPUT: name of the results file
- OUTPUT: statistics about successes and failures of assign and assign+. The code also produces files that contain inputs that lead to following potentially anomalous cases:
- checktests - assign+ failed and assign didn't, i.e. t1 was a success and t2 was a failure
- failedtests - both assign+ and assign failed, i.e. both t1 and t2 were failures
- weirdtests - assign+ succeeded and assign didn't, i.e. t1 was a failure and t2 and t5 were a success
- impossibletests - assign+ succeeded and assign didn't with fixed nodes from output of assign+, i.e. t1 was a failure, t2 was a success and t5 was a failure. This most often happens because assign cannot deal properly with fixed interfaces on links.
Additionally, the folder contains a version of assign I have used in testing, that will run on boss. It also contains two sets of test cases:
- expinfotests - all attempted allocations from start of DeterLab until Spring 2013
- expfailedtests - all failed allocations roughly from Jan 2012 until Spring 2013
Expinfotests
There were total of 109,326 tests. Historically, in real operation some of these allocations succeeded and some failed.
Category | Count | Percentage | Reason
|
Both assign and assign+ succeeded | 98,639 | 90% | n/a
|
assign succeeded, assign+ failed | 98 | 0.1% | In 93 of these cases assign doesn't detect a disconnected switch topology nor oversubscribed interswitch bandwidth, but it should. In 2 cases we overestimate what we need in one vclass. I can fix this issue but it will have to wait. In 3 cases the ptopfile has an error - two interfaces on a physical node are called the same. assign doesn't pick up on this but assign+ does, which should be correct behavior. So effectively in only 2 out of 109,326 assign is better than assign+.
|
Both assign and assign+ failed | 6,341 | 5.8% | n/a
|
assign failed, assign+ succeeded, assign succeeded with fixed nodes from assign+ | 666 | 0.6% | There is a good solution but assign cannot find it in a given number of trials.
|
assign failed, assign+ succeeded, assign failed with fixed nodes from assign+ | 3,580 | 3.2% | This happens because assign cannot properly deal with fixed interfaces. I checked quite a few of these solutions manually and they are possible solutions.
|
Expfailedtests
There were total of 9,861 tests. Historically, all these allocations failed.
Category | Count | Percentage | Reason
|
Both assign and assign+ succeeded | 294 | 3% | assign sometimes fails due to "luck". There is a good solution but it runs out of trials to find it.
|
assign succeeded, assign+ failed | 4 | 0.04% | In one case there was a disconnected switch topology. In other 3 cases assign does not properly check for OS support and ends up assigning nodes that cannot load a requested OS. Thus effectively there were 0 cases in these tests where assign was better than assign+.
|
Both assign and assign+ failed | 9,409 | 95% | n/a
|
assign failed, assign+ succeeded, assign succeeded with fixed nodes from assign+ | 147 | 1.5% | There is a good solution but assign cannot find it in a given number of trials.
|
assign failed, assign+ succeeded, assign failed with fixed nodes from assign+ | 1 | 0.01% | This happens because assign cannot properly deal with fixed interfaces. I checked quite a few of these solutions manually and they are possible solutions.
|