[gPXE] Transfer speed with e1000 and pcnet32 in VMware

[Joakim Schicht]

You can read about how to boot a full XP from WIM here: http://sanbarrow.com/phpBB2/viewtopic.php?t=1695 

 

When you say "204 MB XP SP2 HDD image", do you mean complete with all necessary files to ramboot? How stripped-down is it actually?

 

I have not yet dived into iSCSI booting, but will soon do. Btw, is that possible to boot over WAN? Is your setup documented anywhere?

 

By "another stack", I meant downloaded from a booted xp (not pxe), either host-host or guest-host. I cannot say if gPXE behaves differently from other pxe stack, because my other tests with other stack have downloaded over tftp only (built-in vmware). It is therefore not directly comparable.

 

Btw, I am the same Joakim that tested your winvblock driver a few months ago. 

 

Joakim Schicht


 


Date: Mon, 30 Nov 2009 22:57:21 -0500
From: Shao.Miller at yrdsb.edu.on.ca
To: jonny49 at live.no
CC: gpxe at etherboot.org
Subject: Re: [gPXE] Transfer speed with e1000 and pcnet32 in VMware

Joakim Schicht wrote:

I am fiddling with WAN (HTTP) booting of "Universal XP". By wimbooting xp, we can enjoy great compression and faster image transfer (my rather complete XP SP2 with all services intact, is only 209 Mb after finally being zipped).
Interesting.  How exactly are you accomplishing this?  What exactly are you downloading via HTTP?  I was under the impression that the entirety of XP could not be in a .WIM file and be bootable, though you can attach a .WIM file at some point during boot.  If you have a relevant link to your setup over at the Boot-Land forums, perhaps you would kindly reply with such a link here for other interested gPXE Windows XP users?

For comparison, I have a 204 MB XP SP2 HDD image which I boot using MEMDISK and WinVBlock.  Each computer which boots this image is licensed for a single installation of Windows XP SP2.  The BOOT.INI menu offers all kernel and HAL combinations, so the image will boot on any hardware platform with enough RAM.  256 MB is enough to run, but many programs cannot allocate memory and have quirks; CMD.EXE is fine.  In this scenario, I have gPXE attach to a read-only SAN.  That SAN has a FAT32 partition and SYSLINUX installed onto it.  SYSLINUX boots and loads MEMDISK along with the "RamXP" HDD image.  The fact that gPXE uses iSCSI to read this SAN results in significantly faster transfer times than HTTP, but obviously is not quite as universal as HTTP allowances in the world.




But using another stack than gPXE in the same environment (even with no physical nic connected) will not trigger this stall behaviour. Which leads me to think that it could be some weird combination.
Using another stack, how are you downloading via HTTP?

Either way, it is definately a vmware-related issue.
If gPXE is really behaving differently than some other PXE stack which accomplishes decent HTTP download behaviour, it would still be good to know why.

- Shao Miller
 		 	   		  
_________________________________________________________________
Windows Live™ Mail. Flere kontoer på ett sted.
http://download.live.com/wlmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe/attachments/20091201/fb883862/attachment.html