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
