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

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

A new release of BTCMiner has been published: http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar .

Changes:

Several bug fixes (LP busy bug, configuration bug, ...)
Workaround for the P2Pool LP response bug
Faster bitstream (in comparison to the 120126 release)

The Firmware files of this release are (see also http://www.ztex.de/btcminer):

Firmware file	Frequency step
ztex_ufm1_15d1.ihx	8 Mhz
ztex_ufm1_15d3.ihx	6 Mhz
ztex_ufm1_15d3a.ihx	4 Mhz

If the software is used in cluster mode, the firmware has to be updated e.g. by

Code:

java -cp ZtexBTCMiner-120208.jar BTCMiner -m p -pt ztex_ufm1_15d3 -f ztex_ufm1_15d3.ihx

Drsmite

newbie

Activity: 20

Merit: 0

Quote from: ztex on February 08, 2012, 01:01:52 PM

Quote from: Drsmite on February 08, 2012, 12:34:50 PM

Quote from: ztex on February 08, 2012, 12:26:45 PM

Quote from: Drsmite on February 08, 2012, 12:16:28 PM

That is the only place I have encountered it. Regarding disabling LP wouldn't that render BTCMiner incompatible with P2Pool?

Agreed. Simply ignoring this error is better. (If LP is so important they should implement it correctly ...)

I apologize for being a bother and I would love to ignore it, but as it is it actually stops the miner completely which is why I suggested some handling. I will take a look at their LP implementation to see if I can spot the problem.

I meant I will add a workaround so that is error is ignored by BTCMiner (and does not stop it).

Ah, thanks so much! Level level of support and quality of your product is frankly astounding. Good work!

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Drsmite on February 08, 2012, 12:34:50 PM

Quote from: ztex on February 08, 2012, 12:26:45 PM

Quote from: Drsmite on February 08, 2012, 12:16:28 PM

That is the only place I have encountered it. Regarding disabling LP wouldn't that render BTCMiner incompatible with P2Pool?

Agreed. Simply ignoring this error is better. (If LP is so important they should implement it correctly ...)

I apologize for being a bother and I would love to ignore it, but as it is it actually stops the miner completely which is why I suggested some handling. I will take a look at their LP implementation to see if I can spot the problem.

I meant I will add a workaround so that is error is ignored by BTCMiner (and does not stop it).

Drsmite

newbie

Activity: 20

Merit: 0

Quote from: ztex on February 08, 2012, 12:26:45 PM

Quote from: Drsmite on February 08, 2012, 12:16:28 PM

That is the only place I have encountered it. Regarding disabling LP wouldn't that render BTCMiner incompatible with P2Pool?

Agreed. Simply ignoring this error is better. (If LP is so important they should implement it correctly ...)

I apologize for being a bother and I would love to ignore it, but as it is it actually stops the miner completely which is why I suggested some handling. I will take a look at their LP implementation to see if I can spot the problem.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Drsmite on February 08, 2012, 12:16:28 PM

That is the only place I have encountered it. Regarding disabling LP wouldn't that render BTCMiner incompatible with P2Pool?

Agreed. Simply ignoring this error is better. (If LP is so important they should implement it correctly ...)

Drsmite

newbie

Activity: 20

Merit: 0

That is the only place I have encountered it. Regarding disabling LP wouldn't that render BTCMiner incompatible with P2Pool?

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: Drsmite on February 08, 2012, 10:17:14 AM

Could you perhaps include some exception handling in the next stable release? Currently P2Pool will return a work request that is apparently too short as it triggers this exception (Slightly more details here: https://bitcointalk.org

There I found:

Quote

Code:

Exception in thread "Thread-0" java.lang.NumberFormatException: Invalid length of string
at BTCMiner.hexStrToData(BTCMiner.java:695)
at NewBlockMonitor.run(BTCMiner.java:159)

Can you confirm that this error occurs in NewBlockMonitor.run only (that are the long polling requests)? If yes, exception handling will be easy: disabling long polling.

Drsmite

newbie

Activity: 20

Merit: 0

Could you perhaps include some exception handling in the next stable release? Currently P2Pool will return a work request that is apparently too short as it triggers this exception (Slightly more details here: https://bitcointalksearch.org/topic/m.728439)

Code:

public static void hexStrToData( String str, byte[] buf ) throws NumberFormatException {
if ( str.length() throw new NumberFormatException("Invalid length of string");
for ( int i=0; i buf[i] = (byte) Integer.parseInt( str.substring(i*2,i*2+2), 16);
}
}

This is is thrown all the way back out to the command line when it might be able to make another request or at least not crash the entire instance. As such I can't reliably leave BTCMiner pointed at P2Pool without a second instance pointed to a PPS pool waiting with && in bash.

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: ztex on February 07, 2012, 02:36:15 PM

If you count the digits Wink

you will find out that the value is 224 bits long, i.e. the hash value is 0x000000004134f7d69c50c4e3e374867219fb2c1c5b7d079942c6a3dd197fbe3b which is smaller than 0x0000000100000000000000000000000000000000000000000000000000000000.

Ok, I give

I've been really noisy lately, sorry about that.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: nelisky on February 07, 2012, 02:24:36 PM

Quote from: ztex on February 07, 2012, 01:38:08 PM

Quote from: nelisky on February 07, 2012, 07:19:14 AM

I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log:

Code:

2012-02-07 12:16:15.898617 Worker z submitted share with hash > target:
2012-02-07 12:16:15.898790 Hash: 4134f7d69c50c4e3e374867219fb2c1c5b7d079942c6a3dd197fbe3b
2012-02-07 12:16:15.898912 Target: 3cd86727e50fbc00000000000000000000000

The miner still mines, shares are found, etc. So my assumption is that when the full nonce space has been calculated by the FPGA, the last value is returned, regardless of it being a match or not. Is this the case (meaning I can just ignore these) or is there something else going on?

BTCMiner only checks against the largest possible target (which is equal to the target of most pools). The check against the current target is done by the p2pool software or by the bitcoin software. (If not, even better Wink

).

Yeah, but that hash is certainly larger than the largest target... some zeros on the right side would be there. But that's ok, it does submit valid hashes too, was just curious.

If you count the digits Wink

you will find out that the value is 224 bits long, i.e. the hash value is 0x000000004134f7d69c50c4e3e374867219fb2c1c5b7d079942c6a3dd197fbe3b which is smaller than 0x0000000100000000000000000000000000000000000000000000000000000000.

trilby

newbie

Activity: 45

Merit: 0

Quote from: ztex on February 07, 2012, 01:29:45 PM

Quote from: trilby on February 07, 2012, 01:10:13 PM

I am getting the clocking down to 0mhz is there a fix for this. It is happening with d2 d3 and d3a

That is why d2, d3 and d3a firmwares are called experimental. Try out this pre-release: http://www.ztex.de/btcminer/ZtexBTCMiner-120206.jar

it even happens with d1 aswell will try that pre release when i get a min

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: ztex on February 07, 2012, 01:38:08 PM

Quote from: nelisky on February 07, 2012, 07:19:14 AM

I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log:

Code:

2012-02-07 12:16:15.898617 Worker z submitted share with hash > target:
2012-02-07 12:16:15.898790 Hash: 4134f7d69c50c4e3e374867219fb2c1c5b7d079942c6a3dd197fbe3b
2012-02-07 12:16:15.898912 Target: 3cd86727e50fbc00000000000000000000000

The miner still mines, shares are found, etc. So my assumption is that when the full nonce space has been calculated by the FPGA, the last value is returned, regardless of it being a match or not. Is this the case (meaning I can just ignore these) or is there something else going on?

BTCMiner only checks against the largest possible target (which is equal to the target of most pools). The check against the current target is done by the p2pool software or by the bitcoin software. (If not, even better Wink

).

Yeah, but that hash is certainly larger than the largest target... some zeros on the right side would be there. But that's ok, it does submit valid hashes too, was just curious.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: nelisky on February 07, 2012, 07:19:14 AM

I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log:

Code:

2012-02-07 12:16:15.898617 Worker z submitted share with hash > target:
2012-02-07 12:16:15.898790 Hash: 4134f7d69c50c4e3e374867219fb2c1c5b7d079942c6a3dd197fbe3b
2012-02-07 12:16:15.898912 Target: 3cd86727e50fbc00000000000000000000000

The miner still mines, shares are found, etc. So my assumption is that when the full nonce space has been calculated by the FPGA, the last value is returned, regardless of it being a match or not. Is this the case (meaning I can just ignore these) or is there something else going on?

BTCMiner only checks against the largest possible target (which is equal to the target of most pools). The check against the current target is done by the p2pool software or by the bitcoin software. (If not, even better Wink

).

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: trilby on February 07, 2012, 01:10:13 PM

I am getting the clocking down to 0mhz is there a fix for this. It is happening with d2 d3 and d3a

That is why d2, d3 and d3a firmwares are called experimental. Try out this pre-release: http://www.ztex.de/btcminer/ZtexBTCMiner-120206.jar

trilby

newbie

Activity: 45

Merit: 0

I am getting the clocking down to 0mhz is there a fix for this. It is happening with d2 d3 and d3a

nelisky

legendary

Activity: 1540

Merit: 1002

I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log:

Code:

2012-02-07 12:16:15.898617 Worker z submitted share with hash > target:
2012-02-07 12:16:15.898790 Hash: 4134f7d69c50c4e3e374867219fb2c1c5b7d079942c6a3dd197fbe3b
2012-02-07 12:16:15.898912 Target: 3cd86727e50fbc00000000000000000000000

The miner still mines, shares are found, etc. So my assumption is that when the full nonce space has been calculated by the FPGA, the last value is returned, regardless of it being a match or not. Is this the case (meaning I can just ignore these) or is there something else going on?

Turbor

legendary

Activity: 1022

Merit: 1000

BitMinter

Quote from: antirack on February 05, 2012, 07:36:17 PM

I run a single 1.15x board for testing, it usually displays high speed mode failed, like this:

Code:

ztex_ufm1_15d3-04A32E00E9: New device: bitfile=ztex_ufm1_15d3 f_default=200.00MHz f_max=240.00MHz HpC=1.0H
Warning: High speed FPGA configuration failed, trying low speed mode:Claiming interface 0 failed:
libusb0-dll:err [claim_interface] could not claim interface 0, invalid configuration 0
: Trying low speed mode
ztex_ufm1_15d3-04A32E00E9: FPGA configuration time: 7645 ms
ztex_ufm1_15d3-04A32E00E9: Set frequency to 200.00MHz

Disconnect device or press Ctrl-C for exit

I get the same warning on my 4 board cluster everytime i start the miner. Not really a problem but what is the cause ? With the other boards i don't see this.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: ztex on February 06, 2012, 04:44:09 AM

The Long Polling address returned by the server is usually a path, not a full URL.

From the official LP specification (provided by deepbit, who firstly implemented LP) it can be full URL as well, so my pool isn't breaking any specification.

Quote

I will add an extra check so that BTCMiner recognizes full URL's too.

Thank you for the fix.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: antirack on February 06, 2012, 04:36:51 AM

Code:

ztex_ufm1_15d3-04A32E00E9: Using LongPolling URL http://api2.bitcoin.cz:8332http://api2.bitcoin.cz:8403
Warning: For input string: "8332http:": disabling long polling

The Long Polling address returned by the server is usually a path, not a full URL. I will add an extra check so that BTCMiner recognizes full URL's too.

Long polling URL's can also be specified by hand using the "-lp " option.

antirack

hero member

Activity: 489

Merit: 500

Immersionist

I can confirm that I have very low CPU usage now on ZtexBTCMiner-120203.jar with d3a.

Thanks for fixing that so fast.

The "disabling long polling" message seems to happen with slush's pool, but not with Deepbit. Any idea?

Code:

ztex_ufm1_15d3-04A32E00E9: Using LongPolling URL http://api2.bitcoin.cz:8332http://api2.bitcoin.cz:8403
Warning: For input string: "8332http:": disabling long polling

Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 20. (Read 161737 times)