What is "check in"？
-
When I tried to deploy 40 PCs with same image, most PCs would continuously show a message like “Attempting to check in. There are open slots, but xx before me on this node (In line for xx:xx)”. It looks like a queue. How can I increase the queue length and specify the timeout?
-
@Maorui2k I think what you are looking for is in FOG Configuration -> FOG Settings -> General Settings. Look for FOG_QUEUESIZE and FOG_CHECKIN_TIMEOUT…
Why don’t you use multicast to send the same image to 40 PCs?
-
Trying to do 40 units at the same time over unicast will be very very slow, slower than doing them in small batches.
Fastest way in your situation is multicast as Sebastian said.
-
It’s not smart to unicast to 40 boxes at once.
FOG’s default queue size is 10. I’ve always changed this to 2 or 3 for better performance.
-
Multicast is not quiet stable in my environment, poor switch performance, so I wanted to try unicast. It seems the multicast is still a better choice, although the time is so varibale, from 5 minutes to 50 minutes.
BTW, I can not find FOG_QUEUESIZE in 1.3.0, and the default FOG_CHECKIN_TIMEOUT is 600, but some nodes waited more than 12 minutes.
-
@Maorui2k said:
Multicast is not quiet stable in my environment, poor switch performance, so I wanted to try unicast. It seems the multicast is still a better choice, although the time is so varibale, from 5 minutes to 50 minutes.
Are you sure it’s the switch causing this issue? I am not saying that it can’t be the problem but I want to stress that for multicast even a single poor client (slow network, dying disk, corrupt memory, …) can cause a slow down for all the other clients. I would start by multicasting the clients in smaller batches like 5 or 8 at a time. Note down the time it takes and redo at least three times. Then compare the times. Do they vary from batch to batch or are some batches fast others slow. Are those all connected to the same switch? It shouldn’t be too hard to locate the troublemaker.
BTW, I can not find FOG_QUEUESIZE in 1.3.0, and the default FOG_CHECKIN_TIMEOUT is 600, but some nodes waited more than 12 minutes.
As well you might look into upgrading to the latest version. A lot changed since the release of FOG 1.3.0…
-
@Sebastian-Roth I think the switch is the problem maker. It’s a low-end product, and I got similar issue when I used Ghost in the past. With Ghost multicast, if not all PCs got multicast packets successfully, these PCs would ask for a retry and slowed down the entire process. I wonder if fog uses similar method.
I cannot switch to 1.4 or later just because of the Linux kernel issue in another thread…
-
@Maorui2k From your description the issue could still be caused by some of your machines instead of the switch being the bottleneck. Again, I am not saying that switch isn’t causing this. Just want to point out that testing PCs in batches doesn’t cost you money (like a new switch would) but only some time.
Multicast in FOG works pretty similar to how Ghost does it. Although back at my old working place we had strange performance issues which we never had using FOG multicasting!