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

[antirack]

Nice report CAcoins, very helpful.

May I ask what EMC is? Edit: Uhh, EMC the pool. Never mind.

[Turbor]

Eclipse Mining Consortium

[Inspector 2211]

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.

Did you see application note 879?

Quote:

In short, the operations that must be implemented to reconfigure one value in the PLL are:
• Assert RST to the PLL (do not de-assert)
• Set DADDR on the PLL and assert DEN for one clock cycle
• Wait for the DRDY signal to assert from the PLL
• Perform a bitwise AND between the DO port and the MASK (DI = DO and MASK)
• Perform a bitwise OR between the DI signal and the BITSET (DI = DI or BITSET)
• Assert DEN and DWE on the PLL for one clock cycle
• Wait for the DRDY signal to assert from the PLL
• De-assert RST to the PLL
• Wait for PLL to lock

[ztex]

Did you see application note 879?

XAPP879 is about dynamic PLL reconfiguration.

PLL is not reconfigured. See the source code.

[ztex]

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

New feature: Improved overheat protection by FPGA shutdown if frequency drops too much.

The shutdown threshold is a factor and can be set by "-oh" option. If the frequency drops by that factor, but at least two frequency steps, the overheat shutdown is triggered. Default vaule is 0.05, recommended values are 0 to 0.1. If the value is set to 0 the FPGA is stopped if the frequency drops by two frequency steps.

[CA Coins]

Thanks for the new feature Ztex.  Do you think capping the maximum frequency overclock may improve the longevity of the FPGAs?

[Turbor]

Good feature, tnx a lot. What is the difference between 0 and 0.1 ? 0 is two clocks down and 0.1 ?

[CA Coins]

Good feature, tnx a lot. What is the difference between 0 and 0.1 ? 0 is two clocks down and 0.1 ?

I am thinking 0 means shutdown when drop by 2 steps, i.e. 8 Mhz with d3a, and 0.1 means frequency drop by a factor of 0.1, or 10%, ie say 200 to 180Mhz.

[CA Coins]

The 120221.jar seems to be running well with no-issues.  I am not sure I want to artificially test the disable on downclock feature by turning off the fan, but it is a nice to feature to have.  Does it measure the 2-clock down from the base 200Mhz or from what whatever the clock has been running at (I am mostly at 204 and 208)?

Regardless, it is a nice safety feature to have.  I am sure it will come in handy once the summer comes or one of those fans are bound to fail at some point.  Thanks for programming it in and keep up the good work!

[ztex]

Thanks for the new feature Ztex.  Do you think capping the maximum frequency overclock may improve the longevity of the FPGAs?

Only if the FPGA gets very hot (>60 °C). In that case I would recommend a better cooling.

[ztex]

The 120221.jar seems to be running well with no-issues.  I am not sure I want to artificially test the disable on downclock feature by turning off the fan, but it is a nice to feature to have.  Does it measure the 2-clock down from the base 200Mhz or from what whatever the clock has been running at (I am mostly at 204 and 208)?

The reference frequency is the highest frequency which is stable for a while.

If you want to test it, there is a "ztex_ufm1_15d3a.ihx" firmware with 1.41 MHz frequency steps in the package. (Just for fun. Will be removed in future.)

[CA Coins]

Great, thanks for the info.  I will give it a test run if I get a chance.

[Turbor]

I have some problems here getting GPUMAX to run. Here is what i get with BitMinter.

Code:

bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.02%,  maxErrorRate
=0.74%,  hashRate=208.0MH/s,  submitted 18 new nonces,  luckFactor=1.03
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.99%,  maxErrorRate
=1.86%,  hashRate=209.9MH/s,  submitted 16 new nonces,  luckFactor=0.94
bus-0-0: poll loop time: 15ms (USB: 0ms network: 15ms)   getwork time: 144ms  su
bmit time: 293ms
Total hash rate: 417.9 MH/s
Total submitted hash rate: 409.5 MH/s
 --------
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.12%,  maxErrorRate
=0.74%,  hashRate=207.8MH/s,  submitted 15 new nonces,  luckFactor=1.03
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.46%,  maxErrorRate
=1.86%,  hashRate=211.0MH/s,  submitted 9 new nonces,  luckFactor=0.91
bus-0-0: poll loop time: 15ms (USB: 0ms network: 15ms)   getwork time: 179ms  su
bmit time: 280ms
Total hash rate: 418.8 MH/s
Total submitted hash rate: 404.5 MH/s
 --------
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.26%,  maxErrorRate
=0.74%,  hashRate=207.5MH/s,  submitted 11 new nonces,  luckFactor=1.01
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.96%,  maxErrorRate
=1.86%,  hashRate=210.0MH/s,  submitted 11 new nonces,  luckFactor=0.91
bus-0-0: poll loop time: 16ms (USB: 0ms network: 16ms)   getwork time: 187ms  su
bmit time: 287ms

And now GPUMAX.

Code:

bus-0-0: ztex_ufm1_15d3-0001-02-05: Using LongPolling URL http://gpumax.com:8332
/listenChannel
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=200.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=200.0MH/s,  submitted 1 new nonces,  luckFactor=0.36
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=200.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=200.0MH/s,  submitted 0 new nonces,  luckFactor=0.00
bus-0-0: poll loop time: 145ms (USB: 0ms network: 145ms)   getwork time: 1416ms
 submit time: 1078ms
Total hash rate: 400.0 MH/s
Total submitted hash rate: 71.6 MH/s
 --------
