Code resides in assign+ branch of the repository, in assign+ folder. There are three files:
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+.
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:
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. |
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. |
The image above shows the ratio of time taken by assign+ vs assign on y axis vs time taken by assign+ on x axis. Values of y smaller than 1 are better. We can see that the ratio varies a lot for short times, e.g., under 10 seconds. Sometimes assign is better and sometimes assign+. As we go to more complex topologies that take longer to allocate assign+ becomes decidedly better, often taking 1/10 of the time that assign needs. In the extreme this is 1 minute for assign+ vs 10 minutes for assign.
The image above shows the ratio of the nodes allocated by assign+ vs assign on y axis vs number of nodes allocated by assign+ on x axis. All values are very close to 1 indicating that both algorithms allocate similar numbers of nodes for a given topology.
The image above shows the ratio of number of interswitch links allocated by assign+ vs assign on y axis vs total number of interswitch links allocated by assign+ on x axis. Values of y smaller than 1 are better. We can see that the ratio varies a lot for a small number of links, e.g., under 30, although often assign+ is much better than assign needing 10-100 times fewer interswitch links. As we go to more complex topologies with more links assign+ becomes decidedly better, often allocating 1/10 or 1/5 of the links as interswitch, compared to assign.