What I do not like about the Pi is the network port is on the USB bus and thus limited to USB speeds.
<div>-------- Original message --------</div><div>From: Maxwell Cole <mcole.mailinglists@gmail.com> </div><div>Date:02/18/2015 4:30 PM (GMT-05:00) </div><div>To: "nanog@nanog.org >> 'NANOG list'" <nanog@nanog.org> </div><div>Subject: Re: OT - Small DNS "appliances" for remote offices. </div><div>
</div>
For any site where you would use a Pi as the DNS cache, it won't be an issue. DNS isn't that heavy at those query rates.
Yeah, it would be awesome if they'd been able to get a SoC that included ethernet.
-Pete
I have used the BeagleBone to run a few simple servers. I don't know if the ethernet port on the Bone is on the USB bus. It is slightly more expensive than a PI, but they have worked well for me.
Geoff
You also have to watch out for issues with the Pi corrupting SD cards.
The BeagleBone's ethernet is directly connected to the SoC, so you would
get a higher throughput ceiling than the rpi.
The BeagleBone Black uses flash memory to hold the system image which allows it to boot quickly. I'm running Ubuntu Trusty 14.04 and it seems stable.
Geoff
"Robert Webb" <rwebb@ropeguru.com> writes:
What I do not like about the Pi is the network port is on the USB
bus and thus limited to USB speeds.
Pretty much all of the ARM boards have their ethernet ports on HSIC
channels (480mbit/sec, no-transceiver-phy USB for on-board use -
maximum length is 10cm).
The Pi-B shares the single HSIC channel with the USB hub for the
keyboard and mice. It seems from looking at block diagrams and lsusb
output that the ODROID U3 has an SoC with multiple HSIC channels and
dedicate one to to the ethernet (though the "bus" vs "port"
distinction is suspect).
pi@raspi-b ~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
>__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M
>__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M
pi@raspi-b ~ $
root@odroid:~# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M
>__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
>__ Port 3: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
root@odroid:~#
But 480 is greater than 100, and none of the Pis have ethernet faster
than 10/100. The long pole in the tent is definitely not the USB, and
single stream tcp throughput is fine.
pi@raspi-b ~ $ curl -o /dev/null http://172.30.250.101/bigfile
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 989M 100 989M 0 0 11.1M 0 0:01:28 0:01:28 --:--:-- 11.1M
pi@raspi-b ~ $
-r
Agreed the long pole at a small site for DNS won't be the USB bus. Might I recommend the following:
odroid-c1 + eMMC module + RTC battery + case + power adapter. Should run you about $75 *AND*
wouldn't be bad for running NTP as well.
The gig-e port on the C1 has been observed to push 405Mbps TX and 940Mbps+ RX via iperf.
Bryan Seitz <seitz@bsd-unix.net> writes:
odroid-c1 + eMMC module + RTC battery + case + power adapter.
Should run you about $75 *AND* wouldn't be bad for running NTP as
well.
I haven't looked into the details of the clock, so "wouldn't be bad"
is probably true, "notably good", well, that would be a task for
someone with experience doing clock benchmarking and who can describe
MAVAR without looking it up.
The gig-e port on the C1 has been observed to push 405Mbps TX and
940Mbps+ RX via iperf.
The 405 Mbps for TX. I've seen around 30 Mbyte/sec on single stream
TCP RX. Got 99.5 Mbyte/sec from a Mac Mini in the same subnet so
that's not a limit of the host on the other end of the benchmark.
I call shenanigans on the 940 Mbps iperf number though. The HSIC bus
is only 480 Mbit/sec. Two pints of beer in a one pint glass would be
some trick.
-r
Beaglebone has gigabit mac, but due some errata it is not used in gigabit mode, it is 100M (which is maybe enough for small office). But it is "hardware" mac.
Another hardware MAC on inexpensive board it is Odroid-C1.
But stability of all this boards in heavy networking use is under question, i didn't tested them yet intensively for same purpose.
Denys Fedoryshchenko <denys@visp.net.lb> writes:
Beaglebone has gigabit mac, but due some errata it is not used in
gigabit mode, it is 100M (which is maybe enough for small office). But
it is "hardware" mac.
The Beaglebone Black rev C BOM calls out the ethernet phy chip as
LAN8710A-EZC-TR which is 10/100 so there's your constraint. The MAC
is built into the SoC and according to the datasheet the AM3358B is
10/100/1000.
Another hardware MAC on inexpensive board it is Odroid-C1.
Difficulty: hardware MAC tells you nothing about how it's connected,
either on the board or internally in the SoC. Ethernet on Multibus
and Ethernet on PCIe (neither likely on an embedded ARM 
are both
"hardware MAC" yet the bus-constrained bandwidths will differ by
several orders of magnitude.
-r
Well, i guess for DNS it wont matter much(400Mbit or full capacity). But stability of driverand archievable pps rate on it,
due poor code - can be a question. And mostly this products are "Network enabled", but networking are very "lightly"
used, not as it is used on appliances, 24/7 traffic, sometimes malicious.
About Beaglebone, probably reason is this errata:
"While the AM335x GP EVM has a Gb Ethernet PHY, AR8031A, on the base board,
the PCB was designed to use internal clock delay mode of the RGMII interface and
the AM335x does not support the internal clock delay mode. Therefore, if operating
the Ethernet in Gb mode, there may be problems with the performance/function due
to this. The AR8031A PHY supports internal delay mode. This can be enabled by
software to guarantee Gb operation. However, this cannot be done to enable
internal delay mode for Ethernet booting of course. "
Or maybe they just put 100Mbit PHY to make BOM cost less.
As far as i know, Raspberry PI ethernet over USB might be fine for DNS too, but before it had issues with
large data transfers (ethernet driver hangs). No idea about now.
AIUI the problem with the RPi isn't so much that the Ethernet NIC sits on a USB interface, it's that the RPi USB interface is very basic and requires a great deal of host interaction to work. It presents a very high interrupt load, and that can lead to problems.
Remember that the RPi, fantastic as it is, was developed as a low cost educational aid. It can be used with great success in other fields, but you should consider its limitations.
I'm using several to connect sensors, actuators, and such to a private network, which it's great for - but I'd think at least twice before deploying one as a public-serving host in user-experience-critical role in a remote location.
d.
People, processor of this hardware will be killed before the 100M ethernet
be the problem.
I have a Pi that's found a purpose in life as a remote smokeping sensor and
related network monitoring, a task it does quite nicely.
Note that they just released the Pi 2, which goes from the original single-core
ARM V6 to a quad-core ARM V7, and increases memory from 256M to1G. All at the
same price point. That may change the calculus. I admit not having gotten one
in hand to play with yet.
http://dn.odroid.com/homebackup/201411241452444193.jpg
I don't think it lives on the 480Mbit/sec limited bus here.
[ 3] local 192.168.1.4 port 53391 connected with 192.168.1.21 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 488 MBytes 409 Mbits/sec
[ 4] local 192.168.1.4 port 5001 connected with 192.168.1.21 port 34581
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec
Weird thing - it still has Ethernet over ugly USB 2.0
That kills any interest to run it for any serious networking applications.
If your time is worth anything, you can't beat the Mac Mini, especially for a branch office mission-critical application like DNS.
I just picked up a Mini from BestBuy for $480. I plugged it in, applied the latest updates, purchased the MacOSX Server component from the Apples Store ($19), and then via the Server control panel enabled DNS with forwarding.
Total time from unboxing to working DNS: 20 minutes.
The Server component smartly ships with all services disabled, in contrast to a lot of Linux distros, so it's pretty secure out of the box. You can harden it a bit more with the built-in PF firewall. The machine is also IPv6 ready out of the box, so my new DNS server automatically services both IPv4 and IPv6 clients.
You get Apple's warranty and full support. Any Apple store can do testing and repair.
And with a dual-core 1.4GHz I5 and 4GB memory, it's going to handle loads of DNS requests.
Of course, if your time is worth little, spend a lot of time tweaking slow, unsupported, incomplete solutions.
-mel
older apple tv will work as well 
Colin
If you have a lot of locations, as I believe Ray is looking for, all of
this is a manual process you need to do for each instance. That is slow
and inefficient. If you're doing more than a few, you probably want
something you can PXE boot for provisioning and manage with your
preferred DevOps tools. It also sounds like he wants to run anycast for
this service, so probably needs a BGP speaker and other site-specific
configuration that I assume is not covered by the cookie-cutter OSX
tools. Of course you could still do it this way with a Mac Mini running
some other OS, but why would you want to when there are plenty of other
mini-PC options that are more appropriate?
Also: With Apple dropping their Pro products and leaving customers in
the lurch, and no longer having any actual server hardware, I would have
very little confidence in their server software product's quality or
likely longevity. And of course they're mum on their plans, so it's
impossible to plan around if they decide to exit the market.
Keenan