Bitcoin Forum
March 19, 2024, 10:26:24 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
Author Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150  (Read 161481 times)
CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 305
Merit: 250


View Profile
February 05, 2012, 09:14:45 PM
 #241

I ran a few tests yesterday and sent ztex the results.  It seems that when I run in cluster mode, my little SB pentium G620 (win7 pro 64bit, jre64bit, 120130.jar, d1 firmware) gets overloaded (100%CPU).  The first board in the series gets programmed fine with ~3000ms programming time, but then the ones afterwards gets long programming times (~5-6000ms).  Those boards then had issues with the down-clock to death (nice phrase by the way).  If I try running them in single mode, if I program them too quickly, the later boards also gets the prolonged programming time and DCD.  I tried running the boards individually and starting them after the CPU has idled, and no problems.  I am gonna swap out the G620 with an i7 2600k but hopefully ztex can figure out what is going on.  I also noticed that when there is a delay in Long-Poll, the CPU goes crazy as well, but otherwise the CPU is nice and idle. 

Anybody else noticed the long programming time?
Bitcoin mining is now a specialized and very risky industry, just like gold mining. Amateur miners are unlikely to make much money, and may even lose money. Bitcoin is much more than just mining, though!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710843984
Hero Member
*
Offline Offline

Posts: 1710843984

View Profile Personal Message (Offline)

Ignore
1710843984
Reply with quote  #2

1710843984
Report to moderator
antirack
Hero Member
*****
Offline Offline

Activity: 489
Merit: 500

Immersionist


View Profile
February 06, 2012, 12:36:17 AM
Last edit: February 06, 2012, 02:50:46 AM by antirack
 #242

Quote from: CAcoins
Anybody else noticed the long programming time?

I have seen 3000+ ms or 7000+ ms, during the past two days testing (but nothing in between).

How many boards do you run in your cluster?

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

Here are some logs:

Code:
2012-02-04T17:50:16: ztex_ufm1_15d2-04A32E00E9: FPGA configuration time: 3093 ms
2012-02-04T18:59:02: ztex_ufm1_15d1-04A32E00E9: FPGA configuration time: 7428 ms
2012-02-04T18:59:02: ztex_ufm1_15d1-04A32E00E9: FPGA configuration time: 7428 ms
2012-02-04T18:23:17: ztex_ufm1_15d3-04A32E00E9: FPGA configuration time: 3123 ms
2012-02-04T18:52:39: ztex_ufm1_15d3-04A32E00E9: FPGA configuration time: 3122 ms
2012-02-04T19:33:12: ztex_ufm1_15d3-04A32E00E9: FPGA configuration time: 7333 ms
2012-02-05T14:07:56: ztex_ufm1_15d3-04A32E00E9: FPGA configuration time: 7706 ms

As for long polling, I usually get this:

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

As for the CPU usage, I use at 1.15x with 120130 d3a and I am on a Win7 32bit notebook with Intel Core 2 Duo P8800. I just installed Ubuntu on the same machine and gave it at try: the java process uses 100% CPU.

In Windows 7 I am working in the background (internet, emails, etc). Sometimes I have freezes happening, even the mouse freezes momentarily for a second or two. I am just wondering what would happen if I run multiple boards in a cluster instead of just one...I have no experience with other GPU miners, but I understand the CPU just idles.
CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 305
Merit: 250


View Profile
February 06, 2012, 08:00:51 AM
Last edit: February 06, 2012, 08:11:34 AM by CAcoins
 #243

Quote
Code:
Warning: High speed FPGA configuration failed, trying low speed mode:Claiming interface 0 failed:

I have to check the logs, but I have >5 1.15x in testing and I don't think I have seen this.  The programming shows no errors but gets prolonged when the the CPU gets choked off.  I was having some issues with Fedora and Ubuntu and actually ran the boards on a nettop with an Atom N450.  The programming (CPU intensive) took forever, but otherwise the CPU idles when mining.  I am not sure why your CPU is being used.  I have only seen that when there were connection problems.  I am testing on deepbit right now and the CPU stays quiet.

Quote
Code:
java -cp ZtexBTCMiner-120130.jar BTCMiner -host "http://api2.bitcoin.cz:8332" \
-u user -p password -f ztex_ufm1_15d3.ihx -v -l 120130-d3-slush.log

Have you tried programming the firmware into EEPROM beforehand to see if that helps with the CPU usage?
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 06, 2012, 08:24:40 AM
Last edit: February 06, 2012, 09:34:59 AM by ztex
 #244

I have received my first FPGA Board and I am running ZtexBTCMiner-120130 with D3 on Windows 7. I get stable 210.00 MHz.

The Java.exe process is using 50% CPU during mining (not yet during FPGA configuration). Is this normal?

It is a bug in the long polling thread which is triggered if mining pool/server does not return a valid long polling address and if no other long polling address is given.

Here is a fixed version: http://www.ztex.de/btcminer/ZtexBTCMiner-120203.jar

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 06, 2012, 08:32:13 AM
 #245

I too had similar "countdown to death" experiences yesterday with a new 1.15x and d3a and d2, only d1 worked. I have also changed the pool yesterday just to make sure it wasn't a problem with the pool, but same result.

Surprisingly, today the d3a worked without problem. I have not changed anything else, heat sink still the same, same power supply, same parameters etc.

d2, d3 and d3a firmwares are marked as experimental because they may not work.

But I think I found the problem: it was an undocumented requirement in the DCM re-programming sequence.

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 06, 2012, 08:57:55 AM
Last edit: February 06, 2012, 09:48:03 AM by ztex
 #246

I ran a few tests yesterday and sent ztex the results.  It seems that when I run in cluster mode, my little SB pentium G620 (win7 pro 64bit, jre64bit, 120130.jar, d1 firmware) gets overloaded (100%CPU).  The first board in the series gets programmed fine with ~3000ms programming time, but then the ones afterwards gets long programming times (~5-6000ms).  Those boards then had issues with the down-clock to death (nice phrase by the way).  If I try running them in single mode, if I program them too quickly, the later boards also gets the prolonged programming time and DCD.  I tried running the boards individually and starting them after the CPU has idled, and no problems.  I am gonna swap out the G620 with an i7 2600k but hopefully ztex can figure out what is going on.  I also noticed that when there is a delay in Long-Poll, the CPU goes crazy as well, but otherwise the CPU is nice and idle.  

There was another bug which is triggered in combination with the Long-Polling-busy bug and if there is only one CPU (core). If triggered, the configuration process does not to finish.

I sent you a fixed version. If it works it becomes a public release.

antirack
Hero Member
*****
Offline Offline

Activity: 489
Merit: 500

Immersionist


View Profile
February 06, 2012, 09:36:51 AM
 #247

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
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 06, 2012, 09:44:09 AM
 #248

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  <host url> <username> <password>" option.


slush
Legendary
*
Offline Offline

Activity: 1386
Merit: 1097



View Profile WWW
February 06, 2012, 12:58:28 PM
 #249

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.

Turbor
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
February 06, 2012, 06:11:01 PM
 #250

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.

nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
February 07, 2012, 12:19:14 PM
 #251

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?
trilby
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile
February 07, 2012, 06:10:13 PM
 #252

I am getting the clocking down to 0mhz is there a fix for this. It is happening with d2 d3 and d3a
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 07, 2012, 06:29:45 PM
 #253

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

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 07, 2012, 06:38:08 PM
 #254

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 ).

nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
February 07, 2012, 07:24:36 PM
 #255

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.
trilby
Newbie
*
Offline Offline

Activity: 45
Merit: 0


View Profile
February 07, 2012, 07:24:51 PM
 #256

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
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 07, 2012, 07:36:15 PM
 #257

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.

nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
February 07, 2012, 09:10:11 PM
 #258


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 Smiley

I've been really noisy lately, sorry about that.
Drsmite
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile
February 08, 2012, 03:17:14 PM
 #259

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/index.php?topic=18313.msg728439#msg728439)
Code:
public static void hexStrToData( String str, byte[] buf ) throws NumberFormatException {
if ( str.length()<buf.length*2 )
    throw new NumberFormatException("Invalid length of string");
for ( int i=0; i<buf.length; 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.
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
February 08, 2012, 04:39:12 PM
 #260

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.


Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!