Deployment Solution

Hi we have just installed a new server with DS6.9sp4 and are wanting to use winpe boot images. We have moved from DS 6.8 using Dos boot images.

THE ISSUE: When winpe pxe booting 1 machine the boot image takes around 3 mins (it is 140mb in size) as we add more machines to pxe boot the winpe boot image download becomes unmanageable, 20 computers take up to 90 minutes to download the boot image. Once the pxe boot image is downloaded the image deployment is very quick ie a 20 gb would finish in about 14 minutes. We are educational organisation and in our environment it would not be uncomman to image up to 200 computers or more at the same time. We have tried variations of teaming network cards on the server etc. The PXE server is installed on the same server as the DS, the dhcp is on another server.

I would love to know if other people have had this issue and how it was resolved, we want to use pxe boot images as our dos boot images have become restrictive with the sizing and the drivers are not always available for all network cards. We are predominantly Dell PC's.

I have had one of our network staff look at the pxelog_mtftp,txt and he has come up with the following, this is based on  4 machines pxe booting at once.

The tftp server has 4 cache buffers (#0, #1, #2, and #3)
#0 holds 16384 bytes
#1 holds 49152 bytes
#2 holds 32768 bytes
#3 holds 32768 bytes
As we're downloading the same file to all 3 PCs we appear to be using the same cache buffer - cache #0. This presents a problem as 16384 bytes is only around 11.5 times our block size (1420) so if one PC gets more than 11 packets in front of another, the server has to stop transmitting, open the file and read in a different 16384 bytes to the buffer then sent a packet.

The Network technicians comments are in bold

xx.xx.130.201 requests block 30781 - cache #0 currently contains data from block 31869 to 31880 (current offset is 45253980 which is equal to block 31869, length is 16384 which is equal to 11.5 blocks ) which does not contain the desired block so we read in a new buffer from block 30781 (offset 43709020), and send out the desired block
D [11:18:25.209 01/20] (7532): HandleTFTP: action: next block  IPAddr=xx.xx.130.201:12965
(7532)HandleTFTP: P_ACK for blk: 30780 want blk: 30781
(7532)SendUCast: blk = 30781  IPAddr: xx.xx.130.201
(7532)Cache data is changing - RefCount: 3, Current cache info before change
(7532)     [off:len](lbr): #0[45253980:16384](1), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)     [delta time]: base:1295482705  #0[0], #1[2], #2[2], #3[0]
(7532)ReadFile: cache 0 update, return size: 16384
(7532)cache info [off:len](lbr): #0[43709020:16384](0), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)Read to Cache 0 Data Returned
(7532)MySendTo completed: len = 1424
xx.xx.131.184 now requests block 32585 - cache #0 now contains block 30781 to block 30792 so we've again missed the cache. Again, we read in the file, this time from block 32585 to 32596 and send out block 32585
D [11:18:25.209 01/20] (7532): HandleTFTP: action: next block  IPAddr=xx.xx.131.184:12879
(7532)HandleTFTP: P_ACK for blk: 32584 want blk: 32585
(7532)SendUCast: blk = 32585  IPAddr: xx.xx.131.184
(7532)Cache data is changing - RefCount: 3, Current cache info before change
(7532)     [off:len](lbr): #0[43709020:16384](1), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)     [delta time]: base:1295482705  #0[0], #1[2], #2[2], #3[0]
(7532)ReadFile: cache 0 update, return size: 16384
(7532)cache info [off:len](lbr): #0[46270700:16384](0), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)Read to Cache 0 Data Returned
(7532)MySendTo completed: len = 1424
xx.xx.131.177 now requests block 31870 - again we miss the cache, and again we read the file....
D [11:18:25.209 01/20] (7532): HandleTFTP: action: next block  IPAddr=xx.xx.131.177:12880
(7532)HandleTFTP: P_ACK for blk: 31869 want blk: 31870
(7532)SendUCast: blk = 31870  IPAddr: xx.xx.131.177
(7532)Cache data is changing - RefCount: 3, Current cache info before change
(7532)     [off:len](lbr): #0[46270700:16384](1), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)     [delta time]: base:1295482705  #0[0], #1[2], #2[2], #3[0]
(7532)ReadFile: cache 0 update, return size: 16384
(7532)cache info [off:len](lbr): #0[45255400:16384](0), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)Read to Cache 0 Data Returned
(7532)MySendTo completed: len = 1424
xx.xx.130.201 is now back for block 30782
D [11:18:25.209 01/20] (7532): HandleTFTP: action: next block  IPAddr=xx.xx.130.201:12965
(7532)HandleTFTP: P_ACK for blk: 30781 want blk: 30782
(7532)SendUCast: blk = 30782  IPAddr: xx.xx.130.201
(7532)Cache data is changing - RefCount: 3, Current cache info before change
(7532)     [off:len](lbr): #0[45255400:16384](1), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)     [delta time]: base:1295482705  #0[0], #1[2], #2[2], #3[0]
(7532)ReadFile: cache 0 update, return size: 16384
(7532)cache info [off:len](lbr): #0[43710440:16384](0), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)Read to Cache 0 Data Returned
(7532)MySendTo completed: len = 1424
xx.xx.131.184 is back for block 32586
D [11:18:25.225 01/20] (7532): HandleTFTP: action: next block  IPAddr=xx.xx.131.184:12879
(7532)HandleTFTP: P_ACK for blk: 32585 want blk: 32586
(7532)SendUCast: blk = 32586  IPAddr: xx.xx.131.184
(7532)Cache data is changing - RefCount: 3, Current cache info before change
(7532)     [off:len](lbr): #0[43710440:16384](1), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)     [delta time]: base:1295482705  #0[0], #1[2], #2[2], #3[0]
(7532)ReadFile: cache 0 update, return size: 16384
(7532)cache info [off:len](lbr): #0[46272120:16384](0), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)Read to Cache 0 Data Returned
(7532)MySendTo completed: len = 1424
xx.xx.131.177 is back for block 31871
D [11:18:25.225 01/20] (7532): HandleTFTP: action: next block  IPAddr=xx.xx.131.177:12880
(7532)HandleTFTP: P_ACK for blk: 31870 want blk: 31871
(7532)SendUCast: blk = 31871  IPAddr: xx.xx.131.177
(7532)Cache data is changing - RefCount: 3, Current cache info before change
(7532)     [off:len](lbr): #0[46272120:16384](1), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)     [delta time]: base:1295482705  #0[0], #1[2], #2[2], #3[0]
(7532)ReadFile: cache 0 update, return size: 16384
(7532)cache info [off:len](lbr): #0[45256820:16384](0), #1[42940800:49152](1), #2[44485760:32768](1), #3[46185500:32768](1)
(7532)Read to Cache 0 Data Returned
(7532)MySendTo completed: len = 1424

If you have a look at the PxeLog_Mtftp for 1 computer this never happens. There are no instances of "Cache data is changing" and the cache just updates itself every 11 packets or so when it reaches the end of the buffer
 

Thanks Cat

Are you running a unicast or multicast network?

You will see significant speed degredation in unicast networks when booting multiple machines into a WinPE environment at the same time. Multicast should be much faster.

Except that it doesn't multicast.  The advantage of the DS MTFTP service is that it supports Multicast, but this also becomes a slow-down.  We pull that out, it speeds up.  Since most of our clients don't use multicast with WinPE, we're seriously considering pulling that out in future releases.

In the mean time though, IF you can use Multicast, as Rhys said, it should speed things up when you have multiple systems booting, but it wont help much for 1-2.  If MOST of the time you're looking at only a couple at a time, you might consider using the Open TFTP service, which is opensource and thus free, and we have some KB's on how to integrate that into 6.9.

The short answer is that it's really easy.  We need the exe, and an associated INI file, and then you simply modify our TFTP service to point to the other EXE.  That's it.  If it doesn't work for you, you switch the service back to our EXE and away you go - back to normal.

GL!

I found the following article and followed the instructions and have now found in testing (23 computers) that the pxe boot load time has decreased from 1hour 20mins (avg) to 4 mins.

https://www-secure.symantec.com/connect/articles/double-your-pxe-boot-speed

Thanks for the update.