Is it intention that devices still show up with (i)nfo once they are (d)isconnected with d 'serial number'?
Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 5. (Read 161727 times)
December 08, 2012, 10:52:20 PM
December 08, 2012, 07:40:33 PM
Dear Santa, we wish for stratum under the christmas tree, please.
Lol, can I qoute it?
December 08, 2012, 07:38:35 PM
2) Slush gives you transaction fee if you use stratum.
You can use stratum proxy...
December 08, 2012, 11:38:01 AM
Dear Santa, we wish for stratum under the christmas tree, please.
December 08, 2012, 06:25:28 AM
+1 for Stratum)))
December 08, 2012, 06:14:39 AM
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
December 08, 2012, 04:47:44 AM
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.
1) HTTP is a retarded protocol for realtime two way communication, TCP is not.
2) Slush gives you transaction fee if you use stratum.
December 07, 2012, 06:53:39 AM
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.
December 07, 2012, 06:18:08 AM
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?
November 27, 2012, 04:42:26 AM
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 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?
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.
November 26, 2012, 06:32:24 PM
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?
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?
November 26, 2012, 12:52:08 PM
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
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
Ditto, updated to version 121126:
Source: https://github.com/gr0bi42/BTCMiner
Binaries: https://github.com/downloads/gr0bi42/BTCMiner/ZtexBTCMiner_gr0bi42_20121126.tar.bz2
November 26, 2012, 08:04:09 AM
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
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
November 26, 2012, 07:50:54 AM
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
https://github.com/gr0bi42/BTCMiner
https://github.com/downloads/gr0bi42/BTCMiner/ZtexBTCMiner_gr0bi42_20121116.tar.bz2
Thanks for your effort.
November 19, 2012, 11:42:34 AM
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
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
November 16, 2012, 10:04:19 AM
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
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
November 16, 2012, 03:35:52 AM
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?
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.
Quote
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
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
November 15, 2012, 11:18:38 PM
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?
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
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
November 11, 2012, 01:29:56 PM
Cool! All fancy now. Keep up the good work!
November 11, 2012, 08:14:30 AM
A new bugfix version is available here: https://github.com/downloads/gr0bi42/BTCMiner/ZtexBTCMiner_gr0bi42_20121111.tar.bz2
Changes:
@fydel, thanks a lot for the tip
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
Jump to: