Raspberry Pi miner?



  • Would I be able to hook up a bunch of external HDD to my raspberry pi and have it mine 24/7? Assuming that all the drives have a wall plugin.

    Also how much TB do you need to cover the cost of electricity?
    How much TB would you need to be "profitable"


  • admin

    @LeG3NdArYPhiL I know there is a Pi miner - how good it would be with very large TB plots, I'm not sure.



  • @haitch could I just use blago's miner?


  • admin

    @LeG3NdArYPhiL No, not on a Pi. It's a special miner recompiled especially for pi - I'll see if I can find a link, but if anyone happens to know it - jump in.



  • @haitch said in Raspberry Pi miner?:

    @LeG3NdArYPhiL No, not on a Pi. It's a special miner recompiled especially for pi - I'll see if I can find a link, but if anyone happens to know it - jump in.

    You mean this ARM tools? https://github.com/kartojal/burst_arm_tools
    I dindnt work for me on my Odroid XU-4 because it has ARMv7, but maybe it works on the Pi.

    Nethertheless i mine succesfull on my odroid XU4. The problem is, that it takes long time to mine the big HDDs (4TB take ~2,25min for mining with the CPU, 8TB ~ 4-5min). I try to setup OpenCL on the XU4 the next days and hope it brings some benefit to use the GPU-miner (jminer). My Plan is to mine the 8TB-HDD with the GPU and the others with the CPU. Sure you lost some earnings because of the duration for the mining-process, but the power consumption of the odroid is ~1/20 of my desktop. So I thing its worthwhile to use the XU4.

    EDIT: i think with an Pi2 or Pi3 the time you need for the mining process is much higher. You only need to compare the CPU-specs between the XU4 and the Raspberry-Pis. Also the RAM is importend and 1GB is not enough for bigger HDDs. With the XU4 iam in the range of the average Block-time of 4mins. So the Pi would only work well for smaller plots (maybe for two 2TB-hdds, but didnt test it)

    Sry for my bad english...



  • @LeG3NdArYPhiL @piezo I been searching too for tool to mine on a Pi3 but lacks for compiled instances of Armv8 (Four a53 cores) to mine! Regarding only the 1GbRAM of memory on the latest pi, you can always enlarge the swap file in order to give 2Gb extra memory to the pi3 directly in the Sdcard, i have tested and it boosts a little and no error till now!



  • @cooolgs1
    So you mine with a Pi2? What's your plotsize and how long did it take the pi to mine these plotsize when I may ask. And which miner do you use?

    About the swap you are right, but the RAM out of the swap is really slow. But since a few days i also use the swap to create my plots directly with 100000 staggersize on my desktop. Works like a charm. :)



  • @piezo said in Raspberry Pi miner?:

    100000

    no...but im trying..i'm new on Raspberry pi3,but i ploted an external drive 1Tb on a desktop just for that, takes 12sec-18sec to read! Well it take almost 18hours to plot completly inicially!



  • @cooolgs1
    12-18sec is good for a pi mining 1TB. Which miner do you use?



  • Is there any miner for a raspberry pi 3 yet? I have external HDD's that are plotted and ready to be ran 24/7



  • @LeG3NdArYPhiL I have 2 pi3 and 4 external drives but for now I'm running 2 and plotting the 2 others on my main pc because I'm unable to find a good pi3 miner this would be great and less electricity consumption



  • I don´t know anything about miners for the Rpi2/Rpi3, but i mine on my Odroid XU4 (which is very similar) with 20TB.
    Here are the miner working for me:

    Poc_miner_pool_v1: https://mega.co.nz/#!7hwHQJLZ!-waC7CwWeMStkdAwjEVbew1fN_YqeZDRWMWfCylaNPo

    • needs a lot of Ram while mining for big/many plots. Even with 2Gb of allocated RAM it crashes for my 20TB of plots. -> Not usable for me
    • -> You can only use this miner for smaller Plots

    burst-pool-miner:

    • also needs a lot of Ram while mining big/many plotfiles. Even with 2Gb of allocated RAM it crashes for my 20TB of plots. -> Not usable for me
    • you can use it only with this V2 Pool -> http://178.62.39.204:8121/
    • -> You can only use this miner for smaller Plots

    burst-mining-system 1.21 https://github.com/mrpsion/burst-mining-system/releases/tag/1.21

    • can be build from source on armv7
    • low RAM-Usage
    • you can use it only with this V2 Pool -> http://178.62.39.204:8121/
    • It could handle big and many plotfiles

    burst-miner https://github.com/uraymeiviar/burst-miner

    • works perfect and fast with low RAM-usage
    • you can use uray-style Pools
    • Unfortunately this miner calculates the wrong deadlines. When the miner submit the shares to the pool, the Pool doesnt accept them because they are several years high. See this Forum Thread -> https://forums.burst-team.us/topic/512/very-high-deadlines/21

    So for now i use the burst-mining-system 1.21 because its the only one that runs without problems. I got my 20TB mined with it in ~3,5min-4min. Sure i lost a lot of shares because of this long time needed for mining. But on the other side the XU4 only needs 10-15Watt while mining. The HDDs need ~25Watt. With my desktop i got my plots mined in ~20sec, but need 200Watt for the desktop and ~25Watt for the HDDs.

    So i got 35-40Watt on my XU4 with maybe 30% lower shares against 225Watt with my desktop and mostly all possible shares.

    Hope that helps...


  • admin

    @piezo thanks for your documentation!

    About urays miner: There is a improved version that has a maxDeadline variable. https://github.com/dpreyl/burst-miner/

    Can you also explain how compiled urays miner for ARM ?



  • @daWallet said in Raspberry Pi miner?:

    Can you also explain how compiled urays miner for ARM ?

    No problem.

    You could make the uray´s miner like this on an Odroid XU4:

    • Download the miner from the link @daWallet mentioned:
      -> https://github.com/dpreyl/burst-miner/

    • extract the archive

    • open a terminal and change in the extracted directory

    • Make the miner by running the make-command in the terminal:
      make

    • The output should look like this:

    odroid@odroid:~/Downloads/burst-miner-master$ make
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/sphlib/sph_shabal.cpp -o bin/sphlib/sph_shabal.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/nxt/nxt_address.cpp -o bin/nxt/nxt_address.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/MinerLogger.cpp -o bin/MinerLogger.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/PlotReader.cpp -o bin/PlotReader.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/MinerShabal.cpp -o bin/MinerShabal.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/MinerProtocol.cpp -o bin/MinerProtocol.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/MinerConfig.cpp -o bin/MinerConfig.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/main.cpp -o bin/main.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/Miner.cpp -o bin/Miner.o
    g++ -O3 -march=native -std=c++11 -Wall -D_REENTRANT -Isrc/rapidjson -Isrc/sphlib -Isrc/nxt -Isrc -c src/MinerUtil.cpp -o bin/MinerUtil.o
    g++ -pthread bin/sphlib/sph_shabal.o bin/nxt/nxt_address.o bin/MinerLogger.o bin/PlotReader.o bin/MinerShabal.o bin/MinerProtocol.o bin/MinerConfig.o bin/main.o bin/Miner.o bin/MinerUtil.o -o bin/burstminer
    odroid@odroid:~/Downloads/burst-miner-master$
    

    Thats it! Now you can change in the ./bin directory and run the miner with the command ./burstminer after editing the mining.conf after your needs.

    Now the bad news:
    The miner doesnt work for some reason.
    He reads the plotfiles and get some deadlines for the nonces. Lets say he found a deadline of 10hours for nonce 102514531. When the miner send this deadline to the pool, the pool answere like this:

    {"errorCode":1007,"errorDescription":"The deadline for your nonce is REALLY BAD: 180390 years, 2 months, 28 days, 3 hours, 25 mins, 50 secs - wrong block? are your plot files corrupted?"}
    

    This is happening all the time, no matter if i set the maxDeadline-Parameter (="submissionMaxDeadline") in the config file or not.
    The miner think the deadline is a few hours, the pool said the deadline is several years.
    I have no idea why this happens, but it did. So you can´t use this miner. If this isue wouldn´t be, this miner would be the best oppertunity for this ARM-Device.



  • @piezo
    I don't know much about raspberry pi and such, but I got that same deadline problem when I changed the default setting from Jminer properties to a much higher value (when mining on a laptop):

    connectionTimeout=6000

    The problem disappeared when I changed it to a lower one.



  • @Propagandalf
    Ok thanks, i will give it a try.
    The Burst-miner has the following default-options in the mining.conf

     {
        "poolUrl" : "pool.burstcoin.eu:80",
        "submissionMaxDelay" : 30,
        "submissionMaxRetry" : 3,
        "submissionMaxDeadline" : 3888000,
        "socketTimeout" : 60,
        "maxBufferSizeMB" : 1024,
        "plots" : 
        [
    	"/plot/folder/disk1/",
    	"/plot/folder/disk2/",
    	"/plot/folder/disk3/" ]
     }
    
    

    So i play around a little bit with the values of socketTimeout and submissionMaxDelay.



  • Changing socketTimeout and submissionMaxDelay didn't help but I found another advice for this Problem under "Issues" on github. Other users of the Burst-miner (https://github.com/uraymeiviar/burst-miner/releases) had the same problem.

    uraymeiviar named this as possible reason for the different pool's deadline and miner's deadline:

    • could be because of difference in plot data format
    • wrong plot filename
    • others also report this if their plot is "optimized" with a tool, i never tested this miner with "optimized" plot since i never optimize my plot

    So my plots are not optimized and have the correct filename (I think the name is correct because with all other miners the plots could be mined perfectly). So the remaining possible reason is:
    "could be because of difference in plot data format" , whatever that means. :)



  • Any updates



  • @Burstde wanted to throw in the creepminer. There is an open issue for the ARM version, but unfortunately I don't own a raspberry pi and I had no time for setting up an emulator.
    Any help appreciated :)



  • @Creepsky Coincidentally I complied and am now running creepminer on an Odroid XU4 (arm7). I just followed the linux compile instructions and it just worked without any problems or modifications. It's been running for about 5 days now with no problems other than the webserver part does not update correctly and shows some strange info.
    CPU and memory usage is very low and I am getting 45 MB/s read avg on a USB3 connected WD Green drive with a 1TB plot file.


Log in to reply
 

Looks like your connection to Burst - Efficient HDD Mining was lost, please wait while we try to reconnect.