Changes between Version 3 and Version 4 of SwapInTricks

Timestamp:

Aug 1, 2012 4:43:48 PM (12 years ago)

Author:

sunshine

Comment:

--

SwapInTricks

@@ -1 +1 @@
 During node allocation process testbed performs several checks to identify resources that best meet the needs of your experiment. Constraints that you specify in your NS files may prevent testbed from finding suitable nodes even if the total count of "pc" nodes is higher than what your experiment has requested. Here are some ways in which you can increase your chance of a successful swap in. Apply these tips whenever possible, i.e. whenever your experiment does not explicitly require you to impose constraints that go against these tips. Even if you must impose constraints for ''some'' nodes, do not do this for ''all'' by inertia. Only use constraints where you absolutely need them.
 
- * '''Use links with x*1000 Bps limits''' - these limits can be enforced by the switch and do not require additional traffic shaping nodes to be inserted into your topology. 
- * '''Use links with no drops''' - any links with drops require additional node to be inserted into your topology, thus increasing your required node count and reducing your chance of swap in.
- * '''Use supported operating systems''' - these OS are supported on all our nodes. Other OS, including custom OS built a few years back, are supported only on a fraction of our older node types. Thus it may happen that we have free nodes, but none supports your desired OS. To see the list of supported OS go to xxxx.
+ * '''Use links with 1, 10 or 100 Mbps limits''' - these limits can be enforced by the switch and do not require additional traffic shaping nodes to be inserted into your topology. 
+ * '''Avoid using 1GB links''' - Our nodes are hosted on several switches. Sometimes the testbed cannot allocate all your nodes on one switch, and must spread them across multiple switches. This means that some of your links will be "interswitch" links. Our interswitch bandwidth is limited to a small number of GB. If you use 1GB links you are running the risk of overloading it and the testbed will refuse such allocations that overload interswitch bandwidth. Large topologies especially run this risk when our testbed is close to being full. 
+ * '''Use links with no drops or delays''' - any links with drops or delays other than those specified in the first bullet require additional node to be inserted into your topology, thus increasing your required node count and reducing your chance of swap in. If you need these, consider end node traffic shaping https://trac.deterlab.net/wiki/linkdelays
+ * '''Use supported operating systems''' - https://www.isi.deterlab.net/showosid_list.php shows the list officially supported OS images. These are supported on all our nodes. Other OS, including custom OS built a few years back, are supported only on a fraction of our older node types. Thus it may happen that we have free nodes, but none supports your desired OS. 
  * '''Avoid specifying node types''' - this will ensure that the testbed attempts to match ''any'' free node to your experiment, instead of just those free nodes that have the type you specified.
  * '''Avoid having nodes with more than 4 neighbors in your topology''' - most of our nodes have 4 experimental interfaces, a few have 9. If most or all of your experimental nodes have 4 or less neighbors they can be matched against any node of type "pc".
- * '''Avoid using 1GB links''' - our nodes are hosted on several switches. Sometimes the testbed cannot allocate all your nodes on one switch, and must spread them across multiple switches. This means that some of your links will be "interswitch" links. Our interswitch bandwidth is limited to a small number of GB. If you use 1GB links you are running the risk of overloading it and the testbed will refuse such allocations that overload interswitch bandwidth. Large topologies especially run this risk when our testbed is close to being full.