Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 4. (Read 161727 times)
March 24, 2013, 06:57:20 PM
As soon getwork stop working on all pools, BTCMiner become obsolete. The problem is that the stratum proxy has some problems do occasionally lose the connection to the pool so we will be forced to use CGMiner or BFGMiner if BTCMiner not is updated with statum.
March 24, 2013, 02:01:16 AM
Edited code lines, now You can see, that i`m using sudo.
Problem solved.
I was trying to use 121126, but downloaded 121116 insted of 121126. silly.
Problem solved.
I was trying to use 121126, but downloaded 121116 insted of 121126. silly.
March 23, 2013, 07:37:50 PM
i remember something like the "sudo ...." in front of the actual command to be the solution tothis issue!
March 23, 2013, 04:16:31 PM
need help.
my BTCMiner stoped working.
After a fatal crush (log filled up USB-flash drive - sda1) it was a little hard to run anything.
but now i`m getting this
I have downloaded .jar once aggain - no go:/
I have installed java aggain - no go. sticked with that code.
this is java version
any advice ?
It was working perfectly for last 8 months.
I`m forced to use cgminer, witch i dont like to use with ztex.
my BTCMiner stoped working.
After a fatal crush (log filled up USB-flash drive - sda1) it was a little hard to run anything.
but now i`m getting this
Code:
ummas@ummas-fpga:~$ sudo java -cp ZtexBTCMiner-121126.jar BTCMiner -host http://192.168.1.68:8332 -u XXXX.ztex -p XXXXXX10 -m c
[sudo] password for ummas:
Exception in thread "main" java.lang.NoClassDefFoundError: BTCMiner
Caused by: java.lang.ClassNotFoundException: BTCMiner
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: BTCMiner. Program will exit.
ummas@ummas-fpga:~$
[sudo] password for ummas:
Exception in thread "main" java.lang.NoClassDefFoundError: BTCMiner
Caused by: java.lang.ClassNotFoundException: BTCMiner
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: BTCMiner. Program will exit.
ummas@ummas-fpga:~$
I have downloaded .jar once aggain - no go:/
I have installed java aggain - no go. sticked with that code.
this is java version
Code:
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-1ubuntu0.11.04.1)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-1ubuntu0.11.04.1)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
any advice ?
It was working perfectly for last 8 months.
I`m forced to use cgminer, witch i dont like to use with ztex.
March 21, 2013, 03:28:37 PM
In the coming days getwork will not work in all pools, you can use the proxy stratum and in fact is what we are using but in these circumstances will not be implemented stratum in btcminer?
January 18, 2013, 08:56:04 AM
Remember its a linux machine, no script processor 
If you use the RPI exclusively for the ZTEX boards: create cronjob that runs a shutdown -r every 3 or 6 hours.
If also other tasks are running then create cronjob which applies a kill -9 on the BTCMiner task and restart it.
Of course you can use the same RPI to run a stratum-proxy, configure it for your favourite pools and point the BTCMiner to localhost instead of the pools ip(s).
If you use the RPI exclusively for the ZTEX boards: create cronjob that runs a shutdown -r every 3 or 6 hours.
If also other tasks are running then create cronjob which applies a kill -9 on the BTCMiner task and restart it.
Of course you can use the same RPI to run a stratum-proxy, configure it for your favourite pools and point the BTCMiner to localhost instead of the pools ip(s).
January 08, 2013, 04:21:58 AM
Rpi is not handling Ztex miners very well.
I tried but the pi failed (one or multiple units) after some random time.
Has something to do with the integrated USB....
I tried but the pi failed (one or multiple units) after some random time.
Has something to do with the integrated USB....
January 07, 2013, 08:15:15 PM
Are you planning to implement Stratum?
And also version for ARM architecture, like Raspberry Pi?
And also version for ARM architecture, like Raspberry Pi?
January 07, 2013, 09:00:21 AM
Yeah, word! Would be great if ztex and grobi42 could continue their great work with btcminer! 
Without stratum I have between 1-2% rejected shares.
Without stratum I have between 1-2% rejected shares.
Rejected shares are mostly duplicate shares. If pool server responds to slow BTCMiner re-submits shares. Usually a few stales occur too because by default (if submitold flag is not set) BTCMiner always submits shares which are already found.
BTCMiner will be updated from time to time as long the software is used. (ATM I'm engaged with new SDK implementations. Next BTCMiner release will not appear before February.)
January 06, 2013, 05:21:21 AM
Yeah, word! Would be great if ztex and grobi42 could continue their great work with btcminer!
Without stratum I have between 1-2% rejected shares.
Without stratum I have between 1-2% rejected shares.
December 21, 2012, 06:30:40 PM
I absolutely agree that the backup pool handling is less than optimal.
December 19, 2012, 02:43:00 AM
Thanks lenny!
Not the newest source (August) but this is working fine.
Not the newest source (August) but this is working fine.
December 18, 2012, 04:25:49 PM
Hello there,
I am very happy Ztex customer and BTCMiner user. But there are some problems which makes me worried.
Sometimes FPGA boards are really slowing down when main mining pool is unavailable. BTCMiner tries to reconnect thousands of times to main pool and some of boards are idling. Backup pool reporting 30% of hashing power. I could not determine is it a problem with backup pool or BTCMiner trying to reach main pool and wasting time.
Just look at this log:
every single chip on 1.15y board is reporting that, spamming logfile.
And then again, every minute:
And continues. Why is LP disabled when main pool is unavailable? LP could be reached from backup pool.
My suggestions:
1. Add an option to choose, for how long pool should be disabled when unavailable. 60sec is just too short. When main pool fails, I would like to disable it for 10 minutes instead, to make sure it have time to settle down, whatever happening with it.
2. Disable spamming logfile from every single chip, when main pool is unavailable (when running in cluster mode). Only one message like:should be enough.
3. Enable logging of backup pool connections - when main pool refusing connections, BTCMiner should write in log file something like:
EDIT: I noticed that this message "Using LongPooling ..." with backup pool address appears only when main pool is down during miner startup. Later, when pool goes down, we don't know where miner is connected, there is no message about it.
4. When main pool is down, pressing "i" to see status doesn't work, it's lagging for couple of minutes to get output.
What you guys think?
I am very happy Ztex customer and BTCMiner user. But there are some problems which makes me worried.
Sometimes FPGA boards are really slowing down when main mining pool is unavailable. BTCMiner tries to reconnect thousands of times to main pool and some of boards are idling. Backup pool reporting 30% of hashing power. I could not determine is it a problem with backup pool or BTCMiner trying to reach main pool and wasting time.
Just look at this log:
Code:
2012-12-18T20:54:34: Warning: Connection refused: disabling long polling fo 60s
2012-12-18T20:54:34: 001-0: ztex_ufm1_15y1-04A3918D14-2: Error: Connection refused: Disabling URL http://localhost:4990 for 60s
2012-12-18T20:54:34: 001-0: ztex_ufm1_15y1-04A3465EA1-1: Error: Connection refused: Disabling URL http://localhost:4990 for 60s
2012-12-18T20:54:36: 001-0: ztex_ufm1_15y1-04A3463804-2: Error: Connection refused: Disabling URL http://localhost:4990 for 60s
(...)
And then again, every minute:
Code:
2012-12-18T20:58:34: Warning: Connection refused: disabling long polling fo 60s2012-12-18T20:57:47: 001-0: ztex_ufm1_15y1-04A39E4007-4: Error: Connection refused: Disabling URL http://localhost:4990 for 60s
2012-12-18T20:57:49: 001-0: ztex_ufm1_15y1-04A3918D14-2: Error: Connection refused: Disabling URL http://localhost:4990 for 60s
2012-12-18T20:57:49: 001-0: ztex_ufm1_15y1-04A3919EA0-4: Error: Connection refused: Disabling URL http://localhost:4990 for 60s
(...)
My suggestions:
1. Add an option to choose, for how long pool should be disabled when unavailable. 60sec is just too short. When main pool fails, I would like to disable it for 10 minutes instead, to make sure it have time to settle down, whatever happening with it.
2. Disable spamming logfile from every single chip, when main pool is unavailable (when running in cluster mode). Only one message like:
Code:
Error: Connection refused: Disabling URL xxx for xxx sec
3. Enable logging of backup pool connections - when main pool refusing connections, BTCMiner should write in log file something like:
Code:
Error: Connection refused: Disabling URL http://localhost:4990 for 60s
Using LongPolling URL http://backup_pool:8332/lp
4. When main pool is down, pressing "i" to see status doesn't work, it's lagging for couple of minutes to get output.
What you guys think?
December 17, 2012, 07:55:07 PM
Has anyone tried to port the BTCMiner to ARM-architecture?
http://blog.villekangas.com/?p=23 December 15, 2012, 05:03:50 PM
Is this USB-related? Im more the hardware guy...
"Possible cause: can't load IA 32-bit .so on a ARM-bit platform"
For me this sounds as if this or all all libraries must be 64bit.
For better stability i use on the raspberrys hardware watchdog, if the system hangs for more than a few seconds it will be hard-resetted. Software errors can be caught by a cronjob which is checking if the miner is running, otherwise starting it.
"Possible cause: can't load IA 32-bit .so on a ARM-bit platform"
For me this sounds as if this or all all libraries must be 64bit.
For better stability i use on the raspberrys hardware watchdog, if the system hangs for more than a few seconds it will be hard-resetted. Software errors can be caught by a cronjob which is checking if the miner is running, otherwise starting it.
December 15, 2012, 02:31:22 PM
Tried it ... My pi was unstable as hell .... Worked fine for at least an hour. Then the pi shut down.
You have to call the string with "sudo" command. Otherwise it won't work
Do u have the right lib USB installed ?
Mind that cgminer and BTCminer use different ports ...
You have to call the string with "sudo" command. Otherwise it won't work
Do u have the right lib USB installed ?
Mind that cgminer and BTCminer use different ports ...
December 15, 2012, 02:30:50 PM
...
What confuses me: Why is a port needed, I always thougt java bytecode is platform independent?
What confuses me: Why is a port needed, I always thougt java bytecode is platform independent?
The java code is platform independent but it's using some native code library which has to be ported.
December 15, 2012, 02:25:56 PM
Has anyone tried to port the BTCMiner to ARM-architecture? When i try running the .jar on the raspberry pi and OpenJDK Runtime Environment (IcedTea7 2.3.2) i get this error:
It would be very nice to run the very energy efficient Ztex-boards with a 5 Watt pc
What confuses me: Why is a port needed, I always thougt java bytecode is platform independent?
Code:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/libusbJavaSt.so: /tmp/libusbJavaSt.so: cannot open shared object file: No such file or directory (Possible cause: can't load IA 32-bit .so on a ARM-bit platform)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1935)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1860)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1821)
at java.lang.Runtime.load0(Runtime.java:792)
at java.lang.System.load(System.java:1059)
at ch.ntb.usb.LibLoader.load(LibLoader.java:69)
at ch.ntb.usb.LibusbJava.(LibusbJava.java:389)
at BTCMiner.main(BTCMiner.java:2044)
What confuses me: Why is a port needed, I always thougt java bytecode is platform independent?
December 09, 2012, 04:28:36 AM
I have bitcoin client on port 8332, so even if my old linux can run your code I have to mess around with configs...
There is no config, just simple parameters.
Code:
./mining_proxy.py -gp 8001
This will do the job for you (gp means getwork port).
Quote
Also it's written in python... :/
I'm sorry if you have personal aversion against Python for some reason. Otherwise the installation is really simple, as documented here: https://github.com/slush0/stratum-mining-proxy . It takes literally 5 minutes to get it run.
December 09, 2012, 02:37:03 AM
2) Slush gives you transaction fee if you use stratum.
You can use stratum proxy...
I have bitcoin client on port 8332, so even if my old linux can run your code I have to mess around with configs...
Also it's written in python... :/
Jump to: