Jan Cannaerts wrote:
>z/Series machines are not geared towards floating point operations the way
>commodity GPUs, FPGAs, or purposely built BitCoin miners are.
True, but I don't think Rob Schramm is using a zSeries machine (z990, z890,
z900, or z800). I assume he's using one of the IBM z Systems. The
processors are different, better. I would not claim that IBM z13 processors
are *particularly* well suited to Bitcoin mining, but they are much better
suited than their zSeries predecessors were. They are not GPUs, but they
are more GPU-like.
They do very well indeed with Hyperledger Blockchain, by the way.
>So you surely would spend more money on electricity powering the machine
>than you'd gain through mining BitCoins, as is already the case for GPUs.
I don't think that assumption is correct, assuming the IBM z13, z13s, or
LinuxONE machine is otherwise powered up and performing some other
"reasonable" amount of work. Aside from static power save mode, they just
run, even when they're not doing much processing. They aren't like the
processors in your laptop, tablet computer, or smartphone that spend most
of their time in various lower power states.
Solely in terms of electricity consumption, an IBM z System running z/OS,
productively employed for some other work, might be the *ideal* part-time
Bitcoin mining platform.
>Moreover, what type of licensing do you have where you can use unused
cycles?
>We have MLC licensing, and as a result we get to use these unused cycles
when
>we need more processing power than we have defined.
Sure, but that's not every machine or even many of them. Let's suppose, for
example, that you have a 500 MSU Defined Capacity, set across all your
LPARs (group limit). So your licensing cannot go above 500 MSUs, and (let's
assume) you hit 500 MSUs every month. So 500 is both your minimum and your
maximum. Let's further suppose that you can predict, with high confidence,
that December 25 will be a low utilization day for at least 14 specific
hours. What happens if you slot in some Bitcoin mining into the first 10
hours of that 14 hour period, in the lowest WLM service class? Could that
Bitcoin mining workload detract from the "whitespace" above your 500 MSU
Defined Capacity? No, it cannot. It's a four hour rolling average, not a
fourteen hour rolling average.
Yes, maybe you have to avoid letting that discretionary workload bleed into
the final four hours before {markets open, branch offices open, the sun
rises, end of month processing starts, whatever}. That's quite possible to
do, though. All you need is a predictable "quiet" period at least somewhat
longer than four hours, that's all. Then you just tell your scheduler to
start a Bitcoin job (in the lowest service class) at the beginning of the
quiet period and stop it four hours before the end of the quiet period.
Loop, repeat. If that's 12 six hour intervals per year, great.
Lots of organizations have predictable "quiet" periods that are longer than
four hours. Sometimes they are three day weekend long periods, or longer.
If you want to be extra extra extra cautious, add in a 30 minute buffer. So
you tell your scheduler to stop the Bitcoin job four and one half hours
before the next "surge."
In short, no, Rob's idea is not crazy. Bitcoin mining probably is crazy, as
mentioned, but an unused mainframe processor cycle can be a *very* free one
to use. If you've got some discretionary workload that could be generating
some money, and it's free to run, why not slot it in? For that matter, even
if it's not free to run (and it's never free to run elsewhere that I can
think of), if running the workload generates another $2 million for the
company but it costs $680 to run, RUN IT! There's nothing toxi-magical
about 500 MSUs, or whatever your current limit is. Yes, I know, some crazy
people behave that way, but that "stick to the arbitrary MSU limit come
hell or high water!" behavior is what's crazy, not Rob's idea.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
