PXE Boot Very Slow
-
I’ve set up fog using virtualbox and ubuntu server, I’ve managed to get both real and virtual clients connecting and I’ve added to the default config to add a few ISOs to boot from. I’m running over a 100mbps network and when I copy the ISOs on and off the server using my samba share I get around 100mbps, when I boot the same ISOs I seem to get only around 10mbps (it takes around a minute to load a 60mb iso into memory) both when using a virtual and real client. I’ve been googling for the last day to try and find out what could be causing it, but I’m at a loss.
-
Tftpboot is used for the transfer during pxe boot. One packet out at a time
-
So it’s meant to be limited to around 1mbps?
-
Pxe is designed around tftp and tftp is designed to be simple. Look into gpxe maybe.
-
This post is deleted! -
I don’t think tftp is my main issue, this video ([media=youtube]KYp-XVPxg3I[/media]) shows at 7:30 someone downloading a 8mb iso in 2 seconds, that’s far faster than I’m managing.
-
At this point it’s syslinux loading vesamenu.c32 loading the default menu loading your custom options. Fog isn’t even involved at this point.
-
I know, that’s why I posted in the Linux Problems thread rather than the Fog one. I can’t find a community for pxe booting itself.
-
[quote=“chad-bisd, post: 8737, member: 18”]At this point it’s syslinux loading vesamenu.c32 loading the default menu loading your custom options. Fog isn’t even involved at this point.[/quote]
Actually I’ve just re-read what you’ve written and that’s not correct. It’s loading delldiags.iso, using memdisk, just as I am and it’s doing it a lot faster than I’m able to. Are there settings for tftp that I need to tweak? Could there be an issue with memdisk?
-
Google it. I think memtest tries to load the entire file into memory before it start execution, causing slowness on larger files. I encourage you to keep researching and let us know what you find.
-
Yes, it does load the complete iso into memory. As my iso’s are around 60-150MB this should be fine if the transfer were running even at my measly 100mbps network speed, but unfortunately it’s only managing ~10mbps (~1MB/s). I think as you suggest tftp is probably the limiting factor here. I will report back if I achieve any speed gains.
-
OK, so I managed to almost solve the issue twice.
1/ Chainloaded iPXE from pxelinux.0, was able to access iPXE commandline and perform commands but it was unstable
2/ replaced pxelinux.0 with gpxelinux.0 (and the associated vesamenu.32 and memdisk files). This actually allowed me to transfer via http wich reduced my time from around 1 minute to around 1 second. The (acronis) ISO even booted, but it got to the part where it changes the screen mode to display some graphics, and crashed. My config for this was:
LABEL Acronis HTTP
kernel [url]http://192.168.1.1/pxeserver/memdisk[/url]
initrd [url]http://192.168.1.1/pxeserver/acronis.iso[/url]
append iso
-
Well, by crashed I mean rebooted.
-
So, in the end I stuck with gpxelinux.0, I found that acronis still boots on most machines - and things like Hirens and Spinrite boot on practically all machines. For those machines that don’t boot, sometimes booting off a CD created with [url]http://rom-o-matic.net/[/url] works. So in any case, I now have the speed I was after with sufficent stability for it to be useful - not as stable as pxelinux.0, but just about enough.
-
One odd thing with gpxelinux.0: tftp actually seems to be slower - so with it it’s http or nothing as far as I can see.