lanefu

All really great points, Zador.    Honestly it was meant to be a bit tongue-in-cheek, but I tend view all the non-raspberry development boards as something for more advanced users.   
 
The Raspberry eco-system is just hard to beat for newer users.   I recognize the price is a important consideration for new people as well, which is probably how many start off with allwinner-based stuff

Don't lose hope.. I asked Steven Zhao on Ali in late sept.   His response:
 
steven zhao 17/09/24 20:19   Yes, we are purchasing the materials for Plus2E now, it will be on stock next month  
 

I've created a wiki for the libre computer which has instructions for getting started, location of downloads and pinout diagrams.
more information here
http://wiki.loverpi.com/sbc-brand:libre-computer

PS: be aware of the non-Sunvell R69 - which uses the same case, but a Rockchip-CPU and not a Allwinner H2 
https://www.alibaba.com/product-detail/New-Arrival-Cheapest-4K-Android-TV_60687195434.html

TL;DR: The small H2+/H3 boards unlike their bigger siblings are all prone to overheating due to smaller PCB size (on the larger boards the PCB's groundplane acts somewhat as a large heatsink dissipating heat away from the SoC). Due to mainline kernel settings not being optimized currently all these boards are slower under constant load compared to legacy kernel. This should change but won't unless someone is looking into it and spends some time on this.
 
Two areas that deal with this overheating tendency or are somewhat related are
 
thermal protection / throttling: use the thermal sensor(s) inside the SoC to downclock various engines if specific tresholds are exceeded DVFS (dynamic voltage frequency scaling). All the small boards have either no voltage regulation (NanoPi NEO2) or a primitive one only switching between 1.1V and 1.3V  
With sun8i legacy kernel Armbian and linux-sunxi community members spent a lot of time and efforts on improving thermal/throttling performance. Read through the following as a reference please: https://github.com/armbian/build/issues/298
 
The result of our optimizations was a lot of better performance compared to Allwinner's defaults (that targeted only Android and preferred higher single thread performance over overall better performance, with Allwinner settings on an overheating system you could end up with just one or two active CPU cores pretty easily). Now with mainline kernel situation for the larger H3 boards is ok-ish (those boards have an I2C adjustable voltage regulator, voltage switching works fine grained, overheating isn't much of an issue anyway and performance is almost as good as with legacy kernel). But situation with the smaller boards needs some attention.
 
If we run the cheapest boards currently with mainline kernel then we're talking about these settings:
 
max cpufreq 1008 MHz (at 1.3V), next lower cpufreq 816 MHz at 1.1V, then 624/480/312/240/120 MHz defined 4 thermal trip points defined starting at 65"C with throttling, then using 75° and 90°C and shutting board down when 105°C are reached.  
With Armbian and using legacy kernel it's the following instead:
 
max cpufreq is 1200 MHz, then 1008 MHz still at 1.3V, at 912 MHz we switch to 1.1V and below are a few other cpufreqs available between 816 MHz and 1344 MHz Armbian's legacy kernel provides cpufreq steps every 48 MHz (allowing for fine grained throttling) On the small boards we use twice as much thermal trip points as mainline settings and our strategy is to switch to 912MHz@1.1V pretty early once throttling occurs  
These differences result in both lower 'normal' performance (since mainline kernel limits also single threaded tasks to 1GHz instead of 1.2GHz) and also 'full load' performance since DVFS/THS/throttling settings are not optimal and once the board reaches the first thermal trip point throttling is not that efficient compared to legacy.
 
It's easy to test: grab an OPi Zero, NanoPi Duo or any of the other H2+/H3 boards with primitive voltage regulation, then grab an Armbian OS image with legacy kernel (3.4.113 using fex settings) and one with mainline kernel. Execute on both
 
sudo rpimonitor -r (installs RPi-Monitor so you can enjoy nice graphs when connecting with a web browser to port 8888 of your machine) sudo rpimonitor -p (installs cpuminer which is a great tool to heatup your board and also to measure 'thermal performance' since spitting out khash/s values in benchmark mode minerd --benchmark (this is the actual benchmark running)  
With mainline kernel performance is lower. Expected result: same performance. What to do? Improve mainline settings.
 
BTW: Mainline settings currently are as they are since these were the values megi started with last year. Once numbers exist they're only dealt with copy&paste any more.

You can actually squeeze a NanoPi Duo, RJ45 MagJack (LED,GND pins off), a USB port, and tiny buck converter on a half-size breadboard.


 
Seems to be working fine with a user built stretch image for the Orange Pi Zero target, at least initially.
Max current @12vDC I saw was under 400mA with sysbench and WiFi running but more tests are needed.

What do we know now? Not much  -- most importantly that some details will change and 'board available soon'.
 
We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them  )
 
So all we know is really just:
H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo)  One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)

I found out that I can upgrade to 300/50 for no extra money or hardware upgrade and I did it a week ago. Upload is now 5x faster and can be further upgraded but I think there is no need. Daily kernel recompilation is present on the download/repository server until morning - recompilation starts at 00.01. Hopefully, there should be less different kernels to build, so this setup should last. Only server memory is getting low at the moment since we get new sources - I tend to cache them to gain some speed and save SSD. Building utilisation is low at .deb packing and EXTRA packages building as Zador already explained ...

Network Manager does have its weaknesses and behaves sometimes erratic.  SBCs with more than one network interface such as the ClearFog Pro, ClearFog Base and  EspressoBin may require more complex configurations (i.e. firewalled router) - to realise that in a reliable way using Network Manager is a nightmare. Even bridged interfaces lead to erratic interruptions during boot.
 
One could switch to systemd-networkd - it is already installed and just needs to be configured. No more hassles with jobs for raising network interfaces  .
 
Interfaces wan, lan0 and lan1 are hot-pluggable and work with full speed (iperf3 results are as expected: 112MByte/s and 103MBytes/s in reverse direction). A working example configuration for bridged network interfaces is here:
#purge network manager: apt-get --purge autoremove network-manager #copy three lines to the interfaces file: cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback #start services and create a symbolic link to resolv.conf: sudo rm /etc/resolv.conf systemctl start systemd-networkd.service systemctl start systemd-resolved.service systemctl enable systemd-networkd.service systemctl enable systemd-resolved.service ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf #create the 5 network configuration files in /etc/systemd/network/ #(do not delete empty lines): cd /etc/systemd/network/ cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge cat 10-dhcp-br0.network [Match] Name=br0 [Network] DHCP=ipv4 cat 10-dhcp-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 cat 10-bridged-lan0.network [Match] Name=lan0 [Network] Bridge=br0 cat 10-bridged-lan1.network [Match] Name=lan1 [Network] Bridge=br0 #and restart systemd-networkd: systemctl restart systemd-networkd  

This might be close to be off-topic, but I think this is the closest forum for this thread.
 
