Hi Everyone,
Livepeer transcoder (0xCdFC898128DBC380A60895c6E8C0975Dc07D07E0) and GPU miner interested in dual-mining and transcoding here. I noticed that there has been some preliminary work done with testing Livepeer transcoding + ETH mining. This is great and hope to see much more progress in this direction.
As a GPU miner with a set of different GPU models mining different currencies, I thought I would kick off a thread with questions that I had, as I suspect a lot of GPU miners have the same questions. Other GPU miners: Please feel free to add our questions here if not already covered (esp the AMD miners, as we are all NVIDIA here).
Here’s my initial set of questions:
How would a GPU miner with, say a 12 GPU mining rig, join the LivePeer network? Do they run their own orchestrator or are they able to contribute their compute power to an orchestrator?
In the latter case would the payments be divided between the Orchestrator, the GPU miner and the LPT holders delegating to the orchestrator?
Are the orchestrators built to transcode utilizing the power of all the GPUs on the system? (I’ve seen upto 19 GPUs on a motherboard for example)
We run 1060s, 1070s and 1080tis. While the 1060s and 1070s typically run Ethminer, the 1080tis run either a GRIN or a Raven miner as those are the most profitable (check whattomine.com to get a sense of what the networks of GPUs are best off running right now). Has LivePeer been tested with the major mining software out there: Ethminer, Claymore, bminer, ravenminer and so on?
To reiterate the previous point, the different mining algorithms are heavy on one part of the GPU, either memory or the processor. Has LPT transcoding been tested under these different conditions?
A lot of the mining algorithms are very heavy on the GPU even with fans running at 80+% they could heat up to 75+ degrees. It’s hard to imagine a GPU doing transcoding workwhile the mining is taking such a toll on the GPUs. Has this been tested and proven to be stable?
Most miners run bare bones configurations. For example we run an octominer with 4GB of memory and an intel i3-7100 celeron processor. The operating system runs on a USB stick, so no HDD. Not exactly the beefiest of configurations outside the GPUs. What are the requirements in terms of upgrades needed for an Octominer such as the ones we have, to be able to run the Transcoding software?
Why is it necessary for Transcoding and Mining to occur simultaneously (I guess it’s ideal to earn 2 incomes as a miner)? An interim step could be to shut down mining on the GPUs when a transcoding job becomes available and turn the mining back on once transcoding is done (assumption being that Transcoding is always more profitable than mining. In the future it be necessary for the miner to do a quick calculation before switching over). Has this been considered?
Can the transcoder active set be opened up from the current 25 to enable more GPU miners to join the network? We’d love to retool our GPU mining rigs to help answer some of the questions above, but it’s hard to justify taking a profitable mining rig and dedicating it to helping with transcoder testing and all the attendant downtime and maintenance that will require. Being an active participant in the network would help.
How would a GPU miner with, say a 12 GPU mining rig, join the LivePeer network? Do they run their own orchestrator or are they able to contribute their compute power to an orchestrator?
he would become a Orchestrator with our Streamflow release. His choices are to run both the Transcoder and the Orchestrator on the rig, or have another server for the Orchestrator to add more than one rig to his workforce.
In the latter case would the payments be divided between the Orchestrator, the GPU miner and the LPT holders delegating to the orchestrator?
in a public pool in which anyone can work for an Orchestrator yes but this is not yet available in streamflow. orchestrators in streamflow will be private pools at first with the outlook on becoming public pools later.
Are the orchestrators built to transcode utilizing the power of all the GPUs on the system? (I’ve seen upto 19 GPUs on a motherboard for example)
Yes the livepeer software will allow utilization for encoding on all GPUs at the same time.
We run 1060s, 1070s and 1080tis. While the 1060s and 1070s typically run Ethminer, the 1080tis run either a GRIN or a Raven miner as those are the most profitable (check whattomine.com to get a sense of what the networks of GPUs are best off running right now). Has LivePeer been tested with the major mining software out there: Ethminer, Claymore, bminer, ravenminer and so on?
we currently test with ethereum mining to get a solid benchmark. Other options have been considered but are not our primary target for optimization
To reiterate the previous point, the different mining algorithms are heavy on one part of the GPU, either memory or the processor. Has LPT transcoding been tested under these different conditions?
Only for ether, again. DAG size matters since we need a bit memory in the card but more in the MBs than GBs since we only deal with very short amount of videos.
A lot of the mining algorithms are very heavy on the GPU even with fans running at 80+% they could heat up to 75+ degrees. It’s hard to imagine a GPU doing transcoding workwhile the mining is taking such a toll on the GPUs. Has this been tested and proven to be stable?
The performance hit on the hashing is about 2% per stream we encode. Total power draw and produced heat fall the more streams you encode and are quite linear with the measured performance hit.
Most miners run bare bones configurations. For example we run an octominer with 4GB of memory and an intel i3-7100 celeron processor. The operating system runs on a USB stick, so no HDD. Not exactly the beefiest of configurations outside the GPUs. What are the requirements in terms of upgrades needed for an Octominer such as the ones we have, to be able to run the Transcoding software?
There are reasons to use a higher grade CPU and a bit more of RAM. The riser adapter so far has not shown any bottlenecks even if you encode multiple streams per card. This is cause the content moves compressed in the card and compressed out but never send uncompressed video back to the CPU. so 100 mbits per riser would be enough and there is 300+ avaiable.
Why is it necessary for Transcoding and Mining to occur simultaneously (I guess it’s ideal to earn 2 incomes as a miner)? An interim step could be to shut down mining on the GPUs when a transcoding job becomes available and turn the mining back on once transcoding is done (assumption being that Transcoding is always more profitable than mining. In the future it be necessary for the miner to do a quick calculation before switching over). Has this been considered?
it is not necessary but possible and will as you suspected lead to the best profits.
Can the transcoder active set be opened up from the current 25 to enable more GPU miners to join the network? We’d love to retool our GPU mining rigs to help answer some of the questions above, but it’s hard to justify taking a profitable mining rig and dedicating it to helping with transcoder testing and all the attendant downtime and maintenance that will require. Being an active participant in the network would help.
Thank you for the answers Philipp! Much appreciated and super stoked on the streamflow release.
Is there a timeline for when it will be available on testnet and then mainnet?
Can one run an orchestrator and transcoder on hardware without GPUs like we do now or will GPUs become a requirement with streamflow.
Any idea of expected workload we can expect to see? Is it best to size our GPU clusters participating in Streamflow post-release or is there some capacity planning we can do now?
Would the opening up beyond 25 transcoders occur before or with the Streamflow release?
Hey Gautam. We’re working on deploying the infrastructure for the testnet later this week.
Yes, you can continue running on regular CPUs rather than GPUs. Whether that is cost competitive for you in the long term remains to be seen, but during the testnet and initial mainnet it is fine.
No estimation on workload yet. While the team is certainly working to productize to meet the needs of scaled users, until there’s a functioning public network it is hard to quantify an exact demand in terms of # of live streams just standing by to use it. It will likely start small, but if there are no technical blockers in terms of reliability, and the price that orchestrators are charging on the network is right, then the gates are opened for scaled usage.
It is unlikely that the mainnet will expand beyond 25 before Streamflow, due to shifting the focus to testing, validating, and launching Streamflow, but this can continue to be discussed.