I see that I was wrong in saying that Timothy didn't try to answer John's question. I see now that he did, and suggested that you could use unused CPU cycles (that didn't contribute to MSU-metered costs). This would assume that the delta electricity costs of a running vs waiting z13 CPU were justified based on performance of the mining code.
Kirk Wolf Dovetailed Technologies http://dovetail.com On Fri, Jan 27, 2017 at 10:53 AM, Kirk Wolf <k...@dovetail.com> wrote: > Are there z13 benchmarks for Bitcoin mining? How many profitable Bitcoin > miners are running z13s? (I would guess that the answers are "no", and > "none") > > Running Hyperledger Blockchain node/server and Bitcoin mining are > *completely* different things. Hyperledger Blockchain does not have a > function that mines blocks (i.e. completes a block by finding a nonce to > complete a SHA-256 hash). > > Timothy, I really appreciate your participation on this list, but I think > that your suggestion that "z/OS might be the *ideal* part-time Bitcoin > mining platform" is utter nonsense. But I'm sure that IBM would love it if > customers tried this (without zIIP enabled code) :-) > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > PS> Bitcoin mining (SHA-256 hashing) is not floating point. Its about 1000 > simple operations like and/or/xor/not, shift, rotate, addition mod2. You > also have to generate good random numbers. > See: https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU > Bitcoin miners use GPUs like a flock of parallel micro-codable vector > processors. It would be interesting to code vector based SHA-256 (the > key algorithm for Bitcoin mining) using the z13 Vector integer instructions > and publish the results. > > PS> Timothy, now is your chance to answer John McKown's question on this > list two years ago: > > > > > *(Subject: z13 unanswered questions (1/15/15))How fast could a fully > enabled machine mint bitcoins or other cryptocurrency? How much power would > such a machine use while doing so? "Inquiring minds want to know!" "* > > > On Fri, Jan 27, 2017 at 12:27 AM, Timothy Sipples <sipp...@sg.ibm.com> > wrote: > >> 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 >> > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
