BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150

[gr0bi42]

grobi42: Thanks you for the fancy webinterface. I am running the miner on a QNAP NAS. But the Webserver doesn't start up. Are there any logs where I can see why ?

edit: typo

Did you start the miner in httpd-cluster mode (option -m h instead -m c)?

Here's the startup script I'm using (replace user and pass, maybe the website url too):

Code:

#!/bin/sh

java -cp ZtexBTCMiner.jar BTCMiner -m h -id Ztex1 -p 7005 -ac 7200 -nolog -oh 0.1 -n 6 -tc \
-o "Slush (Stratum)" https://mining.bitcoin.cz/stats/ http://192.168.1.200:8332 user pass \
-o "BtcGuild (Stratum)" http://www.btcguild.com/my_account.php http://192.168.1.200:9332 user pass \
-o MtRed https://mtred.com/user/profile.html http://mtred.com:8337 user pass \
-o Itzod http://pool.itzod.ru/index.php http://pool.itzod.ru:8346 user pass \
-o Bitminter http://bitminter.com http://mint.bitminter.com:8332 user pass \
-o Ozcoin http://ozco.in http://eu.ozco.in:80 user pass \
-o 50Btc https://50btc.com/account http://50btc.com:8332 user pass \
-b Ozcoin http://ozco.in http://eu.ozco.in:80 user pass \
-b 50Btc https://50btc.com/account http://50btc.com:8332 user pass \
-b "BtcGuild (Stratum)" http://www.btcguild.com/my_account.php http://192.168.1.200:9332 user pass

Read the README for more details, or start BTCMiner with option -h to get a description of all options.

Some Website hints:

On the pool tab:
you can switch the pools by clicking on the pool number
you can open the pools website by clicking on the pools name

and if you click on the "Ztex1@fpga:7005" you can force and update.

So long

[1714800767]

1714800767

[1714800767]

1714800767

[1714800767]

1714800767

[fydel]

Thank you for your help. The webinterface is running now. I didn't use the httpd-cluster mode.

But I have the problem that no shares are submitted. I am using your newest jar. It makes no difference if I start it with or without the "-tc" parameter.
In the webinterface the tabs "miners" and "admin" are empty.

java -cp ZtexBTCMiner.jar BTCMiner -m h -p 7005 -ac 7200 -nolog -oh 0.1 -n 6 -tc -o Slush https://mining.bitcoin.cz/stats/ http://api.bitcoin.cz:8332 user pass

Any ideas?

[gr0bi42]

Thank you for your help. The webinterface is running now. I didn't use the httpd-cluster mode.

But I have the problem that no shares are submitted. I am using your newest jar. It makes no difference if I start it with or without the "-tc" parameter.
In the webinterface the tabs "miners" and "admin" are empty.

java -cp ZtexBTCMiner.jar BTCMiner -m h -p 7005 -ac 7200 -nolog -oh 0.1 -n 6 -tc -o Slush https://mining.bitcoin.cz/stats/ http://api.bitcoin.cz:8332 user pass

Any ideas?

Seem's that you have encountered a bug. The pool is not active. A quick fix: click on the pool number on the Mining pools tab. Another advice, add a backup pool with option -b.

The option -n 6 is a nice have for my setup to distibute all miner equally to the mining threads. -nolog disables log file writing. -p 7005 is the httpd port number.

I will fix the bug later... have to leave now.

[fydel]

Thank you. The workaround did the trick.

But the tabs "Miner" and "Admin" are still empty for me.

I have sent 0.42 BTC to 1Btf3BqUegfe5iFdWsgfBf1Ew3YsAvsrLT for motivational purposes.

[gr0bi42]

A new bugfix version is available here: https://github.com/downloads/gr0bi42/BTCMiner/ZtexBTCMiner_gr0bi42_20121111.tar.bz2

Changes:

• Bugfix: getwork could not find a pool when only one mining pool was specified
• Bugfix: website did not show anything on the Miner and Admin tab when no backup pool was specified
• Change: print out a log message, if getwork fails to find a working pool

@fydel, thanks a lot for the tip

[fydel]

Cool! All fancy now. Keep up the good work!

[antirack]

I've just tried enabling target checking (-tc) on the latest version. I am mining over the stratum proxy with variable difficulty.

Most miners submit 0 new nonces. luckFactor on these is 0.00 but on the ones where it submits nonces it's high (ie. 19.52).
Why is the total submitted hash rate is almost double than the total hash rate?

Does this look right to you?

Code:

