Intro
The intended audience of this thread is for those FOG admins who have one or more models of computers with slow imaging rates, where otherwise most of their campuses are imaging at a normal rate. The “normal rate” is a bit of a moving target because FOG imaging relies on a health network, well managed FOG server and modern target computers.
The easiest bench marking method a FOG admin has to access is the speed rating listed on the blue partclone screen, seen during imaging. This rating is measured in data volume per minute of transfer. We need to be mindful that this “speed rating” is a composite score of the entire imaging process and not specifically network throughput. This composite score is the combination of the fog server moving data to and from the network interface (plus) network throughput (plus) target computer ingest and image decompression in memory (plus) the target writing the expanded image to local storage media. Any one of these components not functioning optimally will cause a lower than “normal” score in partclone.
<Editor note: add in screen shot of partclone screen during imaging>
Some FOG admins equate this partclone score directly to network throughput. This an incorrect assumption. I’ve seen comments like “I’m getting partclone speeds faster than physically possible with my network, how is that possible?”. In this case the poster was getting 8.2GB/min according to partclone over a 1GbE network. A 1GbE network has a theoretical throughput of 7.5GB/min, yet the poster was seeing 8.2GB/min according to partclone. As I mentioned earlier the partclone score is a composite score of the entire process, where network throughput is only one component. So that 8.2GB/min score is telling me the poster’s network is running very well in that the target computer is receiving the image at a rate to keep the input buffer full and the target computer is performing well in that it is ingesting, decompressing the image, and writing the image to local storage at top speed.
I can speak for the benchmarks I see on my campus. I do have to mention a caveat here in that on my campus I don't use the FOG Client, so from this perspective my FOG server is only used for imaging and not for system management. The FOG Client adds its own overhead to the FOG server that may skew your results if you have a large campus with all target computers running the FOG client.
For a well managed pure 1GbE network with a modern (contemporary) target computer, I typically see 6.1GB/min score in partclone. Using our enterprise infrastructure with a 10GbE core network we typically see 13GB/min score on the target computers. Just to contrast this, my FOG-Pi3 server on a 1 GbE network I’ve seen 5GB/min partclone scores. The point is the FOG server has minimal impact on FOG imaging rates. All of the heavy lifting (so to speak) during imaging is done by the target computer. To say it a different way, the target computer performance has a bigger impact on imaging than the FOG server.
One thing I need to point out here is that as you read through this thread be mindful of the unit of scale being used. Some tools report out in bits per second, others in Bytes per second, and others in MB per minute. I will try my best to keep everything straight myself. For example for a 1GbE network that is 1 gigabits per second, or 125 Mega Bytes per second or 7.5 gigabytes per minute. They all mean the same speed but at a different unit of time.
The remainder of this thread is going to assume your campus is imaging at your normal speed except one specific model of computer. We will go through the steps to try to determine which leg of imaging is causing the partclone score to be lower than expected.
This thread is based on the work I did several years ago in this thread: https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast We will take some of the lessons learned in that thread and apply them below.
Target system setup for testing
- Register your target system with the FOG server. If you can’t use the built in registration process, manually register the target computer with the FOG server.
- Connect the target computer’s configuration to an image definition.
- Schedule a debug capture/deploy (doesn’t matter which). Before you hit the Schedule Task button, tick the Debug checkbox then schedule the task.
- PXE boot the target computer into FOG. You will see several screens of text on the target computer that you need to clear using the Enter key. At this point you should be at the FOS Linux command prompt.
- Follow the testing procedures below.
For tips on remote debugging the target computer check out this link: <Editor note: add in link to remote debugging article when its written>