eyals1 Absent Member.
Absent Member.
1286 views

Slow TFTP work

We are using zenworks 2017 and deploy our image using mdt.

I'm trying to integrate zenworks with mdt, we create mdt bundle and it working but slow...

I found this article about WDS
https://technet.microsoft.com/en-us/library/dn163597.aspx

and it's showing that you can configure TFTP block size as 8192
I was looking for the same value in zenworks and find this:
https://www.novell.com/documentation/zenworks-2017-update-1/zen_cm_preboot_imaging/data/bvej9v1.html
and the value of TransferBlockSize = 1428

Is this what cause this slow deployment ?

Thanks
Eyal
Labels (1)
0 Likes
5 Replies
Micro Focus Expert
Micro Focus Expert

Re: Slow TFTP work

Unlikely, but you can always test by increasing to try and use "Jumbo" Frames.

#1 - Make sure you test Non-Multi-Cast setups when analyzing, there are many things that can impact multi-cast performance.
#2 - If possible, test devices on same subnet.
#3 - Test devices with Different NICs, Could be a NIC issue.
#4 - Verify your switch settings, normally "Auto-Negotiate" is standard, but if you are hard coding on the switch and on the managed device, the WinPE boot environment is likely not setting that.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Slow TFTP work

eyals;2474915 wrote:
We are using zenworks 2017 and deploy our image using mdt.

I'm trying to integrate zenworks with mdt, we create mdt bundle and it working but slow...

I found this article about WDS
https://technet.microsoft.com/en-us/library/dn163597.aspx

and it's showing that you can configure TFTP block size as 8192
I was looking for the same value in zenworks and find this:
https://www.novell.com/documentation/zenworks-2017-update-1/zen_cm_preboot_imaging/data/bvej9v1.html
and the value of TransferBlockSize = 1428

Is this what cause this slow deployment ?

Thanks
Eyal


Seeing the same thing here (2017 u3).

The slowness is mainly visible whilst winpe.wim is getting uploaded (the initial phase of the PXE boot). Placing images seems OK.

Hardware used (meaning client side) also seems to play a role. A Dell Optiplex 7010 will take about 3 minutes to load just that winpe.wim bit, whereas that same action will load in around a minute on a Latitude laptop.

Putting down an image was ok on both (8 minutes give or take).


Setting the TransferBlockSize to 8192 on the ZENworks imaging server and restarting the Novell TFTP Service does make a difference in our case.
edit: we have not tested with different settings, like the max 4428 value that is specified in the novell-tftp.conf file. YMMV.


Loading the winpe.wim on de Dell Optiplex now takes just little over a minute (vs 3 mins).

We made no other adjustments to see this increase in speed.


Will do some more testing to make sure there is are no issues with the layed down image due to a higer setting of the transfer blocksize.... but for now, results look good!

Cheers,
Willem
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Slow TFTP work

Adjusting the Blocksize must be done with extreme caution.
The Max Ehternet Packet size is just over 1500 by default....but that includes more than just the payload.

The 1428 defines the payload portion.

Jumbo Packet Support allows for the sending of much larger packets, but needs to be supported by every single device along the way.
If not, performance will actually either be reduced or even possibly communication blocked to some devices.

The following command will give you a general idea what size packets can be supported.
I would not set the Imaging Server to use the max that succeeds, but would give you an idea if larger packets can be sent...

ping -l 4096 -f xxx.xxx.xxx.xxx
ping -l 8192 -f xxx.xxx.xxx.xxx

This will send a packet with a large packet size with the instruction to not fragment.
If it does thru, then that device and everything to the server support that size packet.
If it fails, it will let you know the packet is too big.

My network does not support larger packets....
Use with care...
0 Likes
Knowledge Partner
Knowledge Partner

Re: Slow TFTP work

Hi Craig,

CRAIGDWILSON;2496650 wrote:
Adjusting the Blocksize must be done with extreme caution....


Good to express that when tweaking those values one should test reliability.

We are aware of the larger TFTP blocksize vs max MTU packet size.

The larger chunks TFTP pushes leads to smaller segments being sent on the network to match the maximum packet size supported from A to B. When using JUMBO frames it defeats the purpose if the larger frame size is not supported on all network components involved.

But here, in testing still, we are not seeing any ill results (no timeouts, and no corrupted placing of the image), just the speedup previously mentioned on the Optiplex desktops. And we've been imaging 30 to 40 desktops with this larger TFTP blocksize.

Maybe also relevant to note, we are doing UEFI type PXE, not BIOS PXE. MMV between those two.

Cheers,
Willem
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Slow TFTP work

If you contact support, they may be able to get you an unofficial patch to improve WinPE Restore performance when performing imaging via the ZENworks "IMG" command.
The performance improvements seen using the update have been very significant.

These updates are expected to be in ZCM 2020.
At this point, the improvements are only on RESTORE using IMG.exe, though image creation is now under investigation to see if anything thing can be tweaked there as well.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.