2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-1: f=212.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=212.0MH/s,  submitted 1 new nonces,  luckFactor=19.52
2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-2: f=216.00MHz,  errorRate=0.49%,  maxErrorRate=1.14%,  hashRate=214.9MH/s,  submitted 0 new nonces,  luckFactor=0.00
2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-3: f=220.00MHz,  errorRate=0.00%,  maxErrorRate=0.89%,  hashRate=220.0MH/s,  submitted 0 new nonces,  luckFactor=0.00
2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-4: f=220.00MHz,  errorRate=0.17%,  maxErrorRate=1.59%,  hashRate=219.6MH/s,  submitted 0 new nonces,  luckFactor=0.00

2012-11-16T12:08:53: Total hash rate: 13606.7 MH/s
2012-11-16T12:08:53: Total submitted hash rate: 24824.2 MH/s

[ztex]

I've just tried enabling target checking (-tc) on the latest version. I am mining over the stratum proxy with variable difficulty.

Most miners submit 0 new nonces. luckFactor on these is 0.00 but on the ones where it submits nonces it's high (ie. 19.52).
Why is the total submitted hash rate is almost double than the total hash rate?

Does this look right to you?

Yes, that looks right. "Submitted hash rate" and "luckFactor" depends on luck. If the amount of submitted shares is small, i.e. if target is high or runtime is short, this is normal.

Code:

2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-1: f=212.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=212.0MH/s,  submitted 1 new nonces,  luckFactor=19.52
2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-2: f=216.00MHz,  errorRate=0.49%,  maxErrorRate=1.14%,  hashRate=214.9MH/s,  submitted 0 new nonces,  luckFactor=0.00
2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-3: f=220.00MHz,  errorRate=0.00%,  maxErrorRate=0.89%,  hashRate=220.0MH/s,  submitted 0 new nonces,  luckFactor=0.00
2012-11-16T12:08:52: 001-0: ztex_ufm1_15y1-0000000031-4: f=220.00MHz,  errorRate=0.17%,  maxErrorRate=1.59%,  hashRate=219.6MH/s,  submitted 0 new nonces,  luckFactor=0.00

2012-11-16T12:08:53: Total hash rate: 13606.7 MH/s
2012-11-16T12:08:53: Total submitted hash rate: 24824.2 MH/s

[ztex]

A version has been released on http://www.ztex.de/btcminer.
Binaries: http://www.ztex.de/btcminer/ZtexBTCMiner-121116.jar
Source: http://www.ztex.de/btcminer/ZtexBTCMiner-121116.tar.bz2

New features are since the last testing release (121017):

    * Bug in the "ztex_ufm1_15y1.ihx" firmware fixed (configuration failed if auto-suspend triggered)

Those who installed this firmware file in EEPROM should replace it (using "BTCMiner -m p -pt ztex_ufm1_15y1 -f ztex_ufm1_15y1.ihx". If the default (dummy) firmware is used BTCMiner automatically loads the fxied firmware after next power-up).

New features are since the last official release:

    * Temperature sensor support for USB-FPGA Modules 1.15y rev. 2 (temperature limit is set using the paramter -t)
    * X-Mining-extensions: midstate, submitold
    * Target checking, must be enabled using -tc
    * MAC address printed at -i

[gr0bi42]

A version has been released on http://www.ztex.de/btcminer.
Binaries: http://www.ztex.de/btcminer/ZtexBTCMiner-121116.jar
Source: http://www.ztex.de/btcminer/ZtexBTCMiner-121116.tar.bz2

New features are since the last testing release (121017):

    * Bug in the "ztex_ufm1_15y1.ihx" firmware fixed (configuration failed if auto-suspend triggered)

Those who installed this firmware file in EEPROM should replace it (using "BTCMiner -m p -pt ztex_ufm1_15y1 -f ztex_ufm1_15y1.ihx". If the default (dummy) firmware is used BTCMiner automatically loads the fxied firmware after next power-up).

New features are since the last official release:

    * Temperature sensor support for USB-FPGA Modules 1.15y rev. 2 (temperature limit is set using the paramter -t)
    * X-Mining-extensions: midstate, submitold
    * Target checking, must be enabled using -tc
    * MAC address printed at -i

Hi, my BTCMiner+HTTP branch is now in sync with latest BTCMiner Version 121116.

https://github.com/gr0bi42/BTCMiner
https://github.com/downloads/gr0bi42/BTCMiner/ZtexBTCMiner_gr0bi42_20121116.tar.bz2

[ztex]

Hi, my BTCMiner+HTTP branch is now in sync with latest BTCMiner Version 121116.

https://github.com/gr0bi42/BTCMiner
https://github.com/downloads/gr0bi42/BTCMiner/ZtexBTCMiner_gr0bi42_20121116.tar.bz2

Thanks for your effort.

[ztex]

A version has been released at http://www.ztex.de/btcminer.
Binaries: http://www.ztex.de/btcminer/ZtexBTCMiner-121126.jar
Source: http://www.ztex.de/btcminer/ZtexBTCMiner-121126.tar.bz2

New features are :
    * Target checking bug fixed
    * (D)isconnect command

