Hi all,

I promised an update with our new Precision T3500 server, however I’m experiencing a few little niggles that have distracted me from the overall performance of the server so far, and I’m hoping somebody here can shed some light on them.

These queries are now completely different to the original post title, so please let me know if you would like me to create a new topic.

The first thing I have come across which is rather strange, is that a Full Host Registration and Inventory will not create a deploy task when asked to. So I type in the Host name, and the image ID I want assoiating with the host, I skip all other parts by hitting enter as they don’t apply to us, and then when asked if I want to deploy now I hit “y” and then enter the username and password. I notice it saying, “Done, with imaging”, and it also says
“Attempting to register host…
Host already registered as %Host name I just specified%”. (I’m not sure if it always says this or not even when working normally)
It definitely hasn’t already been registered, I even cleared all the hosts off the server and tried again. This also happens when trying the Quick Host Registration and Inventory (Yes, I have ticked the box to autopopulate and selected a default image on the Web UI).
The only way I can get a host to image is by selecting the “Deploy Now” function on the PXE boot menu. This is of course a very quick and useful way of deploying an image to a machine, however the inventory report is extremley useful to us in cases of future technical support issues with that machine.
Does anybody know what could be causing this? It worked fine on the Optiplex 380 server I mentioned previously on this thread, and I am extremely confident I have set up the Precision identically.

The second issue prevents us from doing a memtest on the host machine. It has only happened on 2 or 3 laptops so far (all of them HP), and one of them was eventually able to boot memtest after a BIOS reset.
I have provided a picture of the screen with the error message on below -

Does this make sense to anyone?

Mod Note: This topic has been forked from here:
https://forums.fogproject.org/topic/9039/very-slow-unicast-deploy-when-imaging-2-or-more-machines

@george1421 said in Very slow unicast deploy when imaging 2 or more machines:

Was the image recorded with FOG 1.2.0 or newer or is this an old 0.3x image?

The image I have been using for these tests was captured using the new 1.3.0. I was thinking of transferring our old images to the new server, however I didn’t have much faith in it actually working or at best there would be issues somewhere down the line so I just captured from fresh.
Using an SSD was discussed, and I noticed an old thread here where somebody was thinking about using one, but I don’t think the results were actually shared. Now that you have clarified this for me I believe I will be going down the SSD route. Thanks.

@Wayne-Workman said in Very slow unicast deploy when imaging 2 or more machines:

That speed is not transfer rate, it’s write rate, the speed at which partclone is writing to disk.

Thanks for confirming this. I was getting rather confused after the server was continuing to display this speed after you stated it was not possible!

@Wayne-Workman said in Very slow unicast deploy when imaging 2 or more machines:

I’d recommend you limit your max clients to 2 or 3

That is a good idea. It will be a much better option for hosts to simply wait in line so that they can image at full speed rather than pull the rest of the hosts down. Considering the vast speed increase of 1.3.0 on just 1 or 2 hosts, this will be just as fast, if not faster than our old method on 0.32 anyway.

Many thanks to all of you for your input and suggestions, great help as usual.
Keep up the good work!

Harrison

Thank you again for the replies.

@Tom-Elliott said in Very slow unicast deploy when imaging 2 or more machines:

I’m assuming you’re using “Partimage” for the images then?

As far as I can remember, it is Partimage. I am out of the office now and will not be back until tomorrow (UK time) so will confirm it then. It is just the default imaging software that came with my installation (I installed FOG 1.2 from scratch and then used git pull to update to the latest version). If it does turn out to be this, would somebody be able to point me towards some instructions on how to install it to work with FOG?

@george1421 said in Very slow unicast deploy when imaging 2 or more machines:

I’m still thinking it could be that single sata disk that is causing a problem.

I am also starting to think the same thing. I’ll get the model number for you tomorrow but I can tell you it’s a 160GB Western Digital. Sometimes the performance on these drive can be pretty horrible, and simply running the WD Drive Utilities on the HDD in question can work wonders for drive performance - even when the drive is completely unreadable.

Yes, unit 2 does slowly increase in speed after unit one has finished imaging. Very slowly.

Just to add some confusion to this matter, I am actually going to be building a brand new FOG server for when we move premises in a weeks time. The current one was just a test run really, and wanted to try and iron out any potential problems before we get into our new office. I’ll be using a Precision T3500 with at least 1x Xeon processor in and I’m pretty sure the board is SATA3 too. I’ll be very mindful of the HDD I choose this time around…

I’ll obviously update everyone on progress of the current server and will let you know how the Precision compares once it is built.

Thank you both for your replies, your input on this is very appreciated on this.
So I think maybe I should have done a little more testing on this before posting my original question, as Wayne has suggested.

I have found that these speed issues only occur when “staggering” deployments on multiple machines. Let me explain from the start -

I have tested deploy of a Windows 7 multiple partition non resizeable image to an Optiplex 780 SFF on all deploy stations that we have, just to eliminate a possible faulty Ethernet cable. All stations were fine with speeds hovering around 5.5GB/m - 6GB/m. Also, no pesky 100Mbps switches anywhere on the network - all are 1000Mbps.
I then used 2 identical machines to the one above and used station 1 and 2 to deploy the same image to each machine, one at a time. All results fine, same as the above.
I then imaged them both at the same time on the same stations. While the initial start speed was slightly slower (3.6Gb/m) they eventually got back up to speed by the time the second partition was deploying, topping around 6.3GB/m.
I then added a 3rd machine to station 3, all same specs, same image etc. Again, slightly slow start to begin with but gradually gathering speed up to about 4.7GB/m in the end.

I repeated the process above with all 3 machines, however I “staggered” the deploy task to give around 1 minute between each one before the deploy starts.
This is where the speed issues began.
The first started normally around 6GB/m, but when the second machine started roughly 1 minute later, it was getting no more than 500MB/m for the first 15 minutes of deploying. The third machine started a minute after again, with no more than 350MB/m for the WHOLE deploy.

You both may be thinking this is a rather strange method of imaging and using FOG, but that is just how our routine has always been; air compressor in the machine to remove all dirt/dust, fit the required RAM, HDD, add-in cards etc for the customers requirements, begin image through FOG, then onto the next machine. Rinse and repeat. So by the time you have built the next system and want to image it, the first system is only around half way through its deploy.

I am not sure if FOG was designed to meet requirements of this nature, It’s just odd that our old 0.32 version could handle this routine quite happily.

Now, onto the FOG server specs -
Optiplex 380 SFF
Intel Core 2 Duo E7500 2.93Ghz
6GB RAM
I’m pretty sure it’s SATA2 on that board (correct me if I’m wrong)
I’m not running VM, it’s dedicated.

The old 0.32 server is an ancient Dell Precision 470 workstation, and I’m pretty sure this would have been SATA2 as well, if not lower.

@george1421 said in Very slow unicast deploy when imaging 2 or more machines:

Also how much free RAM does the FOG server have when its fully running (top) will give you an idea here.

I’m not sure how to check this, and I think you may have tried giving me a link here to find out but it hasn’t displayed properly?

Thanks again for your input so far on this.

Server

• FOG Version: 1.3.0-RC-25
• OS: Ubuntu 16.04 LTS

We have recently upgraded our Fog server to the latest version 1.3.0 (previously running 0.32 on Ubuntu 12.04! Old I know, but it worked fine for what we needed) and I am experiencing extremely slow deploy speeds when I image more than 1 machine at a time (between 300MB/M and 800MB/M). I understand that if I add the hosts to a group and assign a Multicast task to the group, then the speeds will be much better, but this doesn’t really tie in well with how we work, and separate unicast deploys on our old Fog server used to work fine with no bottlenecking.

I am just wondering - is this normal? A few factors I suspect could be affecting this:

• Could it be something to do with my current Kernel? I am using the default one at the moment, but maybe somebody knows of a different Kernel which copes better with a few unicast deploys at roughly the same time?

• The image it is affecting most currently is a Windows 7 build with a bit of extra software, and also a recovery partition; so the image type is a "Single disk, multiple partition (non resizeable). It is quite an old image now (around 20GB), and was captured from a deploy from our old Fog server. Perhaps the image is a bit messy and needs re-building?