Since I read that Igor asked if we know any build-farm services (clouds like Amazon's EC3 or the like), I've been thinking about private build farms.
 
I imagine that Igor does not have a large build farm (perhaps some boards are contributing with distcc).
Thomas, what is your setup for building Armbian ? (I imagine that you may have a stronger setup).
Other developers, please chip in too.
 
What's been in my mind for a while, is to make a low-cost farm, which would perform well and make things easier and quicker for the Armbian team. There's a lot of maintaining of the source code, so I doubt there's time for expanding compile-clusters.
 
So my idea is that first of all, I get that ubuntu Xenial running on a 64-bit intel CPU is the minimum requirement for a build-master.
That is due to some of the tools that Armbian uses. If those tools were able to run on an ARM-based architecture, it would be easier for me to find a good build-master for Armbian (I'm going to use MacchiatoBIN for my own builds).
The slaves would most likely be MiQi boards as they perform better than even the S912 competitors (but they also use more electricity).
Finally I plan to use solar power to assist in paying the bill.
 
When all is set up, I think it would be very useful to add external build slaves as well (such as every developer's build slaves, so that distcc can do the job as quickly as possible. I know that more isn't always better; it depends on the connection speeds and the speeds of the slaves, latencies and a lot of other things.
-Still the goal is to get an almost 'free' build farm, which is able to build Armbian on its own (so if you're on a non-intel platform (such as PowerPC or ARM), then you will be able to make your own builds anyway by using my build-master.
On the other hand, if you have a 64-bit intel machine, then it would probably be beneficial to use that as a build-master, because local is usually faster than remote. It can use the compile-cluster for compiling, but the intel-only tools could be run locally.
 
I might not be able to succeed in all this; it's an expensive project and I have many higher priorities than making a build-farm; but if things go my way, I might be able to move the priorities around (I certainly want to).
Maybe I'll be able to start out with a few MiQi boards and no build-master and then expand over time.

You can compile your own Armbian xenial image with headers (still without asm/*) but with cpufreq support:
apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build nano ./config/sources/mvebu64.conf #change the last digit in case 'default' to: KERNELBRANCH='branch:linux-4.4.52-armada-17.06' #change to: MAX_SPEED=1000000 ./compile.sh BOARD=espressobin BRANCH=default BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes INSTALL_HEADERS=yes RELEASE=xenial During kernel configuration select: CPU Power Management - CPU Frequency Scaling - Default Governor - ondemand
and you may disable other governors. Output is Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.87.img with cpufreq ondemand governor enabled..
 
More information about the Armbian build system can be found here: https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
EDIT: @lanefu  A commit for changing /config/sources/mvebu64.conf to default KERNELBRANCH linux-4.4.52-armada-17.06 and to MAX_SPEED=1000000 would avoid breaking cpufreq when updating Armbian xenial 4.4.73 images.

I've been super fascinated with the DSA stuff since my espressobin first exposed me to it's existence.      The thing I don't quite grok with DSA is if I'm trying to do any layer 3 stuff on the switch ports,  such as inter vlan routing is whether or not I'm always limited by the RGMII or whatever link the DSA chip is using to connect to the SoC.    
 
You have described a pretty ideal board.   A DSA with a cheap 4 core SoC is enough horsepower to brute force doing all sorts of cool network stuff without being so reliant on hardware offloading like on my EdgeRouter Lite.     Now that VyOS has ported their build over to supporting Jessie, I've been hoping to eventually rig up a VyOS installer armbian similar to the OMV userpatches installer.    

STP is probably https://en.m.wikipedia.org/wiki/Spanning_Tree_Protocol


Verzonden vanaf mijn iPhone met Tapatalk

Yes, but I have missed one patch which may or may not be important. It will have to wait till tomorrow.
 
For now, yes. I guess this doesn't really matter since we could squash all HDMI patches to one?
 
Driver should work (not tested), but DT must be updated.
 
Once everything works, I was thinking about adding Mali driver. Fortunately, we could borrow properly licensed X11 driver from CHIP.

Hi Igor,
 
Yes completely understandably.
I just meant odd in the sense that it's look to be more of a copy paste from opione.
I will have a look and see if I can get it going and contribute.
 
regards,

I'm augmenting my iBook G3 with my pcDuino3 Nano to act as a wireless gateway and host for a development toolchain.
It's working fine so far and once I'm done it will be completely powered by the FireWire port
 
The only downsides are that it is a bit big and at idle it's taking ~250mA which I'm going to have to play with at some point and
see if I can get it down any more.

Ahh ok,
 
Thank you. It seems that the voltage regulator on the zero is supported (its just GPIO) and it has the same regulator as one the orangepi-one. So it should just be a matter of adapting that from the orangepi-one dts and to add DVFS and higher speed to the zero as well.
 
It's a bit odd that this has not been done but it seems to be implemented on later kernel version.
 
Thank for your answer!
regards,

u-boot 17.08.1 flash images for all combinations of Marvell supported CPU/DDR3 frequencies (600/600, 800/800, 1000/800, 1200/750)
 
With kind support of @Igor and @aldzune I could build and test u-boot 17.08.1 and 17.06.3 flash images for all frequency combinations indicated above (boot snippets 17.08: https://pastebin.com/kKTvP5sx and 17.06: https://pastebin.com/8DZ37Wti , available functions: https://pastebin.com/kN5WBjW9 ). 
 
The flash-image.bin files (u-boot-images.tar.gz are attached below) just have to be resident in the root directory of a USB stick attached to the Espressobin and they can be flashed at the u-boot prompt:
 
Marvell>> bubt flash-image-XXX_YYY.bin spi usb       
(XXX: CPU Frequency, YYY: DDR3 Frequency)
 
'ARMBIAN 5.32.170817 nightly Debian GNU/Linux 9 (stretch) 4.4.82-mvebu64' boots smoothly in all 4 scenarios (see i.e. https://pastebin.com/KkZsU8sk ). (A static IP address is assigned in /etc/network/interfaces to get rid of the 'raise network interface' issue)
 
EDIT:
With the new firmware I receive I/O errors after some time while accessing the sd card.
The firmware needs to be properly tested by Marvell / Globalscale Technologies and made available by them.
Please contact Globalscale Technologoies / Marvell if you are interested in a more recent firmware.
 

Clearfog PRO with Linux 4.12.4-mvebu Samsung 840 PRO utilization:
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 62501 101691 98761 94430 34522 93050 102400 16 183325 215091 231439 232948 101667 171875 102400 512 301985 307789 341261 344567 328849 309560 102400 1024 294818 309177 345099 347791 339763 309775 102400 16384 271066 344426 384226 388587 387169 346825 2 x Samsung 840 PRO in RAID0, ext4 utilization:
random random kB reclen write rewrite read reread read write 102400 4 67614 95508 94561 94984 32561 74157 102400 16 174075 200947 222430 223840 109654 199578 102400 512 307905 294689 317652 308007 307057 268841 102400 1024 307821 317784 327007 330213 322851 317024 102400 16384 286193 383463 394221 398474 397951 374333  
Logs: http://sprunge.us/CfRS 
Controller temperature is stable at 64°C, network utilization is also at top speed.  Card was donated via Amazan wish list. Thank you!


 
Hummingboard 2 with Linux 3.14.79-cubox (mainline not working out of the box)

Not that impressive as Clearfog,  but works. 
random random kB reclen write rewrite read reread read write 102400 4 28502 39271 37895 37983 22325 38821 102400 16 68494 80988 69940 70511 53264 80047 102400 512 116594 118132 93789 94280 92828 118884 102400 1024 138185 140277 122610 123717 120853 139393 102400 16384 183976 183169 151745 153813 151890 179652 Logs: http://sprunge.us/OeMY
 
Espressobin
2 x Samsung PRO 840, RAID 0, BTRFS
http://sprunge.us/iBFS
random random kB reclen write rewrite read reread read write 102400 4 21547 20493 37509 37024 21747 17728 102400 16 61955 56230 93068 93795 64349 45724 102400 512 188611 186828 175688 176961 172098 185109 102400 1024 215817 216559 189477 191846 188481 214727 102400 16384 226764 228502 229162 238883 222826 229894 Intel N4200 / Up2board Square
1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 65003 76031 93147 92507 32024 73029 102400 16 146880 175968 187734 224409 106025 163916 102400 512 244782 225736 348401 357949 343145 221037 102400 1024 239203 247778 313476 313372 309170 248540 102400 16384 254396 266530 357708 368483 370731 276458 2 x Samsung 840 PRO in RAID 0 random random kB reclen write rewrite read reread read write 102400 4 61680 70018 67650 66635 18221 67984 102400 16 145869 164784 147884 143877 46355 160169 102400 512 230140 219870 213069 199087 213587 210607 102400 1024 273150 271782 257206 279397 275632 271896 102400 16384 314895 311385 365117 376228 375081 317790 Native onboard SATA 1 x Samsung 840 PRO random random kB reclen write rewrite read reread read write 102400 4 70611 80842 100647 97276 30072 77666 102400 16 194707 208422 239401 224119 102211 218393 102400 512 346735 410867 401536 425167 396013 412711 102400 1024 374032 366490 378981 394321 382352 368195 102400 16384 441298 430380 475063 486540 482151 414518 Reference: A20's native SATA
 

This document is work in progress ...

Update.
 
Pinebook was my Beachbook for some time. I used it for email, browsing, IRC and terminal. It proved to be sufficient while once it didn't start charging (from 5%) even plugged to charger - unplug / plug back solved that - and "heavy" Chromium usage ate all resources. I think we need to check Chromium caching - when using let's say about 10 tabs for some time - RAM is going down, swap is not getting used and system just become extremely slow / unresponsive. My environment did not provide enough motives for exploring the problem deeper 

I'll try to build dev image with desktop at first.
My LCD was hdmi 5inch 800x480. I confused the resolution.
After testing, I'll share the result.
Thank you very much.

Thanks to @lupus I don't have to wait for Amazon shipping my board since one is already on my desk. Firtst surprise: my ASM1062 in the background can not be used due to SATA connector placement. So then I'm going to test AP functionality instead with a AR9380 3x3 MIMO Wi-Fi mPCIe card ($9 on eBay)

The puzzle seems to be solved - the ondemand governor does not scale up the cpu frequencies as expected.
Armbianmonitor -m always displays a maximum of 200MHz as the current cpu frequency:
root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 15:26:36: 200MHz 0.16 13% 3% 9% 0% 0% 0% 15:26:41: 0MHz 0.14 13% 3% 9% 0% 0% 0% 15:26:46: 200MHz 0.13 13% 3% 9% 0% 0% 0% 15:26:51: 200MHz 0.20 13% 3% 9% 0% 0% 0% 15:26:56: 0MHz 0.39 14% 3% 9% 0% 0% 1% 15:27:01: 0MHz 0.36 14% 3% 9% 0% 0% 1% 15:27:07: 200MHz 0.41 14% 3% 9% 0% 0% 1% 15:27:12: 200MHz 0.38 14% 3% 9% 0% 0% 1% 15:27:17: 200MHz 0.35 14% 3% 9% 0% 0% 1% 15:27:22: 0MHz 0.32 14% 3% 9% 0% 0% 1% 15:27:27: 200MHz 0.29 14% 3% 8% 0% 0% 1% 15:27:32: 200MHz 0.27 14% 3% 8% 0% 0% 1% Manually setting the frequency of both cpus to 1GHz leads to expected results of iperf3:
root@espressobin:~# cpufreq-set -c 1 -d 1000000 -u 1000000 -g performance root@espressobin:~# cpufreq-set -c 0 -d 1000000 -u 1000000 -g performance root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 15:38:48: 1000MHz 0.15 8% 2% 3% 0% 0% 1% 15:38:53: 1000MHz 0.13 8% 2% 3% 0% 0% 1% 15:38:58: 1000MHz 0.12 7% 2% 3% 0% 0% 1% 15:39:04: 1000MHz 0.19 8% 2% 3% 0% 0% 1% 15:39:09: 1000MHz 0.26 8% 2% 3% 0% 0% 1% 15:39:14: 1000MHz 0.24 8% 2% 3% 0% 0% 1% MacBookPro: admin$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 4] local 192.168.240.41 port 49642 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 73.5 MBytes 616 Mbits/sec [ 4] 1.00-2.00 sec 110 MBytes 920 Mbits/sec [ 4] 2.00-3.00 sec 108 MBytes 904 Mbits/sec [ 4] 3.00-4.00 sec 105 MBytes 881 Mbits/sec [ 4] 4.00-5.00 sec 105 MBytes 881 Mbits/sec [ 4] 5.00-6.00 sec 104 MBytes 874 Mbits/sec [ 4] 6.00-7.00 sec 106 MBytes 885 Mbits/sec [ 4] 7.00-8.00 sec 106 MBytes 885 Mbits/sec [ 4] 8.00-9.00 sec 106 MBytes 886 Mbits/sec [ 4] 9.00-10.00 sec 103 MBytes 867 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.00 GBytes 860 Mbits/sec sender [ 4] 0.00-10.00 sec 1.00 GBytes 860 Mbits/sec receiver iperf Done. MacBookPro: admin$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 4] local 192.168.240.41 port 49645 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 4] 1.00-2.00 sec 112 MBytes 936 Mbits/sec [ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec [ 4] 4.00-5.00 sec 112 MBytes 937 Mbits/sec [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec [ 4] 7.00-8.00 sec 112 MBytes 936 Mbits/sec [ 4] 8.00-9.00 sec 112 MBytes 936 Mbits/sec [ 4] 9.00-10.00 sec 112 MBytes 937 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec receiver iperf Done.  

There are only specific frequencies supported with the current system:
root@espressobin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 200000 250000 500000 1000000 However, cpufrequtils is currently configured to use another maximum value:
root@espressobin:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=200000 MAX_SPEED=800000 GOVERNOR=ondemand I have changed MAX_SPEED to 1000000 but unfortunately espressobin does not boot reliably anymore (crashes upon login).
 
I have received my order of 10 espressobin this week ($49 each plus shipping) - I still have 7 to give away for the price I have paid. I have sent to you a PM with my contact details in any case ...

My default workstation. Soon it will be deserted on those small notebooks for summer time.
 
Usually there is, little but not much, random clutter around: papers, cables and boards. Core testing and debugging infrastructure is on the right side. Under the table I have two fix mounted and easy accessible USB powered hubs, which serves as powering and debug. Half ports have secured 1.5A per port. 14 ports in total, connected to server and shared around the network. Powering via extended USB3 hub proved to be enough in most cases, for rest and for special cases I use their original power supplies. which are somewhere below, differentiated with colours. Than there are 15 gigabit and 5 fast Ethernet ports and 2.4G AP. Since I am software developer first and tinkerer second, 40" of property is central point of interest. Sometimes it also get too small and also to avoid more cables, I have another fixed 19" in debug section. On the top of folder shelves I got an extremely low noise build server and another cabinet of electronics stuff. Lower left cabinet is place for small desktop computer and printer, while right side is filled with various parts, from cables, bigger boards, soldering equipment, hard drives, etc. Most of cables are hidden / embedded, to make this mess manageable. When I don't play with boards, I move cabinets in upper level and make use of whole table (minus keyboard and mouse).