Date: Sun, 4 May 2014 13:55:42 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: Boris Samorodov <bsam@passap.ru> Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: wandboard-quad: ffec performance (about 190 Mbits/sec) Message-ID: <20140504115542.GA71303@cicely7.cicely.de> In-Reply-To: <5366111B.5070503@passap.ru> References: <53654A67.6030605@passap.ru> <20140503202441.GD64774@cicely7.cicely.de> <5366111B.5070503@passap.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <server>"). 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 <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140504115542.GA71303>