• Could it be related to the image compression option when initially creating the image? This is a completely new feature to me, so I have been leaving it at the default “6”. Space is not really an issue with our new Fog server, so if I need to pull this value down to “1”, it wouldn’t be a problem.

When the new server was first set and working, I tested a Windows 10 image capture and deploy (the main reason I upgraded to Fog 1.3.0 is for the Windows 10 support as it is becoming much more popular with our customers now) and I was blown away with how quick it was! The capture speed was hovering around 6GB/M and when it was deploying it was topping around 9GB/M. The 10GB Windows 10 image was deployed in 1 minute 12 seconds - that’s crazy fast compared to the old server!

Any ideas or suggestions on this would be greatly appreciated.

I would just like to send a big thank you to @Jaymes-Driver @Tom-Elliott for a previous discussion on setting up DNSMASQ on an (very) old thread. Although I never got around to setting it up 100% on the old server, I am happy to say it’s working perfectly on my new server. I revisited the old thread a few times recently, and with your guidance and suggestions I was able to get it going. Many thanks once again!

Well I promised an update so here it is.

Unfortunately after following your precise instructions and steps from the wiki you linked me, it is still giving me the same grief

I think it’s time to give up trying to fix this issue and just do a reinstall.

Many thanks to you both for your time and help, it is much appreciated!

Kind regards
Harrison

Hi Jaymes, thanks for the info.

I did have a look at DNSMASQ last night when researching into what Tom had said on his previous post. Time was getting on a bit, and just reading the word DHCP was making my eyes ache so I gave up in the end. I got as far as installing DNSMASQ through the terminal and creating the ltsp.conf file, but was having difficulty getting the ltsp.conf file in the correct directory due to the permissions on Ubuntu (I have managed to successfully do this kind of thing before in Ubuntu, but time was taking its toll on me and I was starting to get restless whilst trying to figure out/remember the sudo command to do this).

I am currently at work, and life experience is telling me not to touch the work Fog server yet until I have sorted my home server out and am confident in doing it. I’ll have another look at mine tonight and update you on how I get on.

Thank you both for your time patience with me

Hi Tom,

Thank you again for your response. Your advice is very appreciated but unfortunately my network skills/knowledge have hit a brick wall, and although I have read into what you have suggested I still can’t seem to get my head around it
Setting my main DHCP server (which is my router) to know where to get the PXE boot files, I imagine is either logging into my router and doing something in there, or using Ubuntu to tell my router where to look for the PXE boot files (presumably the Fog server IP address).

I may not be making much sense here so how about this -

If I back up my image files now and decide to upgrade to a more up to date Fog version, can I choose “no” for the DHCP server on Fog, and my main DHCP will be configured automatically? (I have a feeling this is wishful thinking).

Am I right in thinking it’s better to go for an earlier version than 1.2.0. as this is still a “work in progress”?

Many thanks

Hi Tom,

Thank you for the sudo command, you were very close too! I found that you had to add “-server” to the end of it, so in full it was -

sudo apt-get remove --purge isc-dhcp-server dhcp3-server

This seems to have done something, as my Fog server at home never used to be able to get internet access and now it works!
The only issue now, is that when I try to PXE boot a machine I get the “no boot filename not received” error. I get the feeling that Fog is still trying to use it’s own DHCP server which is now not there anymore, so it is timing out and giving that error message.

I could be completely wrong though…

Thanks again for your reply Tom,

Looking back at it now, it does seem pretty obvious about the DHCP server and that I should have selected “no” during the installation. This is what you get for blindly following a tutorial without concentrating fully on what it was asking me to do.

OK, so my solution for this would have been to backup my image files and format/reinstall the Fog server and selecting “no” to the DHCP during the install, but you mention uninstalling the DHCP server instead. How would I go about doing this? Can I do it though the Fog dashboard interface, or will I have to go through the Ubuntu Terminal using sudo commands etc?

I am most appreciative of your time and information so far Tom, so if I have just opened up a can of worms asking how to uninstall Fogs DHCP please just tell me and I will just go through format/reinstall route instead - I honestly don’t mind.

Thanks again