From nobody Mon Jun 21 10:13:01 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3CF005D68D1 for ; Mon, 21 Jun 2021 10:16:11 +0000 (UTC) (envelope-from denis@ovsienko.info) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G7lmS6HQwz4n4f for ; Mon, 21 Jun 2021 10:16:07 +0000 (UTC) (envelope-from denis@ovsienko.info) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ovsienko.info; s=selector2; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=6TtGZIGaKK7qlfbq0cQAMlaEpf10dxpbdt1PKk89AjA=; b=ePKT93k5oS0E2xUQNhL5wZ4iDh mFjUgeneW1tEgSB9C1zjQHVWN1JO0PWqa4ZZCQ+AfU9AUycaGofMsG0juD8lnjsJKRlwfU1w92Y5i lyR/7FYwvY2Dv0RXDMHAlZKKYfbCDoYfToE4qIyPikNQ5Ni32JNDg825WNJI9JB6+yWN4GHX+hSLA lfcUxMM3dEl6rHOQrrAFuPEybfsOAfEVMAvWapMP12SV9aSpjxXa0jLuBIBkHj9qZbJHD/UX3kcr1 QX/DQaYJEaDn9Eh1t6nNU3frVdq3nDsMcm1ZnWwHmKtz/76F0VKVQVj3+4b6uJnULRKsJzgnL5nxr RM2nGt+g==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1lvGyL-0007Bl-L0 for freebsd-arm@freebsd.org; Mon, 21 Jun 2021 12:16:05 +0200 Received: by submission02.runbox with esmtpsa [Authenticated ID (984599)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1lvGyG-0004PS-VD for freebsd-arm@freebsd.org; Mon, 21 Jun 2021 12:16:01 +0200 Date: Mon, 21 Jun 2021 11:13:01 +0100 From: Denis Ovsienko To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi 3B+ and pitiful network speeds Message-ID: <20210621111301.75fa1c7a@basepc> In-Reply-To: References: <20210620144513.1f91a68f@basepc> <169baf0b-3f3c-f1dc-4a6f-b8a0ef863f51@denninger.net> <20210620154105.0c83bbcc@basepc> <20210620222922.51da1818@basepc> <3fa3f2a6-8560-f413-b2eb-5c172ce025eb@gmail.com> <6B4F2FB6-ABA1-4CFA-BE2A-6A466C30FF02@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G7lmS6HQwz4n4f X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ovsienko.info header.s=selector2 header.b=ePKT93k5; dmarc=none; spf=pass (mx1.freebsd.org: domain of denis@ovsienko.info designates 91.220.196.211 as permitted sender) smtp.mailfrom=denis@ovsienko.info X-Spamd-Result: default: False [-3.10 / 15.00]; MID_RHS_NOT_FQDN(0.50)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[91.220.196.211:from]; R_DKIM_ALLOW(-0.20)[ovsienko.info:s=selector2]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[91.220.196.211:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.220.196.211]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[ovsienko.info]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[91.220.196.211:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[ovsienko.info:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:50304, ipnet:91.220.196.0/24, country:NO]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_IN_DNSWL_LOW(-0.10)[91.220.196.211:from] X-ThisMailContainsUnwantedMimeParts: N On Mon, 21 Jun 2021 17:04:32 +1000 MJ wrote: > [A plain write to /dev/null from a file made by /dev/zero] > > dd if=/tmp/test.img of=/dev/null > 1024000+0 records in > 1024000+0 records out > 524288000 bytes (524 MB, 500 MiB) copied, 22.8584 s, 22.9 MB/s > > > Now the network speeds (the destination machine is the same): > > 22.9 Megabytes per second, filezilla to Windows 10, SSD & NVMe. Hello Matt. The dd command above does a sequential read performance test on the SD reader (you mentioned earlier that the SD card is faster than that). Even on the latest RPIs this does not exceed 45MB/s by design. Please mind that your filezilla upload test performance is exactly the SD card read performance (the network interface is said to be internally bottlenecked at 300Mb/s, which is about 1.5 times the 22.9MB/s). Also it looks like the SSD you mentioned is not where RPI filesystem is. But this should not matter in a properly staged network throughput test. In my "dd+nc" test the goal was to measure plain TCP performance. Hence it consists of: * an nc process at each end of the TCP connection * a dd process piped to each nc process to measure the throughput * no filesystem access, hence the dd processes reading from /dev/urandom (or /dev/zero if you like) and writing to /dev/null Which would be along these lines: # TCP download freebsdrpi$ nc -l 10000 | dd bs=1m of=/dev/null linuxpc$ dd if=/dev/zero bs=1M count=2000 status=progress | \ nc freebsdrpi 10000 # TCP upload linuxpc$ nc -l 15000 | dd bs=1M of=/dev/null status=progress freebsdrpi$ dd if=/dev/zero bs=1m count=2000 | nc linuxpc 15000 If you do not feel confident staging the test like this, iperf would be a more convenient testing tool. Please mind it by default does a one-way 1Mb/s test with a possible time limit. So you will have to look at the man page and to use the right command-line options. With due attention to detail it should be possible to identify the root cause of the problem, and hopefully to solve it. Perhaps you could work the test details out first using your preferred OS. As soon as you get 300Mb/s sustained over more than the amount of RAM, you can boot the RPI3B+ into FreeBSD and repeat the test exactly to see if the results reproduce. As to the board identification, RaspiOS/Raspbian can conveniently do that in the ways explained by Mark. Obviously, you would have to boot into it once. You don't have to keep it and to use it afterwards. Alternatively, you can use NetBSD [1] and run the command below to get the board revision: # sysctl machdep.board_revision machdep.board_revision = 10494163 (this is A020D3 in hex, as suggested by Mark before). 1: https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.2/evbarm-aarch64/binary/gzimg/arm64.img.gz -- Denis Ovsienko