On Tue, 2016-05-03 at 09:13 -0700, Vagrant Cascadian wrote: > On 2016-05-02, Vagrant Cascadian wrote: > > > > On 2016-05-02, Ben Hutchings wrote: > > > > > > On Sun, 2016-05-01 at 18:20 -0700, Vagrant Cascadian wrote: > > > > > > > > On 2016-04-28, Ben Hutchings wrote: > > > > > > > > > > Could you test with turbo_mode re-enabled and with this patch applied? > > > > > > > > > > Also could you test network receive throughput (e.g. with netperf -t > > > > > TCP_STREAM, sending *to* the RPi) in these three different > > > > > configurations: > > > > Ok, if I understood you correctly... > > > > > > > > Installed netperf on another machine, and ran: > > > > > > > > netperf -t TCP_STREAM 10.0.0.50 > > > That is not correct syntax; you need to put a -H before the IP address. > > Ok. Never used netperf before... will try again! > Ok, this time with: > > netperf -l 60 -t TCP_STREAM -H 10.0.0.50 > > 4.5.2-1, with turbo disabled: > > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 () > port 0 AF_INET : demo > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 87380 16384 16384 60.04 93.95
Interesting - it's very close to saturating the link even without turbo. (The maximum possible TCP throughput over and Ethernet with standard MTU is about 94% of the underling bit rate.) > 4.5.2-1, with turbo enabled: > > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 () > port 0 AF_INET : demo > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 87380 16384 16384 60.03 94.15 > > > 4.5.2, patched with turbo enabled: > > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 () > port 0 AF_INET : demo > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 87380 16384 16384 60.04 94.15 So the patch doesn't seem to hurt performance at all. From your previous mail: > For what it's worth, the patched driver did still appear to eventually > generate the error logs reported: > > smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped > > So at best, it reduces the problem, rather than solving it. I think the basic problem is you're giving this machine more tasks than will comfortably fit in its memory, added to which the swap device is slow (or maybe you disabled swap?). If this patch reduces the risk of failed buffer allocations then I think it's still a win. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999
signature.asc
Description: This is a digitally signed message part
