Dual Intel LAN NUC!

TotallyInsane

Similar to _Rogue I was also looking for a pfsense wlan router with <10W, small and enough power to OpenVPN >50 Mbit (and in an ideal case 100MBit for the upcoming VDSL2 line) and ended up with the noted Jetway HBJC311U93W-2930-B and just replaced the internal half-sized intel wlan with an atheros version. And while rather early, the device seems to do the job.

Regarding power usage: with pfsense 2.1.5, Kingston 60GB SSD, 4GB ram, network, HDMI and a Logitech K400 keyboard connected the jetways power usage is 8.5W when idle - wich is much lower than I expected with HDMI on.

The other cheaper available solution I considered was the Mitac E220 based on the J1900 and dual lan (but no Intel NICs).

Otherwise I agree with gonzopancho, if you have the time to wait, I guess there will be plenty of nice hardware coming up next year with AES-NI support to allow very fast VPNs in small devices with <10W. But isn't there always a better solution next year? And the HBJC311U93W-2930-B will still be usefull for other jobs (media player, …) once replaced.

stephenw10

8.5W is impressive. How are you measuring it? Do you have powerd enabled? Does it recognise such a relatively new cpu?

Steve

Guest

So what did you choose for Atheros radio. I have a bunch and finally found a good half card.
Dell Alienware AR5BHB112.
Only Atheros 450M half card i could find.
I bought the DC3217IYE to build a mifi hotspot.

Guest

I like that the Jetway uses wide range of input voltages. From 9V-24V. To me that is very versatile. I am guessing the intel NUC is 19V only?~??
I will fire up adjustable power supply and test when it arrives. I am really hoping it works at 12V as i would like to incorporate a PicoUPS into my MIFI so i can carry it from the car to an outlet with a battery pack I want to build it with 12V-12AH SLA batteries and an plastic enclosure..I'm thinking lunchbox design with battery on bottom and the computer on hinged lid with a handle outside..

TotallyInsane

The 8.5W with pfsense 2.1.5 on the jetway HBJC311U93W-2930-B were without any additional power optimzations done. Just the default pfsense settings. I only did setup the LAN ports. But considering the old pfsense version and nor could I find any other data available online, I tried other systems incl. pfSense 2.2 (amd64-20141108-0611).

Now let's summarize the idle power findings:

pfsense 2.1.5 no tweakings:          8.5W
pfsense 2.2   no tweakings:         10.0W
pfsense 2.2   PowerD enabled:        9.7W
ipfire 2.15   no tweakings:          8.8W
ipfire 2.15 (powertop savings):      7.3W

All tests were made with HDMI on and usb keyboard connected. Default A01 BIOS settings.
Without HDMI/usb devices connected the above values are only further reduced by 0.2-0.3W.

I am new to FreeBSD (do have Linux experience), but I really wonder what those high pfsense 2.2 values are causing. The CPU is rather idle and thus there is no process causing this. Any help/recommendation would be great as good non-obsolete info on powerd on FreeBSD seems hard to find. On Linux enabling the powersaving of usb/PCI/sata/audio as recommded by powertop reduced the consumption by 1.5W and with pfsense 2.2 there needs to be done more to become competitive.

stephenw10: power measurements were made with a small old power meter EKM 265 from ELV. The low power measurements in the past were pretty
compareble to figures published based on a professoinal LMG 95 device from ZES. So they are unlikely completly off ;-) I also did some measurents using a Fritz!Dect 200 wich provides 0.15W higher values on the jetway and allows displaying the power usage over time.

Phishfry: I bought a noname Atheros 9280 card. I avoided the newer cards for now, as I allready would be lucky to get this one working reliable. I had my share of driver problems with atheros in the past on dd-wrt and OpenWRT devices. Never worked 100% reliable.

And at last some openssl benchmarks results. During those tests the power usage increased by 2-3 watt. Sorry I had no tools for a quick max test. But based the Intel NUC measurements published, I guess with CPU and GPU maxed out you can get 16-17W - very unlikely values in routing practice wich should stay <10W if pfSense 2.2 power usage is optimized.

pfsense 2.2:
OpenSSL 1.0.1i-freebsd 6 Aug 2014
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: cc
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              14908.20k    58849.61k   155058.26k   265082.06k   334230.87k
sha1             17859.42k    55769.09k   126660.18k   186410.67k   216241.49k
des cbc          36870.12k    39487.79k    40424.19k    40656.21k    40716.97k
des ede3         14402.27k    14809.69k    14941.95k    14975.32k    14944.25k
aes-128 cbc      37023.75k    41897.60k    43502.68k   109868.71k   111091.71k
aes-192 cbc      31610.94k    34957.65k    36090.50k    93038.25k    93937.66k
aes-256 cbc      27236.69k    29907.31k    30949.97k    80860.47k    81214.77k
sha256           15787.31k    35099.65k    59627.26k    72193.37k    76961.11k
sha512           12212.90k    48712.92k    75503.70k   105785.00k   120015.53k
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.005758s 0.000221s    173.7   4533.4
                  sign    verify    sign/s verify/s
dsa 2048 bits 0.001743s 0.002090s    573.6    478.4

ipfire 2.15:
OpenSSL 1.0.1j 15 Oct 2014
built on: Thu Oct 16 11:14:49 GMT 2014
options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DSSL_FORBID_ENULL -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGEST -DL_ENDIAN -DTERMIO -Wall -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fPIC -fstack-protector-all --param=ssp-buffer-size=4 -march=i586 -mtune=generic -fomit-frame-pointer -DPURIFY
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              11160.98k    39212.15k   111467.05k   208104.08k   279203.13k
sha1              8932.52k    25254.60k    52538.79k    72554.47k    81828.34k
des cbc          17631.95k    18286.85k    18464.98k    18526.98k    18565.72k
des ede3          6923.09k     7041.20k     7061.36k     7067.37k     7086.37k
aes-128 cbc      42861.52k    46583.46k    47833.87k    48221.22k    48377.84k
aes-192 cbc      37666.14k    40351.69k    41397.66k    41620.11k    41756.29k
aes-256 cbc      33229.59k    35514.66k    36174.95k    36391.55k    36339.38k
sha256            8464.54k    20115.75k    36104.36k    45101.31k    48788.85k
sha512            2480.39k     9917.46k    14650.50k    20254.65k    22848.81k
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.049082s 0.001477s     20.4    676.9
                  sign    verify    sign/s verify/s
dsa 2048 bits 0.013782s 0.016444s     72.6     60.8

kejianshi

The only good way to measure power draw is with a amp meter… On the cord that plugs into the wall or battery power.

But I'm sure its quite low.

I'd like to have one of the new atom 8 core boards but I'd run alot more than just pfsense on it.

stephenw10

My first thought is that the much newer drivers in 2.2 (built on FreeBSD 10.1) is enabling some hardware that 2.1.5 doesn't. Maybe the ACPI stuff is working significantly differently.
It's a little old now but this is pretty much the definitive document in saving power in FreeBSD:
https://wiki.freebsd.org/TuningPowerConsumption

Steve

TotallyInsane

kejianshi: It's a True RMS based measurement at the power plug at the wall. So I do not know what is wrong with that other than the device not being as accurate as the noted LMG 95.

stephenw10: I already run into the site you noted. But as said, I am new to FreeBSD and thus the note like "hint.ahcich.X.pm_level" is something I do not easily understand (like how to determine the X.Y devices on FreeBSD?). And shouldn't a PowerD configuration handle these things? So there are lot's of time consuming searching coming up to get answers.

kejianshi

There is nothing wrong with it. Thats the way to measure it.

TotallyInsane

I have done some testing on pfsense 2.2 and I think the cause for the higher power usage is that the CPU is not switching to >C1 states on the jetway NUC. I already tried all sorts of things: disabling throttle+p4tcc, trying to set hw.acpi.cpu.cx_lowest="C3" and various P-State settings in the BIOS, but after booting hw.acpi.cpu.cx_lowest remains on C1 and no change to dev.cpu.0.cx_usage. Strangely dev.cpu.0.cx_supported does list C2/C3. No obvious problem reported in dmesg either.

Being a FreeBSD/pfsense user for just some hours, I wonder if this is a limitation of FreeBSD on Bay Trail-M? A BIOS problem? A missing setting in rc.conf?

Any idea what I could try next? C6 does work with ipfires Linux kernel 3.10 so it's not completly broken.

dev.cpu.0.freq_levels: 1826/2000 1660/1825 1494/1650 1328/1475 1162/1300 996/1125 871/984 830/950 726/831 664/775 581/678 498/600 435/525 373/450 311/375 249/300 186/225 124/150 62/75
dev.cpu.0.cx_supported: C1/1/1 C2/2/500 C3/3/5000
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 384us
dev.cpu.0.coretemp.delta: 60
dev.cpu.0.coretemp.resolution: 1
dev.cpu.0.coretemp.tjmax: 105.0C
dev.cpu.0.coretemp.throttle_log: 0
dev.cpu.0.temperature: 45.0C
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1/1
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% last 88273us
dev.cpu.1.coretemp.delta: 60
dev.cpu.1.coretemp.resolution: 1
dev.cpu.1.coretemp.tjmax: 105.0C
dev.cpu.1.coretemp.throttle_log: 0
dev.cpu.1.temperature: 45.0C
dev.cpu.2.%desc: ACPI CPU
dev.cpu.2.%driver: cpu
dev.cpu.2.%location: handle=\_PR_.CPU2
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%parent: acpi0
dev.cpu.2.cx_supported: C1/1/1
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_usage: 100.00% last 79us
dev.cpu.2.coretemp.delta: 56
dev.cpu.2.coretemp.resolution: 1
dev.cpu.2.coretemp.tjmax: 105.0C
dev.cpu.2.coretemp.throttle_log: 0
dev.cpu.2.temperature: 49.0C
dev.cpu.3.%desc: ACPI CPU
dev.cpu.3.%driver: cpu
dev.cpu.3.%location: handle=\_PR_.CPU3
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%parent: acpi0
dev.cpu.3.cx_supported: C1/1/1
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_usage: 100.00% last 39747us
dev.cpu.3.coretemp.delta: 56
dev.cpu.3.coretemp.resolution: 1
dev.cpu.3.coretemp.tjmax: 105.0C
dev.cpu.3.coretemp.throttle_log: 0
dev.cpu.3.temperature: 49.0C
hw.acpi.cpu.cx_lowest: C1
machdep.idle_mwait: 1
machdep.idle_available: spin, mwait, hlt, acpi
machdep.idle: acpi

Otherwise the only two other things that slightly helped reducing power usage were:

# avoid power for devices without driver  0.2W
hw.pci.do_power_nodriver=3
# Powermanagement for SATA  0.5W
hint.ahcich.0.pm_level=5
hint.ahcich.1.pm_level=5

stephenw10

Hmm, interesting.
I have played with power tuning on a couple of boxes, both much older than this. A Pentium-M based box responded very well to powerd controlling the P states, 15-20% idle power reduction. However a C2D box much less well, though I was hacking the BIOS to enable speedstep etc which confused things. ;) It appeared as though the lower power C states overwhelmed any gains made by using P states. On that box I had to enable the lower C states in the BIOS and then set the sysctl to allow a lower 'lowest' state. It's a while ago now but I'm pretty sure I set dev.cpu.0.cx_lowest rather than hw.acpi.cpu.cx_lowest.
powerd can control a couple of other things but mostly does only CPU power control.

Steve

TotallyInsane

Thanks stephenw10. I tried everything. Switched to FreeBSD 10.1RC4 and generated the data necessary to file bug report 194920 on bugs.freebsd.org . Maybe they will fix this for FreeBSD 11.

The additional 1.5W power this bug seems to cause on idle are less of a concern to me as the pfsense 2.2 system is down to 9W with the noted settings. A bigger concern is, that this might be the reason for powerd being stuck to 1826 MHz and not getting into turbo with the openssl speed test running on one thread? For now, the speed should be more than fine for my 50MBit VPN. But with 100MBit this might become a problem.

Forgot to talk about temperatures on the jetway NUC: CPU is usualy fine with <50C. It takes some time until the case warms up under heavy load. A bit concern gives me the mSATA ssd wich already has reached a max temp of 63C during the tests and it is not >40C in summer and heavy load for hours. Jetway seems to also have some suspicions for such extremes and did add a fan connector. But I guess a small heatsinks connecting SSD with the case will be totaly fine for me.

stephenw10

My understanding is that the 'turbo' mode is not dependent on the OS, I don't think powerd is the issue here.
Also I imagine that cpu will easily manage 100Mbps of vpn traffic even at the lower frequency.

Steve

TotallyInsane

I couldn't find any info on the Bay Trail turbo mode, but all info I found from Intel seems to indicate that C1 state is considered active when it comes to turbo mode and thus there is no turbo with all cores in C0 or C1. If powerd doesn't display the turbo frequency even if activated by the cpu hardware, then I guess I have to find another way to test that.

stephenw10

The cpu frequency should be shown in the sysctls. I forget exactly which one, I usually just grep for 'freq'.

Steve

TotallyInsane

I made a copy/paste fault while testing FreeBSD 10.1RC4 and unlike pfsense C2 (not C3) states are reached. This at least gave me an idea what might be wrong with pfsense 2.2 beta.

My current guess is, that saving

performance_cx_lowest="C8"
economy_cx_lowest="C8"

in /etc/rc.conf.local doesn't work on pfsense 2.2 beta unlike FreeBSD. The setting has no effect on sysctl output after reboot like on FreeBSD.

I couldn't find any actual data on the net, but where do I have to save this if not /etc/rc.conf.local on pfsense 2.2? Maybe I should create a new thread on this as this doesn't seem to be jetway NUC related.

I also run some benchmarks and the turbo mode seems to be working on pfsense/jetway NUC even if all cores are in C1. So all is well with the jetway NUC. Only the idle power usage is slightly higher compare to pfsense 2.1.5/ipfire…

stephenw10

Custom sysctl settings can be added via the webgui in System: Advanced: System Tunables: that way they are saved in the config file and carried across an upgrade.
However these are the equivalent of using /etc/sysctl.conf in FreeBSD. Hmm, not sure about rc.conf settings. :-\ You're correct that these files are not used in pfSense as they are in FreeBSD, they are generated by the pfSense scripts using info in the config file.

Steve

BugBash

Hi there,

Im new to the forum and PFSense, I was searching for the forum for the
Jetway NU93-2930 motherboard
I didnt get any hits but searching for the CPU I found this thread. Rather than start a new thread thats basically the same
I tacked on (Hope you dont mind)

The board seems ideal, tiny, dual intel gigabit ,variable power requirements and CHEAP!

I have just yesterday upgraded to 74/19 fibre and Im thinking firewall/virus protection and VPN

Does the CPU in this little board of tricks have enough left for future tinkering?
I use Bittorrent alot and intend to host a game server next year.

EDIT: Im in the UK

rexki

Its max ram is 4GB - maybe not an issue but packet sniffing combined with packet filtering may take this to the top of the memory stack.

"Shared mPCI-e slot" could be interesting for additional Ethernet

power savings are huge with this "NUC" - this is put into a full box solution with JBC311U93E-2930-B priced at $220 barebones (CPU, power, wifi /BT included.) Will have to boot off something other than a 2.5" sata drive. No room in box or SATA header for 2.5" media.

TotallyInsane

Rexki, the Jetway is listed with 4GB max, but for instance on http://www.mini-itx.com/store/~JBC311W you do get 8GB DDR3 lp modules for it. Seeing similar offers for other N29x0 systems with single memory slots, I assume the CPU is capable of addressing 8GB with certain 8GB modules.