From owner-freebsd-hackers@freebsd.org Fri Feb 28 10:51:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2437825FFC5 for ; Fri, 28 Feb 2020 10:51:33 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48TRDP01kWz4Bdj for ; Fri, 28 Feb 2020 10:51:33 +0000 (UTC) (envelope-from se@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E375F25FFC4; Fri, 28 Feb 2020 10:51:32 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DDDD825FFC3 for ; Fri, 28 Feb 2020 10:51:32 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48TRDN4kS1z4Bd5; Fri, 28 Feb 2020 10:51:32 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-449.fritz.box (p200300CD5F127700AD63170E203181C5.dip0.t-ipconnect.de [IPv6:2003:cd:5f12:7700:ad63:170e:2031:81c5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 071071FFDA; Fri, 28 Feb 2020 10:51:31 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: Slow PXE boot To: =?UTF-8?B?RG9tYWdvaiBTbW9sxI1pxIc=?= References: <20200224032300.00006290@gmail.com> <8F7B8958-5295-4A26-82E9-94C7A62ED8A1@longcount.org> <20200228032644.000018c3@gmail.com> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Message-ID: <29a13654-3b80-52d3-25cd-463073294126@freebsd.org> Date: Fri, 28 Feb 2020 11:51:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200228032644.000018c3@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 28 Feb 2020 14:27:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 10:51:33 -0000 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