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

[Drsmite]

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

[1715443172]

1715443172

[1715443172]

1715443172

[1715443172]

1715443172

[ztex]

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]

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]

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]

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]

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

[CA Coins]

Thanks Ztex for the updates.  I am finally going to have some time to do some testing today and I will let you know how it goes.

CAC

[paraipan]

posting on behalf of newbie user vibe ...

On Ubuntu 32bit using the latest ZtexBTCMiner-120208.jar with latest java.

java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)

# java -cp ZtexBTCMiner-120208.jar BTCMiner -host "http://asdasd.com:8337" -u asdasd -p asdasd -f ztex_ufm1_15d3.ihx -v
ztex_ufm1_15d3-04A32E1A99: New device: bitfile=ztex_ufm1_15d3   f_default=198.00MHz  f_max=240.00MHz  HpC=1.0H
ztex_ufm1_15d3-04A32E1A99: FPGA configuration time: 3240 ms
ztex_ufm1_15d3-04A32E1A99: Set frequency to 198.00MHz

Disconnect device or press Ctrl-C for exit

ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device

Greetings Vibe

[ztex]

posting on behalf of newbie user vibe ...

On Ubuntu 32bit using the latest ZtexBTCMiner-120208.jar with latest java.

java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)

# java -cp ZtexBTCMiner-120208.jar BTCMiner -host "http://asdasd.com:8337" -u asdasd -p asdasd -f ztex_ufm1_15d3.ihx -v
ztex_ufm1_15d3-04A32E1A99: New device: bitfile=ztex_ufm1_15d3   f_default=198.00MHz  f_max=240.00MHz  HpC=1.0H
ztex_ufm1_15d3-04A32E1A99: FPGA configuration time: 3240 ms
ztex_ufm1_15d3-04A32E1A99: Set frequency to 198.00MHz

Disconnect device or press Ctrl-C for exit

ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device

Greetings Vibe

As I wrote per Email: Download it again: http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar (last minut fix) and try it again.

[antirack]

I can confirm that the new BTCMiner-120208.jar release with the d3a firmware fixed the LP problem with slush's pool (bitcoin.cz) and also the "High speed FPGA configuration failed" warning seems to be gone for now. Configuration took 3000+ms instead of 7000+ms.

Something curious, why did it set the frequency from 216MHz to 220MHz and then straight back to 212MHz?

ztex_ufm1_15d3-04A32E00E9: Set frequency to 212.00MHz
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz,  errorRate=0.00%,  hashRate=212.0MH/s,  submitted 1 new nonces,  luckFactor=0.84
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz,  errorRate=0.40%,  maxErrorRate=0.50%,  hashRate=211.1MH/s,  submitted 2 new nonces,  luckFactor=0.95
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz,  errorRate=0.30%,  maxErrorRate=0.50%,  hashRate=211.4MH/s,  submitted 0 new nonces,  luckFactor=0.90
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz,  errorRate=0.57%,  maxErrorRate=0.60%,  hashRate=210.8MH/s,  submitted 1 new nonces,  luckFactor=0.92
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz,  errorRate=0.38%,  maxErrorRate=0.60%,  hashRate=211.2MH/s,  submitted 0 new nonces,  luckFactor=0.88
ztex_ufm1_15d3-04A32E00E9: Set frequency to 216.00MHz
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz,  submitted 2 new nonces,  luckFactor=0.94
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz,  errorRate=1.63%,  maxErrorRate=1.89%,  hashRate=212.5MH/s,  submitted 4 new nonces,  luckFactor=1.16
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz,  errorRate=2.05%,  maxErrorRate=2.49%,  hashRate=211.6MH/s,  submitted 5 new nonces,  luckFactor=1.40
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz,  errorRate=1.57%,  maxErrorRate=2.53%,  hashRate=212.6MH/s,  submitted 0 new nonces,  luckFactor=1.34
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz,  errorRate=2.00%,  maxErrorRate=2.53%,  hashRate=211.7MH/s,  submitted 5 new nonces,  luckFactor=1.56
ztex_ufm1_15d3-04A32E00E9: Set frequency to 220.00MHz
ztex_ufm1_15d3-04A32E00E9: Set frequency to 212.00MHz
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz,  errorRate=0.32%,  maxErrorRate=0.60%,  hashRate=211.3MH/s,  submitted 0 new nonces,  luckFactor=1.50
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz,  errorRate=0.22%,  maxErrorRate=0.60%,  hashRate=211.5MH/s,  submitted 1 new nonces,  luckFactor=1.49

[ztex]

I can confirm that the new BTCMiner-120208.jar release with the d3a firmware fixed the LP problem with slush's pool (bitcoin.cz) and also the "High speed FPGA configuration failed" warning seems to be gone for now. Configuration took 3000+ms instead of 7000+ms.

Something curious, why did it set the frequency from 216MHz to 220MHz and then straight back to 212MHz?

Because at 212MHz your board delivers the most valid hashes per second.

BTCMiner needs to test it out. (The frequency is increased until a certain error rate (10%) is reached. Then the frequency with the highest rate of valid hashes is chosen.)

As smaller the frequency steps as more often you can see this behavior. At 4MHz this is quite normal.

[Turbor]

Somehow i can't use d3a with my 1.15d boards ? d3 works...

Edit: User too dumb it works !

[CA Coins]

ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device

I noticed this error when I briefly tried running with EMC.  I didn't have time to fully test it out, but I just thought I didn't have the pool info correct.  Any thoughts?  EDIT:  This appears to be fixed with the latest 120208 release. 

I had a chance to test the cluster yesterday, and I just want to summarize my experience with ztex.  I hope I am not stating what everybody already knows:

Currently, with the 120208 release, I am able to run my 20-board test cluster with d1, d3, and d3a.  I have been testing with deepbit for the last week or so, and the rate has been very stable at around 4GH/S.  It will range between 3900 to 4100, but for the most part it is around 4,000 to 4,050 (60 min average per deepbit).  Most of the boards are running at 200 to 208 MHz.  Power, measured with a power meter at the outlet is 245 watts (APC BR1500, Corsair Ax1200 gold, core i7 2600k, 4gig ram, 32G SSD, win 7 64, jre64).

Code:

2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A1: f=204.00MHz,  errorRate=0.41%,  maxErrorRate=1.86%,  hashRate=203.2MH/s,  submitted 16 new nonces,  luckFactor=0.96
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A2: f=200.00MHz,  errorRate=0.00%,  maxErrorRate=0.31%,  hashRate=200.0MH/s,  submitted 11 new nonces,  luckFactor=1.02
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A3: f=200.00MHz,  errorRate=0.00%,  maxErrorRate=0.25%,  hashRate=200.0MH/s,  submitted 14 new nonces,  luckFactor=1.02
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A4: f=200.00MHz,  errorRate=0.00%,  maxErrorRate=1.05%,  hashRate=200.0MH/s,  submitted 11 new nonces,  luckFactor=0.99
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B1: f=208.00MHz,  errorRate=0.07%,  maxErrorRate=0.67%,  hashRate=207.8MH/s,  submitted 12 new nonces,  luckFactor=1.00
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B2: f=208.00MHz,  errorRate=1.23%,  maxErrorRate=1.94%,  hashRate=205.4MH/s,  submitted 8 new nonces,  luckFactor=0.96
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B3: f=200.00MHz,  errorRate=0.04%,  maxErrorRate=0.50%,  hashRate=199.9MH/s,  submitted 18 new nonces,  luckFactor=1.06
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B4: f=204.00MHz,  errorRate=0.12%,  maxErrorRate=1.33%,  hashRate=203.7MH/s,  submitted 12 new nonces,  luckFactor=0.92
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B5: f=204.00MHz,  errorRate=0.04%,  maxErrorRate=1.20%,  hashRate=203.9MH/s,  submitted 17 new nonces,  luckFactor=1.04
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B6: f=200.00MHz,  errorRate=0.27%,  maxErrorRate=0.54%,  hashRate=199.5MH/s,  submitted 17 new nonces,  luckFactor=1.03
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A0: f=204.00MHz,  errorRate=0.00%,  maxErrorRate=0.54%,  hashRate=204.0MH/s,  submitted 19 new nonces,  luckFactor=1.04
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A5: f=200.00MHz,  errorRate=0.30%,  maxErrorRate=1.48%,  hashRate=199.4MH/s,  submitted 13 new nonces,  luckFactor=0.96
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A6: f=200.00MHz,  errorRate=0.00%,  maxErrorRate=0.64%,  hashRate=200.0MH/s,  submitted 10 new nonces,  luckFactor=0.96
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A7: f=204.00MHz,  errorRate=1.86%,  maxErrorRate=2.95%,  hashRate=200.2MH/s,  submitted 20 new nonces,  luckFactor=1.07
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A8: f=204.00MHz,  errorRate=0.00%,  maxErrorRate=0.28%,  hashRate=204.0MH/s,  submitted 16 new nonces,  luckFactor=0.99
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A9: f=204.00MHz,  errorRate=0.00%,  maxErrorRate=0.32%,  hashRate=204.0MH/s,  submitted 12 new nonces,  luckFactor=1.00
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B0: f=204.00MHz,  errorRate=0.29%,  maxErrorRate=1.46%,  hashRate=203.4MH/s,  submitted 11 new nonces,  luckFactor=0.97
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B7: f=204.00MHz,  errorRate=0.00%,  maxErrorRate=0.32%,  hashRate=204.0MH/s,  submitted 13 new nonces,  luckFactor=1.05
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B8: f=204.00MHz,  errorRate=0.00%,  maxErrorRate=0.58%,  hashRate=204.0MH/s,  submitted 13 new nonces,  luckFactor=1.14
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B9: f=200.00MHz,  errorRate=0.45%,  maxErrorRate=1.45%,  hashRate=199.1MH/s,  submitted 18 new nonces,  luckFactor=1.08
2012-02-09T23:31:04: bus-0-0: poll loop time: 74ms (USB: 2ms network: 72ms)   getwork time: 189ms  submit time: 197ms
2012-02-09T23:31:04: bus-0-1: poll loop time: 75ms (USB: 2ms network: 73ms)   getwork time: 187ms  submit time: 194ms
2012-02-09T23:31:04: Total hash rate: 4045.6 MH/s
2012-02-09T23:31:04: Total submitted hash rate: 4076.4 MH/s

-Boards were shipped the day after payment.  Shipping took 4 days from Germany to California, including 2 days at customs.
-The boards were well packaged.
-Assembly of the heatsink was straight forward (I used arctic silver for the thermal paste instead of the included stock paste)
-The power supply is probably the most involved part of the assembly.  We decided to solder the wires and the connectors (anal retentiveness acting up) after initially using the terminals per ztex guide, which also works.
-There was a bug in the firmware programming code which is now fixed.  I think swapping out the pentium g620 for a core i72600k also helped.  The programming for 20 boards used up to 4 threads so I would recommend anyone running large clusters to use a cpu capable of handling a few threads.  It will run on the g620 without errors, but it maxes the cpu.  EDIT:  it maxes the g620 during the initial programming (uses 4 threads on the 2600k).  During actual mining, the software barely uses the cpu and a g620 is more than sufficient. /EDIT   2nd EDIT:  As of the newly release 120208.jar, programming does not utilize much cpu at all.  So a pentium g620 or a similar sempron should have no problem running a good-size cluster.
-Ambient temperature is about 75 degree F (sorry it is California) and heatsink temperature is around 85 F measured with a probe.  
-Mining has been very stable on deepbit, which is key for me.  Plan now is to try the other pools.  Is P2Pool running fine now?

Overall, I am very impressed with ztex's professional work and his boards.  He has been very responsive and I am definitely looking to purchase more boards from him.  Sorry to take up this space on the forum post, but I just thought I'd leave a good word for ztex and his work.

[ztex]

Thanks for the review.

ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device

I noticed this error when I briefly tried running with EMC.  I didn't have time to fully test it out, but I just thought I didn't have the pool info correct.  Any thoughts?

I uploaded a new http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar this morning (didn't spent a new version number) with two (more than) late minute fixes. It should reduce the CPU usage during start-up and the string error which occurs with some Java version.

It will run on the g620 without errors, but it maxes the cpu.

The CPU usage during runtime (i.e. after start-up) should be almost zero.

[CA Coins]

I uploaded a new http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar this morning (didn't spent a new version number) with two (more than) late minute fixes. It should reduce the CPU usage during start-up and the string error which occurs with some Java version.

Ok, will test it out.

The CPU usage during runtime (i.e. after start-up) should be almost zero.

Yes, during run time is almost no cpu usage (and yes, a 2600k is probably overkill but I couldn't help it.)  I will clarify it on my post that maxing the CPU is only during programming, otherwise it barely uses the cpu during run time.

[Turbor]

Wow, 20 boards... very nice. Looks like i have to upgrade soon . I wonder why the boards only run at 208 MHz, Here at 65 degree the slowest board runs at 208 and the fastest at 220. Most do 212. Perhaps you can try to cool them down more ? Replaced all my fans on the 1.15x boards with Scythe Kaze minis. They are a bit less effective since they run at 3500rpm, but they are very quiet. Lost 4 MHz on one board, the others have a bit higher error rate.

[CA Coins]

Looks like i have to upgrade soon .

Yes, time to upgrade    These little suckers are awesome.

I wonder why the boards only run at 208 MHz, Here at 65 degree the slowest board runs at 208 and the fastest at 220. Most do 212. Perhaps you can try to cool them down more ?

Yeah, ztex noticed it too.  I haven't really work on the cooling yet.  Maybe still stuck in the mindset that 60 degree C is cool.  I have some old Silverstone 120mm fans that I plan to use for some airflow.  Do you notice any difference if you have air flowing through the bottom of the boards?  I also have a habit of putting on too much thermal paste so I might re-apply to see if it makes a difference.  I am content with the hashrate though as long as it runs stable.  It's middle of winter and it is already 85 F outside.  And SCE charges an arm and a leg (12-30 cents/kwh) so AC is a hard pill to swallow.

[Turbor]

Looks like i have to upgrade soon .

Yes, time to upgrade    These little suckers are awesome.

I wonder why the boards only run at 208 MHz, Here at 65 degree the slowest board runs at 208 and the fastest at 220. Most do 212. Perhaps you can try to cool them down more ?

Yeah, ztex noticed it too.  I haven't really work on the cooling yet.  Maybe still stuck in the mindset that 60 degree C is cool.  I have some old Silverstone 120mm fans that I plan to use for some airflow.  Do you notice any difference if you have air flowing through the bottom of the boards?  I also have a habit of putting on too much thermal paste so I might re-apply to see if it makes a difference.  I am content with the hashrate though as long as it runs stable.  It's middle of winter and it is already 85 F outside.  And SCE charges an arm and a leg (12-30 cents/kwh) so AC is a hard pill to swallow.

If you can cool the heatsink from the side you should be able to see a difference. Best would be a 80mm fan behind every board for max effect. Heatsink placement can be a b!itch. I would start with the boards with the highest error rate and re-grease them to see if something changes. At 200 MHz you should not see any errors. Be carefull with the plastic pins ! I broke one off on my first board when i replaced the pad with thermal grease.

[CA Coins]

Thanks for the advice!  I will try it out and post the updated results.

[CA Coins]

I uploaded a new http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar this morning (didn't spent a new version number) with two (more than) late minute fixes. It should reduce the CPU usage during start-up and the string error which occurs with some Java version.

Tested out the latest version.  A couple of observations:

1.  The new programming doesn't use the cpu at all.  Barely noticed a blip on the cpu utilization during initial programming or mining.  So it doesn't seem like the software needs much cpu power at all.  May be time to replace the i7-2600k back to the G620.

2.  The problem with EMC appears fixed with the bug-fixes.  Now mining with no problems on EMC.

Bravo on the bug fixes!