Anthony Weiss
asked on
File This Under Weird - PXE Stops TFTP Transmission When Display Is Disconnected
I am bringing a PXE server online (Symantec Ghost Solution Suite 3.1 Build 502) using the integrated Altiris PXE Server software.
Once I had everything up and running (hats off to Symantec to their "thorough" documentation) I was very disappointed with the transfer speeds (getting ~100-200 Kbps) to get the PE files downloaded onto the client and boot into a Windows environment.
A little bit of searching revealed "Double Your PXE Boot Speed!" http://www.symantec.com/connect/articles/double-your-pxe-boot-speed written by a Symantec Employee, advising to not use Altiris PXE MTFTP Server, and instead replace it with OpenTFTP (gotta love it!).
Once I had the necessary configs down, I was able to pull down 20 Mbps! I was so excited that I went ahead and switched over to the other PC I had on my KVM and got that guy going to. This is where the weirdness started.
When I switched back to the original PC, I found that the transfer had again slowed to a crawl (forehead meet desk). And worse, when I checked on the second PC, it too went to a crawl. I checked around the forums and everything pointed to adjusting the block size. First I went big as suggested here (http://www.alexandreviot.net/2015/07/09/sccm-2012-how-to-increase-tftp-pxe-boot-speed/), then started going small as I kept having issues with the speeds cutting out whenever I switched over to the second PC and got that going.
Now some of you might be thinking "Its the network!" Well that was where I was going, but had no desire to go down that rabbit hole. So I took a beat and said to my self, what exactly is happening here?
That's when I realized that it had nothing to do with turning on PC 2!
For those who do not follow, start on 1, see speed, switch to PC 2, see speed cut out.
It was the switching of inputs/outputs!!!!!
(Audible whack of forehead into closest wall)
Sure enough, I can reliably get the transfer to slow to a crawl by removing the display port cable on the rear of the PC (USB does not seem to affect it)
Does anyone have an idea as to how I can switch displays without killing the downloads???
Once I had everything up and running (hats off to Symantec to their "thorough" documentation) I was very disappointed with the transfer speeds (getting ~100-200 Kbps) to get the PE files downloaded onto the client and boot into a Windows environment.
A little bit of searching revealed "Double Your PXE Boot Speed!" http://www.symantec.com/connect/articles/double-your-pxe-boot-speed written by a Symantec Employee, advising to not use Altiris PXE MTFTP Server, and instead replace it with OpenTFTP (gotta love it!).
Once I had the necessary configs down, I was able to pull down 20 Mbps! I was so excited that I went ahead and switched over to the other PC I had on my KVM and got that guy going to. This is where the weirdness started.
When I switched back to the original PC, I found that the transfer had again slowed to a crawl (forehead meet desk). And worse, when I checked on the second PC, it too went to a crawl. I checked around the forums and everything pointed to adjusting the block size. First I went big as suggested here (http://www.alexandreviot.net/2015/07/09/sccm-2012-how-to-increase-tftp-pxe-boot-speed/), then started going small as I kept having issues with the speeds cutting out whenever I switched over to the second PC and got that going.
Now some of you might be thinking "Its the network!" Well that was where I was going, but had no desire to go down that rabbit hole. So I took a beat and said to my self, what exactly is happening here?
1. Start PXE Boot on PC 1
2. Verify Speed on Server as 20+
3. KVM to PC 2
4. Start PXE Boot on PC 2
5. Verify Speed on Server and see in history that PC 1 dropped off
2. Verify Speed on Server as 20+
3. KVM to PC 2
4. Start PXE Boot on PC 2
5. Verify Speed on Server and see in history that PC 1 dropped off
That's when I realized that it had nothing to do with turning on PC 2!
For those who do not follow, start on 1, see speed, switch to PC 2, see speed cut out.
It was the switching of inputs/outputs!!!!!
(Audible whack of forehead into closest wall)
Sure enough, I can reliably get the transfer to slow to a crawl by removing the display port cable on the rear of the PC (USB does not seem to affect it)
What I am working with:
Dell Optiplex 3040 Micro with a Realtek PCI-E Gigabit Ethernet Controller (Driver on dell website has file name Network_Driver_9YMJF_WN64_
Dell Optiplex 3040 Micro with a Realtek PCI-E Gigabit Ethernet Controller (Driver on dell website has file name Network_Driver_9YMJF_WN64_
Does anyone have an idea as to how I can switch displays without killing the downloads???
ASKER
Interesting, but the PE boot is a Windows 10 environment. Your comment did prompt me to test with the PXE load in with the Symantec-provided Linux PE. Same results when DP is unplugged.
Also conducted testing with the built in HDMI port (only display outs are 1 DP and 1 HDMI). Same results with the HDMI :(
Maybe this is a firmware / UEFI issue? It seems like a really weird presentation though, especially since they are two different manufacturers (Realtek - Ethernet, Intel - On Board Video)
Also conducted testing with the built in HDMI port (only display outs are 1 DP and 1 HDMI). Same results with the HDMI :(
Maybe this is a firmware / UEFI issue? It seems like a really weird presentation though, especially since they are two different manufacturers (Realtek - Ethernet, Intel - On Board Video)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@vivigatt
Thanks for the suggestions. I did pull the KVM out of the equation when I tested for HDMI (it is a DP KVM). My thinking has been on the lines of just getting the job done, and booting these guys up w/o monitors and configuring the PXE Server to boot directly into the PE environment. Not ideal since there is no way for me to isolate to a subnet (any suggestions would be welcome), but doable, as long as it is for a short time period.
I will check for the BIOS / UEFI version as well, though I do not believe there has been an update as of yet for this model.
Thanks for the suggestions. I did pull the KVM out of the equation when I tested for HDMI (it is a DP KVM). My thinking has been on the lines of just getting the job done, and booting these guys up w/o monitors and configuring the PXE Server to boot directly into the PE environment. Not ideal since there is no way for me to isolate to a subnet (any suggestions would be welcome), but doable, as long as it is for a short time period.
I will check for the BIOS / UEFI version as well, though I do not believe there has been an update as of yet for this model.
ASKER
@vivigatt
Oh Yeah, and that article you wrote, AWESOME! I stumbled upon it when I was getting the config setup. Symantec has great documentation!
Oh Yeah, and that article you wrote, AWESOME! I stumbled upon it when I was getting the config setup. Symantec has great documentation!
ASKER
I took a look @ the BIOS / UEFI, and saw it was on 1.3.5. Latest version was 1.4.6, released July 19 2016. Even cooler, it announced a possible fix!
Don't know what they fixed though, because the issue is still present :(
Fixes & Enhancements
Fixes
-Addressed DP/HDMI operates abnormal.
Fixes
-Addressed DP/HDMI operates abnormal.
Don't know what they fixed though, because the issue is still present :(
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks for the update (and the points).
In the future, you may want to give a try to iPXE/wimboot etc, these are very nice "PXE" tools
In the future, you may want to give a try to iPXE/wimboot etc, these are very nice "PXE" tools
ASKER
I was able to independently find a work-around that met my need, as well as others in similar situations with similar goals
https://support.microsoft.com/en-us/kb/2974735
Its WDS but they are patching the OS boot file.