On Monday 22 Nov 2010 09:59:03 Erik Loman wrote: > I actually found something interesting with Wireshark. Since there is no > network traffic (for some time) when Windows boots it seems that > Window's network is the cause of the delay. It is sending ARP requests. > > I have attached a screenshot of the device LoadOrder and Wireshark. > > Do I need to change something to the load order of the drivers? Do you > have an idea on what to do?
(Please Cc ipxe-devel at lists.ipxe.org on replies.) I note the following points of interest on the wireshark trace: #60036 (21.58s) - this is the final packet sent by iPXE: a TCP ACK for the last iSCSI response received by iPXE before Windows takes over. #60038 (29.75s) - this is the first packet sent by Windows: a gratuitous ARP which is presumably the Windows TCP/IP stack checking for an IP address collision before using its IP address (10.1.1.199). #60042 (35.46s) - this is the first packet sent by Windows after it decides it is safe to use the IP address 10.1.1.199. #60043 (35.46s) - this is the start of the Windows iSCSI connection So, the delay from 29.75s to 35.46s is attributable to Windows checking for an IP address collision. It looks as though you should be able to tune the number of gratuitous ARPs using the registry entry: HKLM\System\CurrentControlSet\Services\TcpIp\Parameters\ArpRetryCount A value of zero may or may not work; at least some versions of Windows will treat a value of zero as meaning "use default number". Disabling gratuitous ARP probably does make sense in the case of an iSCSI boot. If gratuitous ARP were to detect an IP address conflict, it would prevent the local interface from using the IP address, which would cause the boot to fail around a minute later with a STOP 0x0000007B error, with no way to inform the user that the IP address conflict was the root cause. Given this, you may as well disable it and speed up your system boot. Michael
