Note though, that RPis have never been the most price effective ARM solution, as Hardkernel has always had more powerful and/or cheaper alternatives. Their current N2+ is probably both more powerful and cheaper than the equivalent RPi.
Note though, that RPis have never been the most price effective ARM solution, as Hardkernel has always had more powerful and/or cheaper alternatives. Their current N2+ is probably both more powerful and cheaper than the equivalent RPi.
I'm not sure if this is a common/repeat thing, but for mine I need to maintain a build of the Realtek kernel modules out of tree
If I try to use the discovered/automatic/inline driver... it'll drop out if I try to saturate the link.
It's only when I blacklist this module and compile/use the one from Realtek that it works reliably
edit: This has been consistent through about a year of Fedora kernel releases, for what it's worth -- rather leading edge.
It's quite odd, this is with Fedora -- the current/latest release for about the past year (34 through 36).
It's seen quite a healthy number of 5.x kernels, but every time I try to go without I reluctantly have to build it again
It'll work fine, for a time, but when I really put stress on that link it'll drop
Edit: This is trained at multi-gig too -- going to a 10GbE Mikrotik switch.
I haven't tried testing reliability at 1G -- it's probably better, but I'd like the speed... I still have yet to try a 6.y kernel on it
Seeing they have a kernel PPA makes me suspect too that there's some patchwork going on, where I'm using vanilla Fedora kernels
When I say build it, I really mean allow dkms to function
I run on an unmodified 18.04 though (kernel v5.4), so I think that the support has been also added in a more recent 18.04 LTS patch version.
I'd be curious to know if you're connected at 1 or 2.5G, and if 2.5, how it does if held at that level for about a minute
An iperf3 test or two is usually enough to make it drop until I reboot
Where with the compiled module it's rock solid
The distro drivers (and/or) kernel drivers, are almost always garbage. Also make sure the NIC firmware is up to date.
Care to provide any rationale?
> The distro drivers (and/or) kernel drivers, are almost always garbage.
My experience is the exact opposite, vendor drivers are almost always garbage, and the kernel drivers just work.
For some vendors or kernels, certainly
However, this completely disregards the work companies like Intel and AMD do to upstream their drivers, or the leagues of individual maintainers
In many cases there is no difference, the driver in the kernel is the upstream one
Nvidia has been a notable exception, but they're slowly improving by going (partially?) open source
Realtek specifically has problems due to their shared driver core. For example, it often can't reliably tell the difference between an r8125 and r8169
This looks like a winner in every way.
x86_64 for longevity and support, tested with Ubuntu $latest LTS
decent CPU, better than Raspberry Pi
RAM up to 64GB, two SO-DIMM slots, up to 32GB per slot
M.2 NVMe storage
2 x 2.5Gbit Ethernet ports
2 x SATA 3.0 ports
Intel UHD Graphics, HDMI 2.0 and DP 1.2 video outputsSupports i2c, UART, USB, and hopefully manual pin control too. That's already miles ahead of a NUC in terms of interfacing.
From the set of pins provided I wouldn't get any hopes up for manual pin control. All pins are single-function, USB pins are almost never switchable (because they're high-speed analog-ish PHY functions), and UART & I2C are not GPIO-capable functions on most x86 platforms.