Greetings folks!
As this is my third post in this forum, i would like to take the chance to leave my compliments for this great community. You are very helpful and I hope you continue to be!
Pre-story:
I bought a ASRock J4205-ITX which is based on Intels "new" Apollo Lake architecture. The reason why i choose this system is because of its power consumption. It takes only 19 watts with two spinning HDDs. Imho this is a perfect base for a "green" private 24/7 Homeserver. Although I am a Linux professional, I chose FreeBSD as the operating system for two reasons: first, I think ZFS mirroring is the best choice for keeping my data safe in relation to integrity an redundancy, and FBSD seems to offer the best balance between technical integration and license compatibility. Second, I would like to look over the edge in relation to other Unix-like systems.
My configuration:
My issues:
After installing FBSD 11 from scratch I noticed three major problems:
1.: System time skews rapidly. The system is not able to keep its time in sync when using its "best quality" time counter TSC. I noticed after several hours of running a time difference of about 150+ seconds when setting it by ntpdate at system start.
2.: System response is very very slow. Friends, I know this is not the fastest machine on the market, and in fact this is a "low cost" category, but I cannot accept that a machine with 4 CPU cores even lags by typing commands into the shell.
3.: The network connection tears off when traffic goes up to high loads. This seems to be a general problem with kernels standard Realtek-NIC driver: keywords "re0 watchdog interrupts" which has already been discussed in the network-area.
Searching solutions:
To point 1: time keeps in sync when switching the counter
kern.timecounter.hardware from TSC to ACPI-fast:
I can live with that "solution" by placing "kern.timecounter.hardware=ACPI-fast" into the sysctl.conf
To point 2: after the (good) experience with stepping back in the quality line of the kernels chosen options, i tried to use the HPET-timer instead of default LAPIC
Unfortunately, this has not changed a bit. Response times of the system are still bad at all. 
To be constructive: seemingly there was a similar problem in Linux-Kernel which is described here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1606147. Is there someone out there who can check this issue in relation to the FBSD-Kernel?
To point 3: The problem is resolved by compiling Realtek's latest driver as a module into the kernel. I have issued some heavy load-tests, and it works pretty good.
Footer:
The easiest solution might be changing the OS, but giving up is not an option for me. And put your hand on your heart: this is not fun.
Maybe there are other people out there who have the same problems, or perhaps even solutions?
Best regards,
Marc
As this is my third post in this forum, i would like to take the chance to leave my compliments for this great community. You are very helpful and I hope you continue to be!

Pre-story:
I bought a ASRock J4205-ITX which is based on Intels "new" Apollo Lake architecture. The reason why i choose this system is because of its power consumption. It takes only 19 watts with two spinning HDDs. Imho this is a perfect base for a "green" private 24/7 Homeserver. Although I am a Linux professional, I chose FreeBSD as the operating system for two reasons: first, I think ZFS mirroring is the best choice for keeping my data safe in relation to integrity an redundancy, and FBSD seems to offer the best balance between technical integration and license compatibility. Second, I would like to look over the edge in relation to other Unix-like systems.
My configuration:
Code:
FreeBSD 11.0-RELEASE-p7 #0: Fri Jan 27 21:00:51 CET 2017
root@FreeBSD01:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
CPU: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz (1497.66-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x506c9 Family=0x6 Model=0x5c Stepping=9
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x4ff8ebbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,RDRAND>
AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
AMD Features2=0x101<LAHF,Prefetch>
Structured Extended Features=0x2294e283<FSGSBASE,TSCADJ,SMEP,ERMS,NFPUSG,MPX,PQE,RDSEED,SMAP,CLFLUSHOPT,PROCTRACE,SHA>
XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
TSC: P-state invariant, performance statistics
real memory = 8589934592 (8192 MB)
My issues:
After installing FBSD 11 from scratch I noticed three major problems:
1.: System time skews rapidly. The system is not able to keep its time in sync when using its "best quality" time counter TSC. I noticed after several hours of running a time difference of about 150+ seconds when setting it by ntpdate at system start.
2.: System response is very very slow. Friends, I know this is not the fastest machine on the market, and in fact this is a "low cost" category, but I cannot accept that a machine with 4 CPU cores even lags by typing commands into the shell.

3.: The network connection tears off when traffic goes up to high loads. This seems to be a general problem with kernels standard Realtek-NIC driver: keywords "re0 watchdog interrupts" which has already been discussed in the network-area.
Searching solutions:
To point 1: time keeps in sync when switching the counter
kern.timecounter.hardware from TSC to ACPI-fast:
Code:
kern.timecounter.choice: TSC(1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
To point 2: after the (good) experience with stepping back in the quality line of the kernels chosen options, i tried to use the HPET-timer instead of default LAPIC
Code:
kern.eventtimer.timer: HPET
kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) i8254(100) RTC(0)

To be constructive: seemingly there was a similar problem in Linux-Kernel which is described here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1606147. Is there someone out there who can check this issue in relation to the FBSD-Kernel?

To point 3: The problem is resolved by compiling Realtek's latest driver as a module into the kernel. I have issued some heavy load-tests, and it works pretty good.
Footer:
The easiest solution might be changing the OS, but giving up is not an option for me. And put your hand on your heart: this is not fun.

Maybe there are other people out there who have the same problems, or perhaps even solutions?
Best regards,
Marc
Last edited by a moderator: