Pages:
Author

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

donator
Activity: 367
Merit: 250
ZTEX FPGA Boards
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.
donator
Activity: 367
Merit: 250
ZTEX FPGA Boards
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.
donator
Activity: 367
Merit: 250
ZTEX FPGA Boards
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
donator
Activity: 305
Merit: 250
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?
hero member
Activity: 489
Merit: 500
Immersionist
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.
donator
Activity: 305
Merit: 250
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?
legendary
Activity: 1022
Merit: 1000
BitMinter
You are running them in cluster mode, right? I am just wondering if you'd run a single one if you'd also end up with 50% CPU usage.

I still haven't gotten around installing Ubuntu and it will probably take a while till I have the time.


I did run them alone. AMD duo core and Intel Core2 Quad Q6600. Never had high CPU usage. Only from my GPUs.
hero member
Activity: 489
Merit: 500
Immersionist
You are running them in cluster mode, right? I am just wondering if you'd run a single one if you'd also end up with 50% CPU usage.

I still haven't gotten around installing Ubuntu and it will probably take a while till I have the time.
legendary
Activity: 1022
Merit: 1000
BitMinter
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. And no dumbbell on top of my 1.15x at all Wink

Edit: I have tried a second Windows 7 PC and I have the java.exe process using 50% CPU as well. Both Notebooks have a Intel Core 2 Duo CPU (2.66 GHz) but I just don't understand how somebody can have a quad core CPU that idles and I have a dual core CPU that uses 50%...


Never had an issue with a 1.15x board. Used d1, d2 and d3a with them. For mining i can only recommend them. 1.15d is a great board but if you want a 24/7 miner the small heatsink is a problem. I had to retreat my unlucky board again today. I pray to god it was the last time. All my "countown to death" experiences seemd hardware not software releated. The longer i run the boards the better i can see that propper cooling is the key to fast hash rates.
hero member
Activity: 489
Merit: 500
Immersionist
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. And no dumbbell on top of my 1.15x at all Wink

Edit: I have tried a second Windows 7 PC and I have the java.exe process using 50% CPU as well. Both Notebooks have a Intel Core 2 Duo CPU (2.66 GHz) but I just don't understand how somebody can have a quad core CPU that idles and I have a dual core CPU that uses 50%...
legendary
Activity: 1022
Merit: 1000
BitMinter
>dumbbells

I think, Xilinx specifies a maximum weight somewhere, and if I were you, I'd make sure not to exceed that.

I removed the weight after one night. When i was removing it, the downclocking began again. I ended up removing the heatsink and place it again. Now i only have a special heatsink sitting ontop of the stock one plus about 100g of lead and metal. Not sure if the latest downlocks are heat or PLL releated.
sr. member
Activity: 448
Merit: 250
No problem over here. I run a 4 board and a 2 board cluster.

Thanks.  Are you running the d3 firmware?  I think you mentioned that you were having some frequency issues until you tried the dumbbells?! 

Yes d3a, had some issues with that board yesterday and today. Downclock of death two times. Placed some weight on the heatsink. BTW the board is a 1.15d not 1.15x. I own 4 x and 2 d  boards. The 1.15d have a smaller heatsink and are more difficult to cool.

Now that mention it (downclock of death  Grin), a few days ago I my DSL modem hung and I switched DSL modems, whereupon there were ARP cache issues causing me to reboot the Windows 7 laptop as well - in a nutshell, when, after finally being online again, I tried to restart the mining software for the ZTEX board, I once again experienced the "downclock of death". With the d3a bitstream, no kidding. I then flashed the original (December) bitstream into it, but that also went into a "downclock of death" situation. Then, I flashed the d3a bitstream again and, lo and behold, this time it worked.

In other words: This PLL stuff is not 100% stable, but on the other hand there is a good chance it eventually will work, given a few tries.

>dumbbells

I think, Xilinx specifies a maximum weight somewhere, and if I were you, I'd make sure not to exceed that.
legendary
Activity: 1022
Merit: 1000
BitMinter
No problem over here. I run a 4 board and a 2 board cluster.

Thanks.  Are you running the d3 firmware?  I think you mentioned that you were having some frequency issues until you tried the dumbbells?! 

Yes d3a, had some issues with that board yesterday and today. Downclock of death two times. Placed some weight on the heatsink. BTW the board is a 1.15d not 1.15x. I own 4 x and 2 d  boards. The 1.15d have a smaller heatsink and are more difficult to cool.
sr. member
Activity: 448
Merit: 250
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?

I am starting it in a command.com prompt as administrator in case that matters.

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

I have one ZTEX module 1.15x and it's running the d3a bitstream.
The Windows 7 laptop it is attached to shows all 4 cores idle.
The clock frequency of the module 1.15x with a shitty $2.79 VGA cooler in a hot office (on account of twelve 5830s mining along happily and on account of the fact that the office window doesn't open) is 208 MHz.
I can't complain.
hero member
Activity: 489
Merit: 500
Immersionist
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?

I am starting it in a command.com prompt as administrator in case that matters.

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
donator
Activity: 305
Merit: 250
No problem over here. I run a 4 board and a 2 board cluster.

Thanks.  Are you running the d3 firmware?  I think you mentioned that you were having some frequency issues until you tried the dumbbells?! 
legendary
Activity: 1022
Merit: 1000
BitMinter
Has anybody gotten the boards to work in cluster mode?  The frequencies jump a lot when the boards run in cluster mode.  Single mode it runs just fine.  

No problem over here. I run a 4 board and a 2 board cluster.
donator
Activity: 305
Merit: 250
Has anybody gotten the boards to work in cluster mode?  The frequencies jump a lot when the boards run in cluster mode.  Single mode it runs just fine. 
hero member
Activity: 725
Merit: 503
Ok, anyways my revenue has increased more than expected with this version, so heat or no heat it's working great; and it seems you fixed my previous network error speed reduction too so: thumbs up! Smiley
donator
Activity: 367
Merit: 250
ZTEX FPGA Boards
Yep, mine is running at 216 MHz... It's really cool too... I wonder why? Why does the error rate rise at 220 when the chip doesn't generate any comparable heat to the last firmware at 208?!

The speed is limited by the logic and routing delays. These delays mainly depend on the semiconductor physics (i.e. not only from the temperature).

The power dissipation (heat) per MH/s is equal for all releases since 111214.
Pages:
Jump to: