From owner-freebsd-arm@FreeBSD.ORG Sun May 4 11:56:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 690A8124 for ; Sun, 4 May 2014 11:56:00 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 156961C6B for ; Sun, 4 May 2014 11:55:59 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s44Btoh2048803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 May 2014 13:55:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s44BthOG011421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2014 13:55:43 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s44BtgPZ071433; Sun, 4 May 2014 13:55:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s44BtgB5071432; Sun, 4 May 2014 13:55:42 +0200 (CEST) (envelope-from ticso) Date: Sun, 4 May 2014 13:55:42 +0200 From: Bernd Walter To: Boris Samorodov Subject: Re: wandboard-quad: ffec performance (about 190 Mbits/sec) Message-ID: <20140504115542.GA71303@cicely7.cicely.de> References: <53654A67.6030605@passap.ru> <20140503202441.GD64774@cicely7.cicely.de> <5366111B.5070503@passap.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5366111B.5070503@passap.ru> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ticso@cicely.de List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 11:56:00 -0000 On Sun, May 04, 2014 at 02:06:19PM +0400, Boris Samorodov wrote: > 04.05.2014 00:24, Bernd Walter ??????????: > > On Sat, May 03, 2014 at 11:58:31PM +0400, Boris Samorodov wrote: > >> Hi All, > >> > >> My home PC has max perfomance approx. 800 Mbit/sec (measured between > >> two re adapters and a cheap d-link switch in between them). > >> > >> I've just test ffec performance (one of re's is the other side): > >> ----- > >> > >> Is this an expected result? Assuming that the system was about 65% idle, > >> there is a space for improvement. > > > > Freecale says that the ethernet interface has a 400Mbit/s memory > > interface, so that's pretty much the physical limit and I think even > > in summary of both directions. > > The hardware also has some very fancy IP offloading stuff, of which I > > don't know how much we already utilize. > > From the Processor Reference Manual (IMX6DQRM, Rev. 1, 04/2013), > Chapter 23 "10/100/1000-Mbps Ethernet MAC (ENET), Section 23.1.1 > "Features": > ----- > The theoretical maximum performance of 1 Gbps ENET is limited to 470 > Mbps (total for Tx and Rx)[...] The actual measured performance in an > optimized environnment is up to 400 Mbps. > ----- > > So, it seems that 400 Mbps is a real target. > > > As an interest off myself, when you already have such a setup running. > > Can you do a ping test to see what latency you get during bulk traffic > > and without? > > Currently I can't easily do such tests myself, since I have a full > > workbench with unrelated stuff. > > OK, here it is. Pining wandboard while it generates traffic to iperf > server (wandboard runs "iperf -c "). Pinging time window is > slightly broader then iperf one: > ----- > % ping wb2.bb.tel.ru > PING wb2 (192.168.100.211): 56 data bytes > 64 bytes from 192.168.100.211: icmp_seq=0 ttl=64 time=0.217 ms > 64 bytes from 192.168.100.211: icmp_seq=1 ttl=64 time=0.193 ms > 64 bytes from 192.168.100.211: icmp_seq=2 ttl=64 time=0.754 ms > 64 bytes from 192.168.100.211: icmp_seq=4 ttl=64 time=2.709 ms > 64 bytes from 192.168.100.211: icmp_seq=8 ttl=64 time=1.011 ms > 64 bytes from 192.168.100.211: icmp_seq=9 ttl=64 time=2.456 ms > 64 bytes from 192.168.100.211: icmp_seq=10 ttl=64 time=3.117 ms > 64 bytes from 192.168.100.211: icmp_seq=11 ttl=64 time=2.871 ms > 64 bytes from 192.168.100.211: icmp_seq=12 ttl=64 time=0.198 ms > 64 bytes from 192.168.100.211: icmp_seq=13 ttl=64 time=0.205 ms > 64 bytes from 192.168.100.211: icmp_seq=14 ttl=64 time=0.206 ms > 64 bytes from 192.168.100.211: icmp_seq=15 ttl=64 time=0.173 ms > ^C > --- wb2 ping statistics --- > 16 packets transmitted, 12 packets received, 25.0% packet loss > round-trip min/avg/max/stddev = 0.173/1.176/3.117/1.175 ms > ----- I was interested for my own project, but it also explains your results. Say 3ms and I remember having seen 32k Socketbuffer. This means you can send at most 32k in a single TCP connection before receiving an ackknowledge. Lets do the math with 3ms and 32k: 32k / 0.003 = 10666k Maybe it is testing bidirectional traffic, so you get doubled values, or the 3ms wasn't accurate and it is more like 1.5ms. To get 40000k with 32k in single stream your latency must be below 0.8ms. You can try using bigger buffers (32k is a traditional TCP limit, but all modern systems allow extended buffer sizes). But I expect this will just increase the latency. I assume there are many unsued features in the driver - should really take a look into the source, but this is quite complex and I never coded for such a complex ethernet hardware. The hardware has a lot of speeding features and it takes a very hughe part in the documentation. The good point is that there is documentation. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.