Commit 9c0cd1ec authored by Robert Ricci's avatar Robert Ricci

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!
parent 5d747f01
...@@ -4,56 +4,9 @@ ...@@ -4,56 +4,9 @@
# All rights reserved. # All rights reserved.
# #
If anyone wants to work on any of these, please contact and discuss This is the current TODO list for assign (not in order by priority):
the issues with me (
1. vclass improvements - from calfeld
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
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
2. vclass improvements
Two immediate improvements to vclass come to mind. The first is, Two immediate improvements to vclass come to mind. The first is,
when choosing the type for the first assignment in a vclass use some when choosing the type for the first assignment in a vclass use some
...@@ -72,18 +25,96 @@ Things to do to assign. ...@@ -72,18 +25,96 @@ Things to do to assign.
allow for other choices. allow for other choices.
3. port to a third part SA kit. 2. clean up and
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 There are two possible ways to do this. The first (and probably easiest) is
to it more deeply might be fruitful though. 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
4. rewrite 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 11. put link mappings into stored solutions
the original code is either unused or has been rewritten.
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 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
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment