From 9c0cd1ec86744813090dc143867efeaa1f3eba2f Mon Sep 17 00:00:00 2001 From: Robert Ricci Date: Mon, 14 Apr 2003 18:55:05 +0000 Subject: [PATCH] Brain dump of my current list of things to do to assign. Should be stored in somewhere more permanent than my gray matter and purple sticky notes! --- assign/assign_todo.txt | 149 +++++++++++++++++++++++++---------------- 1 file changed, 90 insertions(+), 59 deletions(-) diff --git a/assign/assign_todo.txt b/assign/assign_todo.txt index 9ed90c873..74944c89b 100644 --- a/assign/assign_todo.txt +++ b/assign/assign_todo.txt @@ -4,56 +4,9 @@ # All rights reserved. # -If anyone wants to work on any of these, please contact and discuss -the issues with me (calfeld@cs.utah.edu). - -Things to do to assign. - -1. multiple switches per node / annealing links - - This may actually not be so hard. Currently assign decides how to - satisfy a vlink deterministically. What we want to do is change it - so that the vlink mappings are chosen semi randomly so that they - become a part of the solution and subject to annealing. When - adding in a node, for each vlink we need to figure out the possible - ways to satisfy it. Possibilities include: a direct link to the - destination, intraswitch links through any connected switches, - interswitch links through any connected switches. Any valid - possibility (one that does not cause violations) should have a - chance of being tried. We may want to weight those with lower - scores (direct over intraswitch over interswitch) so they show up - more often. In a basic sense there is a potential path from src to - dst for every link in the src node. In practice we probably want - to consider identical link as a whole. I.e. a node with two - identical links to one switch and two to the other should really - only have two potential paths, not four. With interswitch links I - would suggest only looking at a single path for each switch the src - node is directly connected to and still use the switch MST to find - routes. For an even more versatile model that could take advantage - of non-tree switch topologies, we would want to choose a route - through the switch fabric semi randomly. - - Example: Let's have A and B be pnodes, and S1, S2, and S3 be - switches connected in a complete graph. A is connected to B, S1, - S2, and S3. B is connected to A, S2, and S3. Our virtual topology - is N1 and N2 connected to each other. N2 is mapped to B when we - map N1 to A. We look at the link between them. Possible paths - are: - direct link A to B - intraswitch link A to S2 to B - intraswitch link A to S3 to B - interswitch link A to S1 to S2 to B - interswitch link A to S1 to S3 to B - for best results we want each of these five possibilities to be have - a chance of being used. For an initial cut, we would try only one - of the two interswitch paths, whichever shows up in the MST. - - Actually implementing this change would involve some serious work on - the add_node and remove_node code and to the various find*path - routines. - - -2. vclass improvements +This is the current TODO list for assign (not in order by priority): + +1. vclass improvements - from calfeld Two immediate improvements to vclass come to mind. The first is, when choosing the type for the first assignment in a vclass use some @@ -72,18 +25,96 @@ Things to do to assign. allow for other choices. -3. port to a third part SA kit. +2. clean up assign.cc and score.cc + + Many monolithic functions, like anneal(), need to be split up, because + they're just too big to comprehend. + + The code is in bad need of commenting. + + All the compile-time options have made a mess of things, so many that are + obviously good things should just be on. Many that are compile-time should + also become command-line options. + + A lot of the 'classes' are just used like structs. They really should have + proper constructors, etc. + +3. add the 'one interface per LAN' restriction + + For jails/vlinks, we need to be able ensure that only one interface on a + node is in a given LAN - this is because you cannot put more than one + interface in the same subnet. Shouldn't be too hard. + +4. clean up top/ptop parsers, change output format + + The parsers are currently very sensitive to syntax and ordering errors. The + output is also difficult to parse, and is error-prone due to its lack of + type information. At the very least, the top/ptop parsers should be + re-written to be more robust. It may also make sense to go to a different + format, one that uses key=value pairs. Or, even, something like XML, for + which there are already standard graph representations and parsers. + +5. add delay node support + + Merge back in Chris's delay node support. + +6. fix PER_VNODE_TT and vclasses + + PER_VNODE_TT is definitely a good thing, but it currently breaks vclasses, so + we can't use it in production. This might be tricky to fix, but is definitely + worth it. This will help to give better error messages when a vnode has too + many vlinks to fit into any of the pnodes. + +7. fix PER_VNODE_TT and emulated vlinks + + PER_VNODE_TT assume that each vlink is going to consume one plink - need to + relax this for emulated links. + +8. prune pclasses when using PER_VNODE_TT + + Right now, we use all pclasses, even those which we cannot possibly use, in + our estimation of how hard the problem is (vnodes*pclasses). With + PER_VNODE_TT, we can do mark-and-sweep 'garbage collection' of pnodes that + it's not possible to map to. Should improve performace. + +9. add features/desires to PER_VNODE_TT restrictions + + PER_VNODE_TT currently only looks at the node type and number of links - it + could also easily look at features/desires with a weight of 1.0, too + +10. add some sort of global allocation strategy + + The idea here is to include other, already mapped, experiments in the top and + ptop files, and give assign the option to unmap existing experiments to fit + a new one in. The idea is that we'll somehow communicate the idle time and + priority of experiments to assign, so that it can try to do the 'least + damage' in decided who to kick out - and, of course, not kick out anyone if + not necessary. - My initial impression is that this would be very tough. Looking in - to it more deeply might be fruitful though. + There are two possible ways to do this. The first (and probably easiest) is + to use features. Give already-mapped nodes a feature with a weight + corresponding to how much we'd like to keep them swapped in. Then, modify + assign to only penalize for the feature once - because, as soon as you've + deprived an experiment of one node, you might as well swap the whole thing + out. -4. rewrite assign.cc + The second (and possibly more correct) way is to use pclasses - this requires + the specification of pclasses in the ptop file, but the 'only penalize once' + tactic falls out naturally, since that's how we already do pclasses. - There's a lot of garbage floating around in that file. Almost all - the original code is either unused or has been rewritten. +11. put link mappings into stored solutions -5. robust parser or top and ptop + The current behavior of re-doing link assignment on a revert is becoming more + and more questionable, since the greedy algorithm it currently uses can + result in worse scores than the original, and possibly even violations in the + reported solution. The solution is to keep the link mappings. But, this + tosses out our 'deterministic' link mapping. Need to decide which of these + things is more important. - The parsing code is extremely intolerant of input errors (it often - crashes). +12. make rejected transitions work more correctly + Currently, rejected transitions can result in something not identical to the + original configuration. This is because we re-do link mappings (see #11), and + don't keep track of any nodes we might have foribly unmapped to try to open + up a mapping for an unassignable vnode. Doesn't seem to hurt anything, so is + low priority -- GitLab