+- iPXE discussion forum (https://forum.ipxe.org)
+-- Forum: iPXE user forums (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: Download speed (/showthread.php?tid=6796)
Download speed - Stoney - 2013-01-16 13:55
Hi
When I download a winpe boot image size 167 MB
it takes about 1,5 -2 minuttes.
When I download the same image from a browser it takes about 2 sec.
It appears as the newer the machines are, the slower it gets
It's a brandnew Lenovo W530.
Older machines like Lenovo T61 download way faster.
Still not near 2 sec tho
Is this a NIC driver "problem" in IPXE or am I doing something wrong ?
RE: Download speed - robinsmidsrod - 2013-01-17 07:26
How do you serve the WinPE image to iPXE? If you use TFTP, it can take a long time. Make sure you use HTTP.
It can also be that the PXE driver in your laptop is poorly programmed, and if you're using undionly.kpxe, you are using the Lenovo-provided driver to download the image. You can try chainloading ipxe.pxe instead of undionly.kpxe and see if that makes any difference. Be aware that it requires that iPXE supports your laptop's network card.
RE: Download speed - Stoney - 2013-01-22 10:24
Here is my setup:
My PXE menu:
LABEL IPXE
MENU LABEL ^ 3. IPXE 32 bit
KERNEL ipxe/IPXE.KRN dhcp && chain http://172.17.80.33/winpe/bootx86.ipxe
LABEL IPXE
MENU LABEL ^ 4. IPXE 64 bit
KERNEL ipxe/IPXE.KRN dhcp && chain http://172.17.80.33/winpe/bootx64.ipxe
I just like to choose if I wanna boot 32 or 64 bit
This is http://172.17.80.33/winpe/bootx86.ipxe
#!ipxe
# cpuid --ext 29 && set arch amd64 || set arch x86
kernel wimboot
initrd x86/ISO/bootmgr bootmgr
initrd x86/ISO/boot/bcd BCD
initrd x86/ISO/boot/boot.sdi boot.sdi
initrd x86/winpe.wim boot.wim
boot
It works, just very slow.
We are using only Lenovo computeres.
This is the Linux driver
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3299&DwnldID=15817&ProductFamily=Ethernet+Components&ProductLine=Ethernet+Controllers&ProductProduct=Intel%C2%AE+82579+Gigabit+Ethernet+Controller&lang=eng
It is 82579 who cause me a lot of pain
Is it my setup who is wrong or is it a driver problem ?
As far as I can see the Intel driver is newer than the compiled IPXE.KRN
Please help
Btw I am a totally Linux noob
RE: Download speed - fc117 - 2013-01-22 15:18
Hi,
I had same issue and solve it by using ipxe.kkpxe (undionly.pxe don't give me network, and ipxe.pxe and ipxe.kpxe give slow connection to download the wim image
Hope this gona help
Regards
RE: Download speed - robinsmidsrod - 2013-01-24 08:40
The .kkpxe extension does work around some BIOS bugs, so maybe it might work for you as well.
If any of you have any experience debugging things, it would be useful to post a debug report on the mailing-list about the slowness of the intel driver.
RE: Download speed - Stoney - 2013-01-24 17:54
Thanks for the responses
As I wrote I am a Linux noob
@robinsmidsrod
Could you point me in direction how to debug it ?
I got a friend who is nuts about Linux,
he might help me !
Btw I just found a 10 year old IBM laptop T42.
It worked like a charm, downloaded the wim image within 5 secs.
I would really really like to contribute to solve that Intel driver "mystery"
RE: Download speed - robinsmidsrod - 2013-01-27 22:30
When you compile, you can try to do this if you're using the USB image:
Code:
make bin/ipxe.usb DEBUG=intelMake sure you also modify src/config/local/console.h according to information in src/config/console.h to enable serial console. You might need that to capture the information required. If you don't have an old-fashioned serial-port on the machine sometimes it is useful to use a camera to take a photo of the screen.
RE: Download speed - Christian Bovey - 2013-10-15 16:23
Hello,
We have the same problem with a lot of machine, all using Intel 82579lm card. We have tested different version as suggested (ipxe.pxe, ipxe.kpxe, undionly.kpxe, ...), and result are quite simple: the iPXE version doesn't change anything.
Does anyone found a solution?
------------------------------------------------------------------------------------------------------------
Here are some values, downloading a 200Mo wim (Using https and php on 100Mo lan):
- HP 8200 Elite (Intel 82579lm): 3min 54s - 4min
- HP 8300 Elite (Intel 82579lm): 3min 54s - 4min
- HP Elitebook 8560p (Intel 82579lm): 3min 15s - 4min
- HP Elitebook 8570p (Intel 82579lm): 3min 15s - 4min
- HP Elitebook 9470m (Intel 82579lm): 4min - 4min 06s
Some result with card working well:
- HP DC7800 (Intel 82566dm-2): 1min 01s - 1min 10s
- HP DC7900 (Intel 82567lm-3): 1min - 1min 06s
- HP 8000 Elite (Intel 82566lm-3): 58s - 1min
- HP Elitebook 8530p (Intel 82567lm): 1min - 1min 18s
- HP Elitebook 8540p (Intel 82567lm): 55s - 57s
Finally non-intel card:
- Samsung NPXE300 (Realtek RTL8168): 1min 54s - 2min 06s
- Fujitsu C5720 (Broadcom B57 - 14E4-167A): 4min 30s - 4min 42s[/undefined]
RE: Download speed - Stoney - 2013-10-15 18:45
Hi Christian Bovey
You didnt mention if you use pxelinux.0 or "pure" IPXE
It seems to be a problem with pxelinux.0
I build a .kkpxe using http://rom-o-matic.eu/ (remark KKpxe), because I am a dumbass to Linux :-)
When I put that as my bootfile in my dhcp scope it works like a charm on our GB network.
It downloads our winpe image within 10 seconds :-) (HTTP)
My problem is I need the pxelinux.0 due to some low end machines and UEFI shit :-)
So I am still stuck with a pretty huge download time :-(
Well, it's about 2 minut by tftp, but feels like forever.
RE: Download speed - Christian Bovey - 2013-10-16 06:29
Good question, I think I use pure iPXE, not pxelinux.0
Here is the current boot process:
-1- DHCP => load ipxe.pxe (2012 version) with embedded script. (I now know that I could use last version of ipxe.pxe)
-2- Login (ipxe script with https and php) and chain to menu (using iPXE menu command)
-3- Selecting option to chain load to a new version of iPXE (ipxe.pxe, ipxe.kpxe, undionly.kpxe, ...) with the same embedded script
-4- Login (ipxe script with https and php) and chain to menu (using iPXE menu command)
-5- Finally image download with the results I posted yesterday.
If I found a version that goes fast, I will replace the first script with a network card detection to start the good iPXE version, but I don't see any performance improvement. Currently, users skip step -3- and -4- an directly select iso file to download.
I have to use https for security, but tried with ftp with same result in download time. Downloading wim files directly from browser is really fast (less than 20s)
RE: Download speed - robinsmidsrod - 2013-10-20 09:52
I think you should really carefully run all the tests mentioned in http://ipxe.org/dev/driver for the card in question. A 500MB file should download using HTTP on gigabit network in about 5 seconds. Could you tell me what results you get after testing all of those things? Make sure you do all the tests, even the ones that seem a bit trivial, and report back what download speeds you get.
RE: Download speed - Christian Bovey - 2013-10-22 15:27
We are currently doing the tests, I'll post all result when we have finished.
We already found something strange, using an old computer (HP DC7900) running quite fast in production and a new one (HP 8300 Elite):
-1- Using one server - One gigabit switch - DC7900 client => Network usage 100Mbit/s
-2- Using one server - Direct connection (server to client) - DC7900 client => Network usage 800Mbit/s
-3- Using one server - Direct connection or gigabit switch - 8300Elite => Network usage 10Mbit/s
On "-3-" the link speed is 1 Gbit on bios, then negociated at 10Mbit during iPXE booting and staying at 10Mbit during transfer...
Playing with BIOS config on the new machine (HP 8300), we found that disabling AMT help a little: network link is now 1Gbit but transfer speed stay at 100Mbit...
RE: Download speed - robinsmidsrod - 2013-10-23 10:32
It definitely seems like your having auto-negotiation issues. If this is the Broadcom tg3 driver it has had issues with this in the past. Have you tried that -3- machine on a 100Mbit switch to see if it negotiates 100Mbit instead of 10Mbit? If so, you might be seeing the same issue Broadcom helped us with a while back. There is more information in the mailing-list archive. I can't recall the dates, but it might be close to a year ago when I started hearing about it.
RE: Download speed - Christian Bovey - 2013-10-23 10:33
Test done on two machine (HP 8000 Elite with Intel 82567lm-3 and HP 8300 Elite with Intel 82579lm), using an HP 8200 Elite as DHCP/TFTP/HTTP server.
We have currently no PCI/PCIe card for loopback test.
Results:
Both cards are succesful on all test (don't know for loopback).
ifstat command throw errors (but still show link status) on both card : 3c086003, 440e6003 and 380f6001
Speedresults:
- HP 8000 Elite with Intel 82567lm-3 and a 512Mb file => Between 5.3s to 15.8s, using more than 90% bandwidth used.
- HP 8300 Elite with Intel 82579lm and a 8Mb file => Alltime 7.2s with 100% bandwidth used.
We have done one another test using direct link on 82579lm :
- Forcing 100Mb Full Duplex => Speed is now correct, 100% of 100Mb is used.
- Forcing 1Gb Full Duplex => During iPXE booting, the link go down and never go up again...
Setting back to negociate the speed is always 10Mb in iPXE.
I hope this results may help finding a solution...
Yes, It's auto-negociation issue. I wil try tomorrow with a 100Mb hub. All tests are done with Intel card, no broadcom (We only have rare old computer using broadcom card).
Are there more test we could do to help?
RE: Download speed - robinsmidsrod - 2013-10-27 10:26
I have the same Intel 82579V (not LM) on my ASUS motherboard, and I have no speed issues what so ever with that one. I do know that in the early development of the new intel driver, my card switched between V and LM mode depending on if it was a warm or cold boot. We found a workaround for that issue, but it _could be_ that the HP Elite BIOS is doing something else to the initialization of the card, which we're not taking into account. I would suggest you try to build with DEBUG=intel or DEBUG=intel:3 and see what debug messages you get when you get a correct auto-neg response and when you get a wrong one. Sharp photos (or serial debug information) is vital for this step.
This is a technical issue and should probably be mentioned on the mailing-list. I would suggest you continue the discussion there with the core developers.