Well, mixing issues and not monitoring what happens will successfully prevent finding a solution 
Regarding 'speed' it's necessary to rule out the obvious problems leading to bad iperf performance numbers (iperf being a problem itself here).
We already know how CPU bound iperf is so without checking cpufreq and CPU utilization all you generate are useless numbers when posting throughput results. So at least ensure you're using performance governor (I wouldn't use any of the other longsleep optimizations since they lead to a huge variation in numbers which makes it pretty hard to interpret results while they improve overall performance for sure).
Minimum requirements for any test are 3 SSH/Terminal sessions, one running htop, the other longsleep's pine64_health.sh script (sudo watch -n1 pine64_health.sh) and the 3rd with iperf3. And the following line in /etc/rc.local prior to 'exit 0':
(the 'sleep 30' will ensure that the board will switch to performance governor even if the distro used installed/uses cpufrequtils -- in that case adjusting defaults in /etc/defaults/cpufrequtils should also work). There are so many crappy OS images for Pine64 around that without running htop and pine64_health.sh it's simply impossible to tell why iperf results are low.
Please remember: there are still even OS images around that use horribly outdated kernels and old throttling settings. So when you run such an OS image and your board overheated sometimes between now and the last boot, then chances are great that not 4 CPU cores are active any more but maybe just one. pine64_health.sh will tell you what's going on and by looking at htop output you get an idea whether iperf is currently maxing out one CPU core or not.
The best idea is of course to stop using OS images that are known to cause problems (see the 'same MAC address' issue) but instead use longsleep's original Ubuntu image -- not the one from pine64 download section but the real one from http://forum.pine64.org/showthread.php?tid=376 or Armbian/Xenial (then you would use 'sudo armbianmonitor -m' to monitor board behaviour)
If you then get a difference of 280-290 mb/s vs 660+ mb/s with battery or not while htop output shows that iperf is not maxing out a CPU core and pine64_health.sh output tells you you're running with 1152 MHz clockspeed and all 4 CPU cores are active then it gets interesting. Otherwise not.
Regarding the GbE negotiation problem... well, switching from GbE to Fast Ethernet changes two completely different and unrelated things: consumption of the board drops by 350 mW (that might be related to powering problems, most probably undervoltage which could be measured on test points or at least on Euler pins 4/6 if still powering through Micro USB) and Fast Ethernet does not use 2 of the 4 cable pairs so only pins 1,2,3,6 are used (they are all meant to send/receive data unidirectional while 4,5,7,8 are bidirectional)
So if the workaround 'force Fast Ethernet' is working we're talking about something completely different, it's simply a different mode and both Pine64 and switch/hub/host connected to behave completely different. Don't look at iperf numbers that now tell something like 94 Mbits/sec and think about performance numbers. It's an entirely other mode, just a workaround and does not help to solve the real problem at all.
Regarding this 'real problem' it needs to be confirmed whether that's always an RX GbE negotiation problem or not (so does the problem always occur when testing in the same directions or do boards behave differently?). And then I would suspect it's pretty hard to get a clue without a real sniffer between Pine64 and the switch used.
Just as an example: another sunxi board (Lime2 from Olimex) shows very instable GbE links with most GbE switches in default slave mode (of course forcing the Lime2 to use Fast Ethernet workarounded the whole problem successfully) unless u-boot is patched to force the PHY into master mode: http://forum.armbian.com/index.php/topic...#entry7491 (the drawback is that with applied patch the board can not negotiate a GBit Ethernet connection with another device also forced to master mode)
Maybe it's just something like this (at least one board showing this behaviour worked flawlessly when being sent to longsleep in his environment). Maybe it's a combination of more issues (you reported that the area around the RTL8211E looks different on all your 3 boards) but without some methodology and differentiating between 'general' GbE speed issues and this specific negotiation problem I don't believe there will be any progress.
Regarding 'speed' it's necessary to rule out the obvious problems leading to bad iperf performance numbers (iperf being a problem itself here).
We already know how CPU bound iperf is so without checking cpufreq and CPU utilization all you generate are useless numbers when posting throughput results. So at least ensure you're using performance governor (I wouldn't use any of the other longsleep optimizations since they lead to a huge variation in numbers which makes it pretty hard to interpret results while they improve overall performance for sure).
Minimum requirements for any test are 3 SSH/Terminal sessions, one running htop, the other longsleep's pine64_health.sh script (sudo watch -n1 pine64_health.sh) and the 3rd with iperf3. And the following line in /etc/rc.local prior to 'exit 0':
Code:
(sleep 30 && echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor) &(the 'sleep 30' will ensure that the board will switch to performance governor even if the distro used installed/uses cpufrequtils -- in that case adjusting defaults in /etc/defaults/cpufrequtils should also work). There are so many crappy OS images for Pine64 around that without running htop and pine64_health.sh it's simply impossible to tell why iperf results are low.
Please remember: there are still even OS images around that use horribly outdated kernels and old throttling settings. So when you run such an OS image and your board overheated sometimes between now and the last boot, then chances are great that not 4 CPU cores are active any more but maybe just one. pine64_health.sh will tell you what's going on and by looking at htop output you get an idea whether iperf is currently maxing out one CPU core or not.
The best idea is of course to stop using OS images that are known to cause problems (see the 'same MAC address' issue) but instead use longsleep's original Ubuntu image -- not the one from pine64 download section but the real one from http://forum.pine64.org/showthread.php?tid=376 or Armbian/Xenial (then you would use 'sudo armbianmonitor -m' to monitor board behaviour)
If you then get a difference of 280-290 mb/s vs 660+ mb/s with battery or not while htop output shows that iperf is not maxing out a CPU core and pine64_health.sh output tells you you're running with 1152 MHz clockspeed and all 4 CPU cores are active then it gets interesting. Otherwise not.
Regarding the GbE negotiation problem... well, switching from GbE to Fast Ethernet changes two completely different and unrelated things: consumption of the board drops by 350 mW (that might be related to powering problems, most probably undervoltage which could be measured on test points or at least on Euler pins 4/6 if still powering through Micro USB) and Fast Ethernet does not use 2 of the 4 cable pairs so only pins 1,2,3,6 are used (they are all meant to send/receive data unidirectional while 4,5,7,8 are bidirectional)
So if the workaround 'force Fast Ethernet' is working we're talking about something completely different, it's simply a different mode and both Pine64 and switch/hub/host connected to behave completely different. Don't look at iperf numbers that now tell something like 94 Mbits/sec and think about performance numbers. It's an entirely other mode, just a workaround and does not help to solve the real problem at all.
Regarding this 'real problem' it needs to be confirmed whether that's always an RX GbE negotiation problem or not (so does the problem always occur when testing in the same directions or do boards behave differently?). And then I would suspect it's pretty hard to get a clue without a real sniffer between Pine64 and the switch used.
Just as an example: another sunxi board (Lime2 from Olimex) shows very instable GbE links with most GbE switches in default slave mode (of course forcing the Lime2 to use Fast Ethernet workarounded the whole problem successfully) unless u-boot is patched to force the PHY into master mode: http://forum.armbian.com/index.php/topic...#entry7491 (the drawback is that with applied patch the board can not negotiate a GBit Ethernet connection with another device also forced to master mode)
Maybe it's just something like this (at least one board showing this behaviour worked flawlessly when being sent to longsleep in his environment). Maybe it's a combination of more issues (you reported that the area around the RTL8211E looks different on all your 3 boards) but without some methodology and differentiating between 'general' GbE speed issues and this specific negotiation problem I don't believe there will be any progress.