FOG Imaging Doesn't Respect Max Client Setting
-
We’re in the process of deploying some new computers. In order to save time on the day of the roll out we’re registering and imaging them in advance. In the process we have noticed something odd. If we register the computers with imaging and start several in quick succession, FOG will not respect the max clients setting on the storage node. If you then go to register more computers once the imaging has begun, these clients will wait patiently in line as expected.
We currently have it set to only allow 2 clients at a time. Our server runs Debian 8 in a Hyper-V VM on an older desktop machine (the only spare computer available sadly). Hence the low setting for the storage node. However as I write this, seven computers are imaging at once and not taking much longer than usual. We are using FOG version 1.3.0. It isn’t really a problem for us, but it is odd. Has anyone else noticed this?
-
@MikeoftheLibrary said in FOG Imaging Doesn't Respect Max Client Setting:
If we register the computers with imaging and start several in quick succession, FOG will not respect the max clients setting on the storage node. If you then go to register more computers once the imaging has begun, these clients will wait patiently in line as expected.
That’s normal behavior. There is a check that happens after the kernel and inits are loaded to see if there are available slots or not. If you’re starting many computers all at once, more than the max may start - but once the server adjusts how many slots it has available to zero, then the rest wait. The max clients setting isn’t perfect.
Also, you should consider multicast for what your doing.
-
Thanks for the clarification, Wayne. I had a feeling it was normal, but wanted to make sure. The setting works fine for us. As far as multicasting goes, the last time I tried it, it took 5+ hours for 5 computers. Of course I was using an old gateway to run FOG. But a semi-old Dell desktop repurposed as a server doesn’t seem any more likely to produce better results. However I may experiment anyway.
-
@MikeoftheLibrary said in FOG Imaging Doesn't Respect Max Client Setting:
the last time I tried it, it took 5+ hours for 5 computers.
Multicast performance isn’t really dependent on an awesome server - that’s part of the method. The server only sends one time and many receive.
Your problem is probably poor-quality network equipment you were using for multicast. Higher-end network equipment like Cisco Catalyst would not have these issues. The cheaper the network equipment, the worse multicast will be. It’s total-internal-throughput that matters. If you have an el-cheapo crap 10 dollar switch that is advertised as 1Gbps, it may only have 2 or 2.5Gbps total-internal-throughput. The max it can transmit in and out of all ports simultaneously at any one time. To truly take advantage of multicast, if your 1Gbps switch has 8 ports, it needs 8Gpbs total-internal-throughput. If it’s a 48 port 1Gbps switch, then 48Gbps of total internal throughput.
-
-
@Wayne-Workman said in FOG Imaging Doesn't Respect Max Client Setting:
Multicast performance isn’t really dependent on an awesome server - that’s part of the method. The server only sends one time and many receive.
Your problem is probably poor-quality network equipment you were using for multicast. Higher-end network equipment like Cisco Catalyst would not have these issues. The cheaper the network equipment, the worse multicast will be. It’s total-internal-throughput that matters. If you have an el-cheapo crap 10 dollar switch that is advertised as 1Gbps, it may only have 2 or 2.5Gbps total-internal-throughput. The max it can transmit in and out of all ports simultaneously at any one time. To truly take advantage of multicast, if your 1Gbps switch has 8 ports, it needs 8Gpbs total-internal-throughput. If it’s a 48 port 1Gbps switch, then 48Gbps of total internal throughput.
Networking is the purview of campus IT. However I do know a few things. The closet next to my office has a few Cisco Catalyst 3500 series switches. One was replaced about 18 months ago when the fan quit working. The main switches on campus are connected with fiber optic cable. Everything else is cat5e. There may very well be cat 5 in the walls and coming out of the ethernet ports, but I don’t know for sure. Our work room has a netgear ProSafe GS108 in order to make 2 ports become 9. I also know our network has some sort of traffic shaping system, but whether or not that affects FOG I don’t know. The library public computers (including the FOG server) are on their own subnet with a restrictive ACL. The arrangement prevents our imaging server from interfering with the one campus IT uses. With the exception of the netgear, none of this sounds like poor quality equipment. My feeling is the issue is low quality or old cables combined with a low end server.
-
@MikeoftheLibrary After reading that, there’s another thing I forgot to mention. Each multicast session only goes as fast as the slowest host. So if one of them has bad RAM or a failing disk or bad patch cable, this would slow down every host in that multicast task. This could be your issue - and most likely is since you’re using business grade network equipment.
