Date: Fri, 28 Feb 2020 11:51:28 +0100 From: =?UTF-8?Q?Stefan_E=c3=9fer?= <se@freebsd.org> To: =?UTF-8?B?RG9tYWdvaiBTbW9sxI1pxIc=?= <rank1seeker@gmail.com> Subject: Re: Slow PXE boot Message-ID: <29a13654-3b80-52d3-25cd-463073294126@freebsd.org> In-Reply-To: <20200228032644.000018c3@gmail.com> References: <20200224032300.00006290@gmail.com> <8F7B8958-5295-4A26-82E9-94C7A62ED8A1@longcount.org> <20200228032644.000018c3@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 28.02.20 um 03:26 schrieb Domagoj Smolčić: > Mark, > > PXE clients are directly connected to FreeBSD based PXE server, with same ETH cable. Hi Domagoj, this looks like a duplex mis-configuration, even if you think everything is set up correctly. I've seen this multiple times ... > There is no any intermediate hardware like switch, etc ... Then there may still be no auto-negotiation of Ethernet parameters like duplex mode. If one NIC is set to auto-configure (the default in FreeBSD) and the other hard-configured to max performance (which includes full-duplex), then there will be NO auto-configuration of the NIC on the FreeBSD side. The standard reuqires that a NIC that is not flexible in its settings does not participate in the auto-negotiation sequence. And FreeBSD will then use lowest common demoninator settings, i.e. 100 Mbit/s and half-duplex! Did you check the NIC interface counters, e.g. as reported by "netstat -i" on the FreeBSD side? > Regarding '... running at 100mb 1/2 duplex', nope ..., in bios setting is all set to "max" for NICs Do both NICs perform an auto-negotiation or has one of them fixed settings? As written above: Fixed settings do not mean that these settings will be reported in the auto-negotiation attempted by the other side. It will make the NIC ignore the auto-negotiation attempt and it will make the other side fall back to safe defaults (which may lead to a duplex mismatch, if the "fixed side" is set to full-duplex). > Finally, result is always 100% repeatable for both tested clients. > One always being super fast and the other, unbelievably slow ... This proves that a fast boot is technically possible. If you were to connect a network sniffer (or switch with package snoop capability) to the connection, then you'd probably see lots of re-transmissions because of "collisions" that are detected due to the duplex mismatch ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29a13654-3b80-52d3-25cd-463073294126>