Jump to content

Spemerchina

Members
  • Posts

    8
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Spemerchina reacted to spqr in Espressobin support development efforts   
    I ordered eight of the v7 units from GS and six of them couldn't make 48 hours before a freeze or kernel panic. Two of them stay up indefinitely.
    I concluded it was a hardware problem and am returning the units.
     
    PS: this was with their stock ubuntu kernel...
  2. Like
    Spemerchina reacted to Jbobspants in Espressobin - etherchannel?   
    Good info, guys!
     
    @Spemerchina any chance you could post a link to that 10gb Asus card you mentioned?
     
    My single-port network card arrived from Amazon today, along with a half-size to full-size mPCIE bracket. Everything went together easily and was recognized by Armbian right away. As soon as I booted there was a new "enp0s0" device in "ip link", and with a little fiddling in /etc/systemd/network/ I was able to get it to come up at boot and pull an IP automatically.
    Not much time for testing today, unfortunately, and I'll need to bring home a managed switch from work in order to actually test etherchannel performance.
     
    I also ordered this 2-port card from Ebay. It's coming from China so it will be 3 weeks, minimum, but at under $40 I figure it's worth a chance. Of course there are no details on the chip or anything, so there's no telling how much fighting I'll have getting the drivers to work.
  3. Like
    Spemerchina reacted to chrisf in Espressobin - etherchannel?   
    You have to make a choice with the shared SERDES lanes.
    Espressobin has already made that for you with it's PCB layout - one lane goes to SATA, one to USB3 and one to PCIe.
    There is only one lane on the PCIe slot, which is also apparently limited to 2.5Gb in early boards due issues running at PCI 2 speeds.
    The switch is connected via a 1Gb link to the 3270.
     
    Your physical limitations will be 2.5* or 5Gb on the PCIe slot and 3Gb on the SATA 2 connection. The 3Gb link uses 8b/10b encoding, so it's limited to 300MB/s.
     
     
    * OpenWRT has reduce PCIe speed to 1.0 
    https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=772258044b48036699302840abf96cd34c4e5078
     
  4. Like
    Spemerchina reacted to kostap in Espressobin support development efforts   
    Hello, @FlashBurn,
    FYI, the XTAL clock readout was fixed by Marvall LSP, but not yet taken into the mainline sources.
    The fix is available here:
    https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/80d4cec4cef8282e5ac3aaf98ce3e68fb299a134
     
    For reviewing the clock setup it is better to look though the a3700_utils sources.
    There is a big text table here describing the divider values:
    https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/blob/A3700_utils-armada-18.12/wtmi/sys_init/clock.c
     
     
  5. Like
    Spemerchina reacted to FlashBurn in Espressobin support development efforts   
    I just made the pull request with the 2 needed patches to make cpu frequency scaling working. These patches also fixed the problem with the 600 MHz firmware and the cpu scaling.
     
    Best would be if some people could test this on older revision boards. I also could not test this for the 1000 MHz firmware.
  6. Like
    Spemerchina reacted to Jbobspants in Espressobin - etherchannel?   
    Thanks for the nudge... from your post I assume it should just work like any other port. And yes, I had removed the port from the bridge before trying to add it to the bond.
     
    Ok, so I went ahead and did a fresh install of the latest official download, 4.19.20-mvebu64. Reconfigured from scratch, and sure enough, I was able to get the "wan" port and my mPCIE "enp0s0" to both join bonded port. Things don't work exactly as I expect, though. From a fresh reboot, for whatever reason the wan port doesn't automatically join the bond, but the enp0s0 port does come up. If I do "systemctl restart systemd-networkd", it comes back up with both ports in the bond. I've also tried a shut/no shut on the switch, but it only comes back up with enp0s0, wan is still not in the bond until I restart systemd-networkd.
     
    Full config from /etc/systemd/network, output of "ip addr" and "cat /proc/net/bonding/bond1" (before and after restarting systemd-networkd) are below.
     
     
    On a related note, my USB3 network adapter is still not getting link light after a reboot, but that is less of an issue now that I have 2 other ports successfully joined to the bond.
  7. Like
    Spemerchina reacted to lanefu in Espressobin - etherchannel?   
    Firs of all I admire everyone's quest for speed.   Finding every bit of performance available in these boards is a lot of fun.....  But allow me to provide a a brief sermon on link aggregation to manage expectations for those who many not have much experience.
     
    So I've gone down the NIC bonding rabbit hole many times on many pieces of equipment.   I even have LACP trunks going to my garage on principle.    It's really really hard to get a performance payoff on bonded gig links.    Single TCP streams are still only sent down 1 link at a time.     So things like iperf testing, most basic file IO tests etc, won't even send traffic on more than 1 link.   The smarter hashing algorithms will load balance the links to a degree typically based on MAC or IP:port for service.   Aka servers with dozens and dozens of clients work well because the bandwidth accross the 2 links can be distributed.  Even protocols like NFS 4.1 and SMB3.0 that have concepts of parallism still don't perform well with just 2 endpoints.    Typically it's been backup servers that are being absolutely pounded at the same time by many nodes at night, or VM hosts that I've ever gotten over 1 gig of traffic on LACP.
     
    The best performance I've been able to get using multiple gig links is by properly impementing iscsi with several initiators on a node and multipathing.   Since iSCSI is multipathing SCSI IO calls and not tcp it's able to deal wit the out of order stuff and you can really hammer your links.
     
    Best performance bet probably is using 10G and maybe you'll hit a few gigsabits on that.   IMHO I'd just focus on shaving latency down on your services and keep your networking stack simple.    If performance is really an issue... i'd probaly just brute force with a junky intel box.. or by a more purpose built board.
     
    PS in defense of the 1 gig SGMII lane using for the topaz switch to the CPU.... that's still 1GIG of full duplex traffic.. aka.. that's 1GIG of potential packet forwarding/filtering between WAN and LAN on the topaz.   In theory it's more potent than my edge router lite....  i'll have to test one day.
     
     
  8. Like
    Spemerchina reacted to Jbobspants in Espressobin - etherchannel?   
    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.
     
  9. Like
    Spemerchina reacted to FlashBurn in Espressobin support development efforts   
    So the good thing is I found the problem, the bad thing is I don´t know how to fix it
     
    The problem is, like I assumed, that the wrong clock source is selected or better to say, no clock source is selected and because of that it is the wrong one.
     
    In drivers/cpufreq/armada-37xx-cpufreq.c the dvfs is initialized. The right clock source should be selected with the 2 lines at the end of the function armada37xx_cpufreq_dvfs_setup(). But this does not call the needed function clk_pm_cpu_set_parent() in driver/clk/armada-37xx-periph.c.
     
    I fixed it for me with hard coding the right value in the registers.
     
    So all that is needed for fixing the problem is that the function clk_pm_cpu_get_parent() needs to be called, to get the right clock source and then clk_pm_cpu_set() needs to be called with that source. I don´t know enough about the clk code to know what needs to be done the right way.
     
    The question is now, whom to tell this, so that this could be fixed?
     
    This is a sbc-bench.sh run with my hard coded fix and 1200MHz: http://ix.io/1BCD
  10. Like
    Spemerchina reacted to Jbobspants in Espressobin - etherchannel?   
    How about with a mPCIE network card?
     
    Currently there is Syba Gigabit Ethernet Mini PCI Express card on Amazon for about $17. That particular card only gets you one additional port, but I have seen options with two ports (although I haven't found any 2-port models anywhere near this price point).
     
    Would it be possible to use a gigabit port on the PCI expansion slot in an etherchannel with one of the ports of the built-in switch to achieve a 2gbps link? I haven't figured out how to configure those built-in switch ports to anything other than the 3-port bridge yet, but I wonder how limited our options are with that Topaz switch in the middle.
     
    If the 2-port gigabit expansion card wasn't so cost-prohibitive, I think the mPCIE slot would have the bandwidth to do 2gbps by itself. Judging by tkaiser's benchmarks of the mPCI SATA expansion board, it looks like he's hitting between 250,000 and nearly 300,000 kiloBytes/sec when using a single drive on the expansion board. Of course that's dependent on the drive and several other factors, but that gives us an upper limit of at least 1.9 to 2.3 gigabits/sec.
     
    And of course this all assumes you're not already using the mPCIE slot for more SATA ports. :-\
  11. Like
    Spemerchina reacted to ebin-dev in Espressobin support development efforts   
    With kernel 4.12.1 and stock firmware 17.02 openssl performance was fine - with kernel 4.14.27 and firmware 17.10 (both versions compiled 15 March 2018 and 4 October 2017) openssl performance was degraded (see here).
  12. Like
    Spemerchina reacted to tkaiser in NanoPi M4 performance and consumption review   
    Really looking forward to this HAT
     
    BTW: I've not the slightest idea how much efforts and initial development costs are needed for such a HAT. But in case the Marvell based 4-port SATA solution will be somewhat expensive maybe designing another one with an ASMedia ASM1062 (PCIe x2 and 2 x SATA) and just one Molex for 2 drives might be an idea. Could be one design made for NEO4 that will work on M4 too with a larger (or dual-purpose) HAT PCB?
  13. Like
    Spemerchina reacted to dragonlost in NanoPi M4 performance and consumption review   
    http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M4_SATA_HAT
     
    News for SATA HAT ?
  14. Like
    Spemerchina reacted to Igor in Is ESPRESSObin v7 Supported?   
    There are no clear barriers between internal and external. If you or just somebody takes cover, than it will be supported. In any case it's hard to define "supported" for this board since nobody has all versions.
  15. Like
    Spemerchina reacted to Jens Bauer in espressobin power consumption   
    For anyone who wants to test power consumption, I'll recommend not supplying the board with 12V, but instead 5.2V, which is the minimum voltage required by the voltage regulator.
    The higher the input voltage, the higher power-loss you'll get.
    I recommend a good 5.2V PSU, which provides a heavy current like more than 3A.
    You can use a 6V PSU if you can't find anything lower, but just make sure that it can give the board a lot of current.
    For keeping power consumption down, I also recommend that you do not use the USB-ports nor the SATA port.
    That means booting Linux from the microSD card port - or if you want to cheat, you can supply an external harddisk with power from a different PSU and only connect the SATA data cable to the Espressobin. This will result in that the harddisk's power usage does not influence the measurements of the board itself.
     
    -And of course, as Thomas says - it's a very good idea shutting down peripherals you do not use.
     
    Unfortunately, there are things you can't change. The board has been sprayed with voltage regulators - even nested!
    I'm convinced that the board could have been designed a little better regarding this.
    I have not checked if you can shut down some of the power regulators completely, but even if you issue the "poweroff" command, the CPU is still running!!
     
    Things to consider:
    Powering a SATA drive from the board uses a lot of power. A 3.5" drive use much more than a 2.5" drive (check your drive's specs).
    USB devices use lots of power.
    MicroSD / MMC uses some power, but it's not extreme.
    A Mini-PCIe WiFi card uses a lot of power; I'm fairly convinced that the built-in Gbit Ethernet uses less.
    (unfortunately the Topaz switch has not been utilized very well on the board; it's fairly much a waste, it's just using power without giving extra performance).
    The DDR RAM uses a fair amount of power, but for good reasons it's not smart to turn it off.
    ... All those things add on top of the CPU's own power usage, which is said to be 1W.
     
    At the moment, I do not have the proper equipment ready for measuring the power usage on the board; but if I find a way, I'll be using a multimeter and a 5.2V power source - and I'll likely be running Armbian from the SD-card or perhaps cheating by running it from a SATA disk with a secondary power supply, so you can easily add your own numbers for the harddisks of your choice.
  16. Like
    Spemerchina reacted to ManoftheSea in Is ESPRESSObin v7 Supported?   
    I have an EspressoBINv7, I'm running Armbian 5.72 (Stretch) with kernel 4.19.  It appears to be supported.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines