[Tfug] "Downgrading" ("underclocking?") processors

[Bexley Hall]

Hi John,

[attrs elided]

>> I expect the design to be sold as a "fully assembled" product.
>> Too many folks have *no* expertise and/or are unconcerned with
>> the potential savings or "fabrication experience". These are
>> the folks who run OSX/Windows/<any_"stock"_FOSS_OS>.
>>
>> OTOH, I expect there will be folks who *have* experience and
>> would enjoy tinkering and/or "saving a few bucks" by rolling
>> their own. Putting a generic PC in a closet will eventually
>> cause those folks to realize it's too noisey, it burns too much
>> power, it crashes from thermal overload, etc.
>>
>> If the only option is "buy the prebuilt product that has solved
>> all these problems for you" (at some cost: in terms of dollars,
>> form factor, flexibility/hackability, etc.) then I imagine they
>> would be disappointed.
>
> The kind of people who are comfortable installing and configuring their
> own FOSS systems are likely the same kind of people how are comfortable
> building their own PCs.

Comfortable != Competent.  :>

> They also are more likely to understand that you
> don't put a 220W AMD FX-9590 based machine in a closet under a blanket.

Sh*t happens.  Folks don't *intend* to put a machine under a blanket...
until the jacket hanging above the device slips off its hanger and
lands on the unit, etc.

They're also not likely to put all this kit in the middle of a room
with lots of airflow and access.  Think "eyesore".  E.g., I'm currently
a bit over 15U -- without counting backup power, etc.

> My impression from things like the 4chan's technology board[1] is that
> building your own system with Windows is the first level of 'hacker'
> Installing a Mint/Ubuntu is second, and from there you start looking are
> more exotic FOSS options (and at this point you are probably looking at
> < 1% of the population).

I see a lot of folks who are relatively clueless just looking for
someone to TELL them "what to do" -- and then, "tickled" with how
"clever" they are at having "followed directions" (hopefully).

Witness the number of folks who think replacing caps "fixes" a
bad motherboard/monitor/etc. -- without thinking that perhaps
*other* caps on the same board are probably also "suspect"
(even though they don't "look bad").  *Nor* examining the
related circuitry to see if operation of the device with
those failed components in place hasn't stressed some other
components (e.g., CPU!) due to the excessive ripple voltage
that is a direct consequence of a failed cap.

Sort of like the guy who pats himself on the back for having
successfully replaced a FUSE -- without considering what it
was that caused the fuse to blow in the first place!

Or, the guy who witnesses some "anomalous behavior" in a piece
of software, can't come up with a reasonable explanation for it
and DISMISSES IT as a "fluke" (because he isn't competent to
chase down the cause of something that *he* witnessed!).

> If pre-built/configured systems are available,
> that will satisfy the vast majority of the market.

I don't think so.  We're not talking about a few hundred bucks.
E.g., look at what "smart thermostats" sell for.  And it's *just*
a thermostat!  Now, walk through your house looking at all the
places that should/could benefit from automation.  And, think of what
a vendor would (have to!) charge to target products towards each of
them.

How does an HVAC system know whether it makes sense to use the
swamp cooler today/now or if it should opt for the ACbrrr?  Are
the windows open, already?  Or, closed?  Or, some of each?

What would it cost to monitor the perimeter of your home (burglar
alarm)?  All the windows, doors, etc.?  What would the vendor have
to include in the product to keep the installation costs from
forcing you away from his product (e.g., wireless so you don't have
to run wires; but, how do you get *power* to all those devices, then?)

Surveillance cameras?

Or, distribute music/audio program material throughout the home.

Ditto video.

How does he figure out where you are physically located in the building?
Deduce what you are *likely* doing?  Understand your "requests" in
this context?

Control your garage door opener?  Sense if the door is open already...
or closed?

I figure I'll have about $10K into this place by the time I'm done.
But, I probably am doing more than most folks would (especially
for an "after market" application).  OTOH, I'm not wasting money
on "frills" like "drape/curtain openers", "window actuators", etc.

And, I figure that's probably a discounted cost.  A vendor would
charge ~3 * (DM+DL).  So, while my material costs are considerably
higher (due to low volume purchase), they aren't 3 times higher!
And, my labor costs are zero (as would any other tinkerer's).

I.e., there is a *huge* incentive to "roll your own" -- especially
if a vendor doesn't yet offer the kit that you want/need (or, if
it doesn't behave the way you want -- does your $200 thermostat
know how to decide when to use the cooler vs. ACbrrr vs. heat?)

I imagine OTS product will only work for folks with deep pockets.
Or, folks who are only looking for some small subset of an
automated environment (e.g., set thermostat; turn lights on and
off)

> The rest of the
> market thinks that they are smarter then you anyway, and all you can do
> is give guidance, so that when they get screwed, they can say 'well
> maybe I should have followed the guidelines'. On a related note if I
> ever try your system I'll be running everything off of an SSD ;)

SSD won't work (unless there are some big changes in technology
or you grossly overprovision).  E.g., the hardware I'm designing
for myself uses several different memory technologies to exploit
the capabilities of each while avoiding their respective liabilities.
The software goes to great lengths to ensure the "right things"
go in each type of memory.

>> Would you run Lin*x/*BSD if it *only* ran on a particular piece
>> of hardware? Regardless of how flawlessly it did so? What is
>> it worth to you to be able to "tweek" your machine to fit *your*
>> needs and not the needs imagined by the vendor?
>
> It depends on the application. I can do almost no tweaking with my
> phone. I had rooted it, but a firmware upgrade locked me out again. Root
> wasn't that important so I never bothered to find a new exploit. So for
> my phone not being able to tweak isn't really an issue for me. (I think
> that the vast majority of smart phone users are in the same boat). With
> more and more laptops having soldered in memory, and no upgrade path,
> they are in the same boat as well. What you buy today is what you get.
> If the manufactured doesn't make something with the specs you need you
> are SOL. That might scare some people away, but the vast majority are
> happy with what they get.

But the flexibility that your phone/laptop is afforded is "reasonably"
accommodated by the range of applications (and hardware) you can
purchase.

OTOH, how you live your *life* -- and, most of that happens inside
your *home* -- tends to be very person-dependent.

For example, "I" monitor water flow rate entering the house.  If I
see a ~2 gallon "slug" of water run through the system, I deduce that
someone just flushed a toilet (or, possibly, washed their hands/teeth
and coincidentally used the same amount of water that a toilet
flush consumes).  If I see 3 gallons, it was *not* a toilet flush.
Nor was it water drawn for a bath or a shower (maybe washing dishes?).
If "I" coincidentally just turned on the water to the washing machine,
then it is likely the "wash water".  Ditto for the dishwasher.

If I see 10 gallons over the course of an hour AND "I" happened
to have turned on an irrigation valve that happens to feed a
set of emitters that pass 10/60 gallons per minute, then it's
almost definitely the water going out into the yard.  OTOH, if
the irrigation controller isn't calling for water, currently,
then it might be someone running a shower.

Or, it could be a burst water line feeding one of the toilets,
sinks, washing machine, etc.

In *your* house, if these things happen at 3AM, it's probably
more likely a "problem".  Here, however, I tend to be working
at those hours so its not uncommon for me to be taking a shower,
washing dishes, clothes, etc.  I.e., "normal -- no cause for
alarm".

Likewise, if the "garage door opener remote" calls for the door
to be opened, it's probably me wanting to exit the garage and
*not* someone who has the same "opener code" trying to break into
the house!

[Neighbor across the street had their opener programmed to
exactly the same "code" as ours, at one point.  So, we would
each find our doors open at unexpected times -- until we
discovered the screwup]

My point is, what's normal, expected and *desirable* for your
home is probably not for mine -- or your neighbor, etc.  Each
of you wants to be able to tweek automation to fit *your* needs
and not some cookie-cutter scheme established by a manufacturer.

[We had a thermostat that supported 4 set points per day -- treating
all WORKdays the same -- and another 4 for weekends.  Royal PITA
to make changes given that neither of us works outside the home
and wants the same "schedule" established -- one temperature
during the waking hours, another while asleep -- for all 7 days!
We have to deal with *8* settings instead of the *2* that should
be required!]

> Note that I'm not asserting that a lack of tweak-ability is a good or
> acceptable thing; I just saying that the average consumer is OK with it,
> and as a result vendors are moving in that direction.

Yes.  Too many choices intimidates users.  Engineers/programmers
tend to think a "great" design lets the user make all sorts of
"customizations".

This is true.  But, only if the design establishes excellent
"defaults" to begin with (so the user doesn't *have* to make
lots of choices).

Designs that arbitrarily limit choices (like our thermostat)
just annoy -- especially when their arbitrariness is apparent
(or suspected).

>> On the flip side, what value is a design if it can *only* be
>> used by folks who can "build a system from scratch"? Should I
>> just release sources and whatever sort of build environment
>> suits *my* needs? And, expect folks to "figure it out" if they
>> want to play?
>
>  From above: "I expect the design to be sold as a "fully assembled"
> product."
> You have two options, buy the fully assembled product, or build from
> scratch. You average tinkerer is probably going to start with a VM, or
> an old machine that they have laying around before the go out and invest
> in a specific machine for the task.

Exactly.

And *neither* of those approaches will work!  :<  There's a point where
you're "being too cheap" and will only end up wasting your time and
the time of the "support community" as they re-educate you as to why
what you're doing won't work ("read the FAQ" -- despite how much
you *think* it should work!)

For example, I *precisely* synchronize the "clocks" (in the sense
of "time") on all of the nodes in the system.  To do this, the
software (in the network stack/NIC device driver) has to keep track
of when individual packets/frames are passed to (and retrieved
from) the actual NIC hardware.

Then, the software needs to know how that particular NIC hardware
"behaves" -- i.e., the relationship between when the packet is
presented to (retrieved from) the NIC and when the packet actually
hits the wire (came off the wire).  This has to happen *deep* inside
the NIC device driver to eliminate sources of timing jitter
(ideally, the *instant* before the packet is made available to
the NIC)

Knowing the temporal relationship of the packet on the wire vs.
as it is exposed to the "software" inside the host, I next need
to know how the fabric through which it passes behaves, temporally.
I.e., how many switches on the path from this node to node X
(vs. node Y or Z), whether each of those switches cut-through
or store and forward, what other traffic is competing for buffer
space in those switches, etc.

With all of these data, I can accurately account for the time that
it takes to get from "instruction A" (in the XMIT driver) on node 1
to "instruction B" (in the RECV driver) on node 2.  And, from there,
relate to the actual "clocks" on nodes 1 and 2.

A VM tends to be nondeterministic -- what else is running on the
host machine that is competing for instruction cycles?  If the
network driver is virtualized, then all bets are off (the time
spent getting through the virtualization layer *and* the actual
driver just swamps the timing data you're looking for).

Additionally, it would require "me" to qualify each possible NIC
(and driver!) in order to fold those data back into the control
algorithms running under that VM.

[E.g., I built the prototype of this synchronization circuit with
some "old machines".  But, spent a fair bit of time with a 'scope
and logic analyzer so I could accurately *measure* these delays
and convey them to the software.]

*My* (production) hardware uses NIC's that support direct
instrumentation of these timestamps.  So, there is no need to
measure/characterize individual NIC's.  Most NIC's used in
PC's don't have this capability -- especially "old computers".

> They know and understand what they
> have and what its limitations are (e.g. the fan is noisy). Let them
> tinker. Its what they want to do.

I don't think that's the case.  I think you (I) end up spending a
*lot* of time "educating" those users.  And, there's a really high
probability that they won't be able to "step up" at the end of
the day.

DIY projects have appeal when folks have a reasonably high probability
of achieving success without lots of effort/perseverance (how many
folks hack kernels? chase down bugs in apps? even *report* bugs in
a manner that can be reproduced??).

Look at how many folks return devices because they don't have the
patience to read the instructions.  The "flashing 12:00" on the VCR
syndrome.  :<

How many folks would build Linux/BSD systems if they had to
"make world" before they got started?

<frown>  The more I think about this, the more I believe the "solution"
is to "close" the server side and just let folks tinker with the
"motes"/clients.  The consequences of "suboptimal implementations"
are far less significant, there (and, largely confined to *that*
portion of the "field").  As those sources are targeted to specific
chips (SoC's), it also has the (desirable?) effect of tying their
hands in terms of implementation choices -- unless they want to
rewrite big pieces of code!

> [1] Remember that all of your problems would go away if you just
> installed Gentoo ;)

Yeah, I'd just have to remove the user-land and replace the kernel!
Piece-of-cake!  :>