Yes, like @ManoftheSea pointed out above, we are aware that the three onboard ports have a 1gig bottleneck at the SoC. However, with a 1gbps mPCIE card in addition to one of the built-int ports, there is a theoretical 2gbps path. I was only testing the lan0 + lan1 etherchannel group with the sole purpose of trying to get any of the built-in ports to show up in an etherchannel/bond interface (unsuccessfully, so far).
@lanefu, I appreciate your experience and insight, and I'd say you're right-on with your assessment of "typical" traffic going to a home fileserver. You have a good point to level-set for anyone coming across this thread, and this most certainly wouldn't be a great option for a HTPC or home media server. From my perspective, however, the Espressobin has a [theoretical] 6gbps path to SATA, but it's a shame the network bottlenecks to 1gbps. In my hypothetical use-case, there would be several hosts simultaneously accessing data on this server. Each of those hosts would have a single 1gig NIC, so of course there would be no point in going above that speed for any single connection. However, as more and more hosts try to access this share a the same time, a handful of 1gig clients could easily exceed a single interface, so an etherchannel would make sense.
Also, my experience comes from a work environment where a single link is a potential single point of failure. We don't install anything without redundant links, and an etherchannel is a great way to allow for automated failover in the even of one link failing without having to run some additional heartbeat software. I realize that's probably not something your typical home user is concerned with, but IMO it would be cool to have.
One final note along the lines of @lanefu's post, I should mention that in all my tests so far with dual 1gig links to the Espressobin, I am hitting a CPU bottleneck before ever getting close to 2gbps network speed. Obviously I don't have an etherchannel working yet (and I really don't know how that will affect CPU utilization for network throughput), but with one of the built-in ports on VLAN A, and the mPCIE port on VLAN B, using four other test boxes (2 on VLAN B, 2 on VLAN A), all doing reads, writes, or simultaneous reads and writes, I have been unable to achieve much over 100MB/sec total before the Espressobin cores both peg at 100%. I've done a few tests with NFS exports, and a few with NBD exports, but all my tests so far have been limited by the CPU on the server. I'll continue to test and tweak my setup, but at this point, I'm not sure this is the right platform for a high speed NAS server.
All that said, I'm still trying to figure out how to add one of the built-in ports to a bond interface... Any suggestions would be greatly appreciated!
Edit: Just to clarify, 1gbps (gigabits per second) is about 125MB/sec, minus overhead. 2gbps would be about 250MB/sec, give or take.
This is getting annoying. The deeper I look the more errors I find
My fix seems to work. I tried my fix with the current uboot firmware´s supplied by armbian and these are my findings:
- 1200 MHz: working fine, sbc-bench: http://ix.io/1BQ9
- 1000 MHz: I´m still trying to find out why this wont work for me
- 800 MHz: working fine, sbc-bench: http://ix.io/1BQr
- 600 MHz: could work fine, if the cpufreq init code would not mess up; at the moment it is just running at 300 MHz, sbc-bench: http://ix.io/1BQF
The problem with the 600 MHz is, that the parent clocks are running at 1200 MHz and a divider by 2 is used, but this is a problem for the cpufreq init code, because the cpu core frequency is 600 MHz and the cpu frequency which gets reported to the kernel is 600 MHz divided by the divider found in the dvfs which is 2.
So to fix this problem, the parent frequency has to be taken to report the right frequency to the kernel. As I don´t intend to run at 600 MHz I will ignore this problem, but regard it as reported with this post. If someone wants to fix it and needs more information just ask.
When I found out what the problem with 1000 MHz is and I fixed it, I will post the needed patches for fixing the cpu frequency for 800, 1000 and 1200 MHz.