Tuesday, May 14, 2013

How to boost PXE TFTP Boot speed

Want more speed to PXE Boot?  Try this

Out of the Box booting my WinPE on SCCM 2012 with WS 2012 took about 28 Seconds at 45Mb/s Network speed in my Hyper-V environment.
Now Microsoft have set this to a default value that suites most kind of network environments.


Now with some adjustments...


Create this in registry on Your PXE WDS Server:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\DP\RamDiskTFTPBlockSize
Type Reg_Dword
Value: 16384 Dec          (Do not use higher value than this!)
((Recommend that you increase this setting in multiples (4096, 8192, 16384, and so on) and that you not set a value higher than 16384.))
And you need to test this in all kinds of networks in your business. Mostly 4096 or 8192 will give you the performance boost as well as enough reliablity you need.

Restart WDS Service
Remember the higher value the more risk of packet loss if bad network Connection.
You have to try this out carefully in your network environment.
If experiencing problems, try lower value.


With this setting I got a significant increase in speed!
My Hyper-V client PXE booted the WinPE image in just 4 Seconds !!! :-)  With around 210-270Mb/s



Experience with customers in real life so far have been good, an increase by 4-5 times the speed.



Most problems with pxe booting are usually related to networking. So you might want to take it up with the networking people in your company to get issues sorted out. If its extreamly slowly or not working at all.

IP helper or DHCP options?
I as well as Microsoft recommend IP helper on the networking appliance as first and best option. And then if needed in special situations use DHCP options if you must.
IP helper is the most reliable function though and should point to both DHCP Server and PXE Point Server.

10 comments:

  1. Are there any special considerations for this tweak? (With router/switches?)

    ReplyDelete
  2. I wish Msft would just include this configuration in the build.

    ReplyDelete
  3. Not a good solution
    This could very well lead to IP fragmentation and not every PXE client out there is able to deal with that correctly

    ReplyDelete
  4. Made absolutely no difference what-so-ever :(

    ReplyDelete
  5. Making this change solve one issue we had with some system that were taking too long to PXE boot. The issue was that these system were too slow to acknowledge reception of data packets. Anyone knows if there are side effects to this fix?

    ReplyDelete
  6. I tried this because mine is taking almost 4 hours to load the boot wim. I know this is due to firewalls and transferring blocks of data. Is there anyway to change this from TFTP to FTP?

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. This process has to be TFTP as FTP is a completely different beast. Your network infrastructure is incredibly important in this process, as fragmented blocks during a TFTP transfer will cause those blocks to be retransmitted over and over and over until it gets it right(this is why we use TFTP and not FTP). It can be anything from a crappy network switch, bad network/patch cable, or just an overloaded switch will cause you to have a bad day with TFTP.

    The larger you set the ramdisktftpblocksize, the more data can be transmitted at the same time possibly resulting in a faster transfer, but you are increasing the chances of fragmenting said block which could actually make this take even longer than it was when you had it set to a smaller block size. You will need to experiment and find which size best suits your network, or get with your network bros and get some upgrades/replace some cables.

    ReplyDelete
    Replies
    1. Just had to add, I've had a LOT of push back from "network guys" when troubleshooting TFTP that insist it's not the network. Double check that your server's NIC drivers are up to date, that it is negotiating a full speed 1Gbps (or 10Gbps if you're a bad ass), maybe do a speed test with iperf or a web based speed test and then it HAS to be the network. When you finally get them to start digging into things, 99% of the time we have discovered a bad link somewhere in the topology. Bad switch stack, bad switch hardware causing collisions like a mofo, etc.

      Delete