Changes between Version 12 and Version 13 of ClonezillaInfo

Timestamp:

Oct 30, 2013 3:38:44 PM (11 years ago)

Author:

gerow

Comment:

--

ClonezillaInfo

@@ -80 +80 @@
 }}}
 
+Also, for frisbee we had to manually tell it the bandwidth between our nodes (1Gbit) in order to get it to perform comparably.
+
 These tests rendered the following data:
 
@@ -96 +98 @@
 === Analysis ===
 
-Interestingly enough, it seems that the multicast protocols are our bottleneck in this case, unlike how in frisbee's usenix paper they described the bottleneck to be disk I/O. The paper was published in 2003 so it really is no surprise that things might have changed since then.
+It seems that using Clonezilla doesn't provide any increased performance over the current frisbee/imagezip solution. Clonezilla is, of course, used by many more people and would be better supported than Clonezilla.
 
-So using imagezip and using udpcast instead of frisbee saved us 254.36 seconds (4 minutes and 15 seconds) on average, which as a percentage of the total time it takes to prepare a node might be significant. In addition, using partclone and udpcast instead of imagezip also saves us 36 additional seconds.
-
-== Ways to Potentially Integrate Into Deterlab ==
-
-Clonezilla is a rather large collection of things, and while replacing the current Pxe boot system with it is possible, it may not quite be worth the effort.  What may be worth the effort, though, is doing something about the multicast system/image format.
+While doing these tests, though, I noticed that it seems that the maximum bandwidth frisbee is allowed to use is limited to 72Mbit/s.  Since there are at least gigabit links to the nodes this could be improved by setting the limit higher or by adding a kind of congestion avoidance layer into frisbee.