[tor-relays] hardware

[grarpamp]

>> A10-6800K (4 x 4.1GHz) would be decent.
>
> It doesn't seem to support ECC

It doesn't. And for those that recognize its importance, that's
been an kind of weakness of AMD for some time. Actually
for both AMD and Intel, it's treated as a price premium
instead of just 8+n extra gates and logic.

> It's very silly to not specify ECC RAM for a server.

It should be in all systems IMO too, even with crypto over
circuits and ZFS on disk. But I not sure the CPU registers,
or the rest of the gates on the die, have any such hardware
protection beyond the lid on top and the fiberglass on the
bottom... haven't looked into it. Or that the makeup of the
Internet/services as a whole use ECC. Tor seems more
weighted to pushing reproducible bits, than to first production
and storage of your own valuable work product.

> like serial console BIOS support and

It's nice if your model involves needing to go to BIOS, such
as being tied to hardware raid there.

> 1U form factor

The port stacks can be cut down / removed if need be.
Another problem is finding low profile ram to go in non-angled
slots. The 'enthusiast' influx to the ram market is annoying yet
the unneeded 'heatsinks' (aka bling) can also be removed.

> the r8139 (iirc)
> chip/driver lacking interrupt coalescing features. Upgrading to an
> Intel e1000e fixed the problem.

Yes, Intel has always had very good nics and supplies docs/code.
I think a85x boards commonly have rt8111.

> The kind of ISPs that offer competitive pricing on bandwidth tend to
> prefer commercially integrated servers, preferably sourced from vendors
> they're familiar with.

That means Intel, Dell, HP and the like.
I'd hesitate to tie bandwidth price to what some techs want.
It's more about how much the ISP buys, if you're small retail remote
hands using or a large self-serve cage, and if it's in a neutral DC.

> That way when your server crashes and needs a
> reboot at 2AM, the tech in the data center doesn't

This is a bit crossed. A true server board should have a
hw watchdog that will autoreboot the OS. Similarly,
with a good server, pulling the plug should be all a
tech needs to do to clear all stuck cases short of
hardware failure. You need a good OS/FS for that.

>> Be careful, Intel likes to promote HT instead of full cores.
>
> That's a really funny claim

Some of their retail marketing I've seen is not so clear, as
in 'Here are 8 virtual things, footnote asterisk fine print - really
backed by 4 real things'. Their server side online is better.

> a single thread can use nearly all of
> the resources on a core. HT is useful

Sure, if your workload is not weighted to single threads/processes
that you can itemize/count as being under the number of real cores.

> AMD Bulldozer, OTOH, claims to have [unit pairing/starvation]

I do often forget that overall when considering some loads :(

> actual work done per watt on CPU intensive workloads.

Intel often beats AMD on power, even if only due to die
process size. Datacenters tend not to line item 1RU's
for actual power used unless you're at 1/4 rack or more
and they have metered managed outlets, the costs of
which are passed on to you as well. As is wasted power.
In the end, for small customers, the DC averages a single
price to you into which you fit whatever box you want. A
home or corporate DC is different because you can mind
your power there to direct/immediate savings.

> AMD unfortunately doesn't seem to have a competitive
> server CPU these days.  It's possible that Piledriver improves the
> situation, but the analysis I saw did not make me optimistic that it
> would be competitive with Ivy Bridge.

I didn't mean to imply that such a system was true
physical server class, but that it could serve the logical
function of a decent server/host for the Tor application.
Particularly considering the cost per node per megabit as
opposed to maximum yield regardless of cost. Real server
hardware tends to start well above $1kUSD. Factoring in the
performance differences and passing on some features,
distributing a lower cost box may be a win there. As a counter
to that idea, It might also be useful to consider initial cost vs.
megabits delivered over time... if you do not expect to be kicked
from DC to DC thus eating multiple shipping costs as add-on
capital.