The disconnect command is helpful if you lost only one miner from a quad board (e.g. due to an communication error) because rescan only scans for new devices on USB. In such a case disconnect the whole device (using the (d)isconnect command) and then do a rescan (using the (r)escan command).

Syntax is

Code:

(d)isconnect <serial number>

[gr0bi42]

A version has been released at http://www.ztex.de/btcminer.
Binaries: http://www.ztex.de/btcminer/ZtexBTCMiner-121126.jar
Source: http://www.ztex.de/btcminer/ZtexBTCMiner-121126.tar.bz2

New features are :
    * Target checking bug fixed
    * (D)isconnect command

The disconnect command is helpful if you lost only one miner from a quad board (e.g. due to an communication error) because rescan only scans for new devices on USB. In such a case disconnect the whole device (using the (d)isconnect command) and then do a rescan (using the (r)escan command).

Syntax is

Code:

(d)isconnect <serial number>

Ditto, updated to version 121126:

Source: https://github.com/gr0bi42/BTCMiner
Binaries: https://github.com/downloads/gr0bi42/BTCMiner/ZtexBTCMiner_gr0bi42_20121126.tar.bz2

[antirack]

Thanks a log for the new version.

Up and running with the Ztex version on my cluster (without -tc for now).

Are there any plans to change backup pool handling?

I am currently using a stratum proxy on the local network. When the primary pool goes offline, it shows the error message per miner (ie. "... disabled for 60 seconds"), which could mean a lot of error messages. It also doesn't show that it is actually using the backup pool.

Would it make sense if the 60 seconds could be set on startup via command line?

How about changing pools during runtime? To make it easier, simply switching of the available pools would be sufficient, for instance by typing "(p)ool 2" to switch to the second pool in the available pools list specified via command line parameters.

Could features like this be requested for a small BTC donation from gr0bi42 and maybe make it back into the Ztex version?

[gr0bi42]

Are there any plans to change backup pool handling?

I am currently using a stratum proxy on the local network. When the primary pool goes offline, it shows the error message per miner (ie. "... disabled for 60 seconds"), which could mean a lot of error messages. It also doesn't show that it is actually using the backup pool.

I have changed to original pool/backup pools strategy a little bit. My version supports a list of normal mining pools (-o option) and a list of backup pools (-b option).

From the list of normal mining pool, only one can be active at any time. You can switch between these normal mining pools via web interface. The current active mining pool is marked green. If the current active mining pools fails (down, lagging... or whatever reason), then it gets disabled for 60 seconds (180 seconds in my version) and the first backup pool comes in turn. If the first backup pool fails too, then the seconds backup pools is used... and so on. After 60 seconds (180 seconds) BTCMiner retries with the original normal mining pool. All this is done on a "per miner (fpga)" basis. This is the reason why it's not easy to show which pool/backup pool is used.

Would it make sense if the 60 seconds could be set on startup via command line?

Easy to implement.

How about changing pools during runtime? To make it easier, simply switching of the available pools would be sufficient, for instance by typing "(p)ool 2" to switch to the second pool in the available pools list specified via command line parameters.

Could features like this be requested for a small BTC donation from gr0bi42 and maybe make it back into the Ztex version?

Already implemented in my version (list of mining pools, -o option). Pool switching via command line interface could be implemented easily too.

[rupy]

ztex any plans for stratum for BTCMiner?

The bandwidth requirement of your ZTEX cluster is a few hundred bytes per second. Your Internet connection should be able to handle this.

Implementation is not planned within the next release (but maybe later).

Is stratum still "maybe" or planned?

[ztex]

ztex any plans for stratum for BTCMiner?

The bandwidth requirement of your ZTEX cluster is a few hundred bytes per second. Your Internet connection should be able to handle this.

Implementation is not planned within the next release (but maybe later).

Is stratum still "maybe" or planned?

Implementation of one network bandwitdh saving protocol is planned. But I have not decided which one.

Rupy, why did you ask for this feature (at least two times)? Do you have bandwitdh shortage? Your cluster requires about 100 Bytes per second.

[rupy]

Two reasons:

1) HTTP is a retarded protocol for realtime two way communication, TCP is not.

2) Slush gives you transaction fee if you use stratum.

[Nachtwind]

ztex any plans for stratum for BTCMiner?

The bandwidth requirement of your ZTEX cluster is a few hundred bytes per second. Your Internet connection should be able to handle this.

Implementation is not planned within the next release (but maybe later).

Is stratum still "maybe" or planned?

Implementation of one network bandwitdh saving protocol is planned. But I have not decided which one.

Rupy, why did you ask for this feature (at least two times)? Do you have bandwitdh shortage? Your cluster requires about 100 Bytes per second.

Simply go with the majority of pools: Stratum

[narousberg]

+1 for Stratum)))