CA Coins
Donator
Sr. Member
Offline
Activity: 305
Merit: 250
|
|
February 05, 2012, 09:14:45 PM |
|
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?
|
|
|
|
antirack
|
|
February 06, 2012, 12:36:17 AM Last edit: February 06, 2012, 02:50:46 AM by antirack |
|
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: 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: 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: 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
Activity: 305
Merit: 250
|
|
February 06, 2012, 08:00:51 AM Last edit: February 06, 2012, 08:11:34 AM by CAcoins |
|
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. 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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 06, 2012, 08:24:40 AM Last edit: February 06, 2012, 09:34:59 AM by ztex |
|
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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 06, 2012, 08:32:13 AM |
|
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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 06, 2012, 08:57:55 AM Last edit: February 06, 2012, 09:48:03 AM by ztex |
|
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
|
|
February 06, 2012, 09:36:51 AM |
|
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? 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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 06, 2012, 09:44:09 AM |
|
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
Activity: 1386
Merit: 1097
|
|
February 06, 2012, 12:58:28 PM |
|
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. I will add an extra check so that BTCMiner recognizes full URL's too.
Thank you for the fix.
|
|
|
|
Turbor
Legendary
Offline
Activity: 1022
Merit: 1000
BitMinter
|
|
February 06, 2012, 06:11:01 PM |
|
I run a single 1.15x board for testing, it usually displays high speed mode failed, like this: 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
Activity: 1540
Merit: 1002
|
|
February 07, 2012, 12:19:14 PM |
|
I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log: 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
Activity: 45
Merit: 0
|
|
February 07, 2012, 06: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
|
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 07, 2012, 06:29:45 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
|
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 07, 2012, 06:38:08 PM |
|
I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log: 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 ).
|
|
|
|
nelisky
Legendary
Offline
Activity: 1540
Merit: 1002
|
|
February 07, 2012, 07:24:36 PM |
|
I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log: 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 ). 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
Activity: 45
Merit: 0
|
|
February 07, 2012, 07:24:51 PM |
|
it even happens with d1 aswell will try that pre release when i get a min
|
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 07, 2012, 07:36:15 PM |
|
I'm experimenting with p2pool, and BTCMiner works fine there, except for these entries on p2pool log: 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 ). 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 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
Activity: 1540
Merit: 1002
|
|
February 07, 2012, 09:10:11 PM |
|
If you count the digits 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.
|
|
|
|
Drsmite
Newbie
Offline
Activity: 20
Merit: 0
|
|
February 08, 2012, 03:17:14 PM |
|
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) 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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
February 08, 2012, 04:39:12 PM |
|
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: 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.
|
|
|
|
|