Warning: jsonParse: Parameter `data' not found
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 204.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 204.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=204.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=204.0MH/s,  submitted 16 new nonces,  luckFactor=1.00
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=204.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=204.0MH/s,  submitted 13 new nonces,  luckFactor=0.77
bus-0-0: poll loop time: 475ms (USB: 0ms network: 475ms)   getwork time: 1730ms
 submit time: 2104ms
bus-0-0: Warning: 10 overflows occured. This is usually caused by a slow network
 connection.
Total hash rate: 408.0 MH/s
Total submitted hash rate: 357.9 MH/s
 --------
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 208.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 208.00MHz
New block detected by block monitor
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 212.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 212.00MHz
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 208.00MHz

Why is the poll loop time so much higher ? What does the "Warning: jsonParse: Parameter `data' not found" mean ?

[CA Coins]

I have some problems here getting GPUMAX to run. Here is what i get with BitMinter.

Code:

bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.02%,  maxErrorRate
=0.74%,  hashRate=208.0MH/s,  submitted 18 new nonces,  luckFactor=1.03
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.99%,  maxErrorRate
=1.86%,  hashRate=209.9MH/s,  submitted 16 new nonces,  luckFactor=0.94
bus-0-0: poll loop time: 15ms (USB: 0ms network: 15ms)   getwork time: 144ms  su
bmit time: 293ms
Total hash rate: 417.9 MH/s
Total submitted hash rate: 409.5 MH/s
 --------
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.12%,  maxErrorRate
=0.74%,  hashRate=207.8MH/s,  submitted 15 new nonces,  luckFactor=1.03
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.46%,  maxErrorRate
=1.86%,  hashRate=211.0MH/s,  submitted 9 new nonces,  luckFactor=0.91
bus-0-0: poll loop time: 15ms (USB: 0ms network: 15ms)   getwork time: 179ms  su
bmit time: 280ms
Total hash rate: 418.8 MH/s
Total submitted hash rate: 404.5 MH/s
 --------
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=208.00MHz,  errorRate=0.26%,  maxErrorRate
=0.74%,  hashRate=207.5MH/s,  submitted 11 new nonces,  luckFactor=1.01
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=212.00MHz,  errorRate=0.96%,  maxErrorRate
=1.86%,  hashRate=210.0MH/s,  submitted 11 new nonces,  luckFactor=0.91
bus-0-0: poll loop time: 16ms (USB: 0ms network: 16ms)   getwork time: 187ms  su
bmit time: 287ms

And now GPUMAX.

Code:

bus-0-0: ztex_ufm1_15d3-0001-02-05: Using LongPolling URL http://gpumax.com:8332
/listenChannel
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=200.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=200.0MH/s,  submitted 1 new nonces,  luckFactor=0.36
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=200.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=200.0MH/s,  submitted 0 new nonces,  luckFactor=0.00
bus-0-0: poll loop time: 145ms (USB: 0ms network: 145ms)   getwork time: 1416ms
 submit time: 1078ms
Total hash rate: 400.0 MH/s
Total submitted hash rate: 71.6 MH/s
 --------
Warning: jsonParse: Parameter `data' not found
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 204.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 204.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-05: f=204.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=204.0MH/s,  submitted 16 new nonces,  luckFactor=1.00
bus-0-0: ztex_ufm1_15d3-0001-02-06: f=204.00MHz,  errorRate=0.00%,  maxErrorRate
=0.00%,  hashRate=204.0MH/s,  submitted 13 new nonces,  luckFactor=0.77
bus-0-0: poll loop time: 475ms (USB: 0ms network: 475ms)   getwork time: 1730ms
 submit time: 2104ms
bus-0-0: Warning: 10 overflows occured. This is usually caused by a slow network
 connection.
Total hash rate: 408.0 MH/s
Total submitted hash rate: 357.9 MH/s
 --------
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 208.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 208.00MHz
New block detected by block monitor
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 212.00MHz
bus-0-0: ztex_ufm1_15d3-0001-02-06: Set frequency to 212.00MHz
New block detected by long polling
bus-0-0: ztex_ufm1_15d3-0001-02-05: Set frequency to 208.00MHz

Why is the poll loop time so much higher ? What does the "Warning: jsonParse: Parameter `data' not found" mean ?

Man, you're getting really long getwork and submit times with GPUMax.  I have seen the jsonParson data not found when I ran into issues with Long Polling.  Deepbit was having some network issues (ddos?) and I was getting similar long getwork/submit with the overflows as you.  Are you able to test the network to GPUMax with something else?

[Turbor]

Ping times are around 200ms for the pool... works well with my 3 GPUs and cgminer 2.3.1

[CA Coins]

Are you running the latest 120221.jar?  I checked my logs and I haven't seen this error since ztex fixed the LP bug.  This is what I got before the bug was fixed:
"Error: jsonParse: Parameter `data' not found: Disabling URL..."

[Turbor]

Yes, i run the newest version.

[ztex]

Code:

...
bus-0-0: poll loop time: 475ms (USB: 0ms network: 475ms)   getwork time: 1730ms
...

Why is the poll loop time so much higher?

See your logs, it is caused by a slow network. Maybe the pool server is attacked.

What does the "Warning: jsonParse: Parameter `data' not found" mean ?

This means the pool server returns an invalid getwork response.

[Turbor]

Thanks for the info. It looks like i can do nothing about that. Local speed is ok. All other pools work fine with your software. What is different with cgminer that it works (almost) without problems ? Or what can Pirate change to make it work better ?

[ztex]

Thanks for the info. It looks like i can do nothing about that.

You can try the "-n 1" option, i.e. one device per thread. But that only reduces the impact of the network problems.

What is different with cgminer that it works (almost) without problems ?

Any mining software will produce overflows if the server is not reachable. The difference is propably that cgminer dows not report this overflows.