Ghost Solution Suite

 View Only
  • 1.  Improving Ghostcasting (unicast) speed over 10GbE NIC

    Posted Mar 11, 2014 01:45 PM

    Hello All,

    I have a server connected directly to client over 10 GB NIC (at both ends) with Cat6a cable.  No switch is currently in use. Ghostcast server is running on the server and the client is PXE boot to Ghost64.exe to kick off unicast.

    Image is Windows 7 (64 bit) captured with Ghost32.exe. 

    When imaging the client on GhostServer UI, I see speed range from 1100-1200 Mb/min .

    Any suggestions on improving imaging speed on 10GB ethernet is appreciated! 

     

    Thank you.



  • 2.  RE: Improving Ghostcasting (unicast) speed over 10GbE NIC

    Posted Mar 12, 2014 02:06 PM

    Having 10Gbps network speed does not automagically increase the throughput of the hard disk subsystem or the software. The bottleneck is almost certainly the disk operating system especially if it is imaging on a file by file basis which causes a lot of head thrashing on mechanical drives. Try using SSDs and see whether this will speed up throughput.



  • 3.  RE: Improving Ghostcasting (unicast) speed over 10GbE NIC

    Posted Mar 21, 2014 01:04 PM

    Thanks!  Yes, we do have SSDs.  No switch is in use and the server is directly connected to the client.

    Tried more experiments and had some follow up questions:

    At BIOS level, in PXE, transfer of 10GB .gho file takes ~30 seconds.

    Image transfer between the server and client for the same image size with Ghost application takes ~6 minutes.  From one run to next, the time taken does vary though.

    I have not figured out:

    1) Why there is such a huge difference in time taken (30 seconds vs 6 minutes)

    2) Everything being the same, why is there a variation in speed (and time taken as a result) from one run to next using Ghost

     



  • 4.  RE: Improving Ghostcasting (unicast) speed over 10GbE NIC

    Posted Mar 21, 2014 01:48 PM
    You cannot compare the time taken to transfer a single 10Gb file with the time taken to use the 10Gb file to write an image. The latter involves decompression of individual files and writing location details for each file into the disk directory. As for your second question, I would have thought that was down to other processes that are running concurrently such as virus scanning, SSD error management, LAN buffering and resend requests if there was a lan error, and so on.


  • 5.  RE: Improving Ghostcasting (unicast) speed over 10GbE NIC

    Posted Mar 21, 2014 05:48 PM

    That makes sense. Thanks for the clarification.

    I will look at performance monitor and anti-virus on server side during the ghostcasting session to root cause issues. Any tools to monitor issues on the client side?  Is it advisable to tweak any settings in Ghostsrv.exe (File > options)?

    This might sound like a silly question - is it recommended to format/wipe the target drive before joining the ghostcast session?  Target drive does have an image to begin with, in my case.

     



  • 6.  RE: Improving Ghostcasting (unicast) speed over 10GbE NIC

    Posted Mar 22, 2014 06:51 AM

    I would not expect formatting or otherwise wiping the target drive to make any significant difference to transfer speed but of course the only way to be sure in any specific environment is to try it. Bear in mind that SSDs manage data in a different way to rotating hard disks, as there is no latency issue and nothing to be gained by defragmentation. The internal SSD logic moves data around on the drive to equalise wear on the memory cells as flash memory has a finite number of read write cycles. There are also spare cells to allow for this wearout.

    You will get a greater variation when using standard hard disks due to latency and interleave timings, and allowable variations of rotational speed, usually plus or minus 5%. Fragmentation levels also play a part.

    Finally, the fact that a copy dialog has completed does not necessarily mean that the copy operation has completed, just that the data transfer has completed. There is still a distinct possibility that data is still being written from memory to hard disk in the background especially if the software uses write behind caching.

    Use of standard or jumbo frames at the ethernet level would also affect performance, as would error rates on the network (which a network monitor would show up)

    You have not mentioned how large a variation you encounter each time but as you can see there are many factors that can affect the precise transfer time.