= 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 = Performance = == 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% || || || ''assign'' failed, ''assign+'' succeeded, ''assign'' succeeded with fixed nodes from ''assign+'' || 666 || 0.6% || || || ''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. ||