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

[ummas]

Hi. i`m testing 1.15y Ztex board for 1h now.

i passed through installation and running btcminer, and this is what i got:

Code:

arek@arek-GNG:~/btcm$ sudo java -cp ZtexBTCMiner-120417.jar BTCMiner -host htt//XXXXXXX:8332 -u ummas@op.pl_XXX -p XXX
Using firmware `ztex_ufm1_15y1.ihx' for `USB-FPGA Module 1.15y (default)'
MAC address: 0004a3469808
ztex_ufm1_15y1-04A3469808: New device: bitfile=ztex_ufm1_15y1   f_default=200,00MHz  f_max=240,00MHz  HpC=1.0H
ztex_ufm1_15y1-04A3469808: FPGA 1: configuration time: 286 ms
ztex_ufm1_15y1-04A3469808: FPGA 2: configuration time: 285 ms
ztex_ufm1_15y1-04A3469808: FPGA 3: configuration time: 284 ms
ztex_ufm1_15y1-04A3469808: FPGA 4: configuration time: 284 ms
ztex_ufm1_15y1-04A3469808-1: New FPGA
ztex_ufm1_15y1-04A3469808-1: Set frequency to 200,00MHz
ztex_ufm1_15y1-04A3469808-2: New FPGA
ztex_ufm1_15y1-04A3469808-2: Set frequency to 200,00MHz
ztex_ufm1_15y1-04A3469808-3: New FPGA
ztex_ufm1_15y1-04A3469808-3: Set frequency to 200,00MHz
ztex_ufm1_15y1-04A3469808-4: New FPGA
ztex_ufm1_15y1-04A3469808-4: Set frequency to 200,00MHz

A multi-FPGA board is detected. Use the cluster mode for additional statistics.
Disconnect device or press Ctrl-C for exit

ztex_ufm1_15y1-04A3469808-4: Using LongPolling URL http://pit.deepbit.net:8332/listenChannel
ztex_ufm1_15y1-04A3469808-4: f=200,00MHz,  errorRate=1,80%,  hashRate=196,4MH/s,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-3: f=200,00MHz,  errorRate=0,88%,  hashRate=198,2MH/s,  submitted 2 new nonces,  luckFactor=2,88
ztex_ufm1_15y1-04A3469808-2: f=200,00MHz,  errorRate=0,00%,  hashRate=200,0MH/s,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-1: f=200,00MHz,  errorRate=0,00%,  hashRate=200,0MH/s,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-4: Set frequency to 196,00MHz
ztex_ufm1_15y1-04A3469808-3: Set frequency to 196,00MHz
ztex_ufm1_15y1-04A3469808-2: Set frequency to 196,00MHz
ztex_ufm1_15y1-04A3469808-4: f=196,00MHz,  submitted 1 new nonces,  luckFactor=0,73
ztex_ufm1_15y1-04A3469808-3: f=196,00MHz,  submitted 0 new nonces,  luckFactor=1,46
ztex_ufm1_15y1-04A3469808-2: f=196,00MHz,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-1: f=200,00MHz,  errorRate=0,00%,  hashRate=200,0MH/s,  submitted 1 new nonces,  luckFactor=0,72
arek@arek-GNG:~/btcm$ 

when i seen it, i pushed ctrl+c to brake it. I`m assuming it`s cose the heat - is it correct ??
i got few questions, when it`s working, all leds, are off, but why suddenly one led is tourning on ?
I`m sure that there is too much heat, but just need comfirmation. I`m not mining with it until i will be sure.
i will just try to learn haw to make cluster, and prepare to chenge cooling.
should i experience hot VRM when idle ?? Can i put somme Cu on it ?
Can i pulg it in/out without reboot ? silly question i know. i`m using CON2 with power supply.

EDIT:
i`m really confused...

Code:

MH/s,  submitted 2 new nonces,  luckFactor=0,71
ztex_ufm1_15y1-04A3469808-4: f=196,00MHz,  errorRate=0,00%,  hashRate=196,0MH/s,  submitted 2 new nonces,  luckFactor=0,81
ztex_ufm1_15y1-04A3469808-3: f=196,00MHz,  errorRate=0,57%,  maxErrorRate=1,28%,  hashRate=194,9MH/s,  submitted 1 new nonces,  luckFactor=1,84
ztex_ufm1_15y1-04A3469808-2: f=196,00MHz,  errorRate=0,58%,  maxErrorRate=0,71%,  hashRate=194,9MH/s,  submitted 3 new nonces,  luckFactor=1,15
ztex_ufm1_15y1-04A3469808-1: f=204,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=204,0MH/s,  submitted 0 new nonces,  luckFactor=0,66
ztex_ufm1_15y1-04A3469808-4: f=196,00MHz,  errorRate=0,00%,  hashRate=196,0MH/s,  submitted 0 new nonces,  luckFactor=0,76
ztex_ufm1_15y1-04A3469808-3: f=196,00MHz,  errorRate=0,89%,  maxErrorRate=1,28%,  hashRate=194,2MH/s,  submitted 1 new nonces,  luckFactor=1,82
ztex_ufm1_15y1-04A3469808-2: f=196,00MHz,  errorRate=0,40%,  maxErrorRate=0,71%,  hashRate=195,2MH/s,  submitted 0 new nonces,  luckFactor=1,07
ztex_ufm1_15y1-04A3469808-1: f=204,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=204,0MH/s,  submitted 2 new nonces,  luckFactor=0,81
ztex_ufm1_15y1-04A3469808-1: Set frequency to 208,00MHz
ztex_ufm1_15y1-04A3469808-4: f=196,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=196,0MH/s,  submitted 0 new nonces,  luckFactor=0,70
ztex_ufm1_15y1-04A3469808-3: f=196,00MHz,  errorRate=1,18%,  maxErrorRate=1,28%,  hashRate=193,7MH/s,  submitted 0 new nonces,  luckFactor=1,70
ztex_ufm1_15y1-04A3469808-2: f=196,00MHz,  errorRate=0,29%,  maxErrorRate=0,71%,  hashRate=195,4MH/s,  submitted 0 new nonces,  luckFactor=0,99
ztex_ufm1_15y1-04A3469808-1: f=208,00MHz,  errorRate=0,00%,  hashRate=208,0MH/s,  submitted 1 new nonces,  luckFactor=0,84

EDIT2:
i have read all thred and another question came up: what kind of thermal protection shuld i use betwean LX150 and radiator ?? Arctic silver 5 (or simmilar) or should i use thermal pad with 7W/mK - expensiwe, but i alredy got somme - 0.5mm, 1.0 and 1.5. any sugestions??
Can i assume that if my freq is lower than 200, than i have cooling problem ?? it`s not 5-10 as i read before, but it`s not 200+ also.

[1714825925]

1714825925

[1714825925]

1714825925

[1714825925]

1714825925

[Chefnet]

normally you have a cooling or power issue. Use the arctic silver 5 and no pads.

[Turbor]

If you have error rates above 0.00 at 200 MHz something is not right with the heatsink placement. All of my boards do at least 208 MHz with reduced fan performance compared to stock. They are all SG3 chips but that should not make too much of a difference. I never had a problem with the thermal grease supplied with the heatsinks. AS5 is not really special in my eyes. Just don't use too much and grind down the heatsink so it makes propper contact with the chip.

[CA Coins]

@ummas, I will try to answer some of your questions here.  Ztex is the ultimate source of info of course, but good luck.

i got few questions, when it`s working, all leds, are off, but why suddenly one led is tourning on ?

The led turns on when the FPGA is not mining and the firmware is unloaded

should i experience hot VRM when idle ?? Can i put somme Cu on it ?

Don't think you need it.  The rest of the board is pretty cool. The USB controller I think gets a little toasty but shouldn't affect mining performance.

Can i pulg it in/out without reboot ? silly question i know. i`m using CON2 with power supply.

Yes.

EDIT2:
i have read all thred and another question came up: what kind of thermal protection shuld i use betwean LX150 and radiator ?? Arctic silver 5 (or simmilar) or should i use thermal pad with 7W/mK - expensiwe, but i alredy got somme - 0.5mm, 1.0 and 1.5. any sugestions??

Can i assume that if my freq is lower than 200, than i have cooling problem ?? it`s not 5-10 as i read before, but it`s not 200+ also.

You may have a cooling problem.  The stock paste will work.  I used the stock paste at first, then changed to AR5.  It doesn't make any difference.  Make sure you apply a really thin layer that covers the entire LX150.  With the quad, I would also recommend some airflow since the 4 heatsinks are pretty close together.

[punin]

I noticed the BTCMiner creates and writes to a log file. This is a problem for me as I'm running the miners as part of BAMT rig running off a USB stick, so I want to avoid any unnecessary writes. My quick fix to this problem was to run with -l /dev/null

Just wanted to share this so someone else will not have the same problem (I ran out of space on USB stick).

[ummas]

THX CA Coins for your help. I`m alredy in hardware ztex topic.
I had to setup cluster, but i dont have much time
With 1 quad board it`s not anoing.

I hah put just a bit of the grase in chip and put heatsink on it witch is screwd to pcb... 1-208 and seccond still 196MHz, 3 i 4 are stock and pulls 196
My ambient temp is terrible - 34*C that could be the problem.
I`m having 120x120 blowing on the board - it`s cool 5s after BTCminer stopped.

[CA Coins]

34C?  Ouch.  Yeah, that might be it.  Also they do vary a bit.  I have one running at 200 whereas another one is running at 232 so it depends partly on luck.

@punin:  do you mean the log that it writes with the -l option or does it write another log file?

[punin]

@punin:  do you mean the log that it writes with the -l option or does it write another log file?

I run miner from /etc/rc.local on startup: screen -d -m /root/FPGAstart.sh

FPGAstart.sh just to be just:

Code:

java -cp /home/user/Downloads/ZtexBTCMiner-120417.jar BTCMiner -host "http://mypool:8332" -u myworker -p foo -b "http://mybackup_pool:8332" user pass -v -m c

That resulted in a BTCMiner.log being created in /home/user/Downloads/

Adding option -l /dev/null prevents this.

[CA Coins]

@punin:  do you mean the log that it writes with the -l option or does it write another log file?

I run miner from /etc/rc.local on startup: screen -d -m /root/FPGAstart.sh

FPGAstart.sh just to be just:

Code:

java -cp /home/user/Downloads/ZtexBTCMiner-120417.jar BTCMiner -host "http://mypool:8332" -u myworker -p foo -b "http://mybackup_pool:8332" user pass -v -m c

That resulted in a BTCMiner.log being created in /home/user/Downloads/

Adding option -l /dev/null prevents this.

Thanks for the info.  I am running it on Ubuntu but not from a startup script.  Let me check to see if it leaves a log too.

[ztex]

i passed through installation and running btcminer, and this is what i got:

Code:

arek@arek-GNG:~/btcm$ sudo java -cp ZtexBTCMiner-120417.jar BTCMiner -host htt//XXXXXXX:8332 -u ummas@op.pl_XXX -p XXX
ztex_ufm1_15y1-04A3469808-4: Using LongPolling URL http://pit.deepbit.net:8332/listenChannel
ztex_ufm1_15y1-04A3469808-4: f=200,00MHz,  errorRate=1,80%,  hashRate=196,4MH/s,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-3: f=200,00MHz,  errorRate=0,88%,  hashRate=198,2MH/s,  submitted 2 new nonces,  luckFactor=2,88
ztex_ufm1_15y1-04A3469808-2: f=200,00MHz,  errorRate=0,00%,  hashRate=200,0MH/s,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-1: f=200,00MHz,  errorRate=0,00%,  hashRate=200,0MH/s,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-4: Set frequency to 196,00MHz
ztex_ufm1_15y1-04A3469808-3: Set frequency to 196,00MHz
ztex_ufm1_15y1-04A3469808-2: Set frequency to 196,00MHz
ztex_ufm1_15y1-04A3469808-4: f=196,00MHz,  submitted 1 new nonces,  luckFactor=0,73
ztex_ufm1_15y1-04A3469808-3: f=196,00MHz,  submitted 0 new nonces,  luckFactor=1,46
ztex_ufm1_15y1-04A3469808-2: f=196,00MHz,  submitted 0 new nonces,  luckFactor=0,00
ztex_ufm1_15y1-04A3469808-1: f=200,00MHz,  errorRate=0,00%,  hashRate=200,0MH/s,  submitted 1 new nonces,  luckFactor=0,72
arek@arek-GNG:~/btcm$ 

This looks like a cooling problem.

If it clocks down quickly (within a few seconds) / if the clock is running crazy it is usually a PSU overload problem. One or may FPGA's loose their configuration (partially or full)and delivers invalid results.

If it clocks down slowly it should be a cooling problem.

Please also read the hardware thread: https://bitcointalk.org/index.php?topic=49180.msg875211#msg875211

when i seen it, i pushed ctrl+c to brake it. I`m assuming it`s cose the heat - is it correct ??

Best way is to power it off.

i got few questions, when it`s working, all leds, are off, but why suddenly one led is tourning on ?

This happens when the over temperature protection is triggered.

Can i assume that if my freq is lower than 200, than i have cooling problem ?? it`s not 5-10 as i read before, but it`s not 200+ also.

I just checked the results of the the 6 Quads / 24FPGA's I tested intensely: one achieved only 196 MHz, 3 achieved 204 MHz, all others where faster.

[pazor]

hi ztex,

do the btcminer use the tacho signal of the fan ?

when i change the fan to the titan version there is no tacho signal comming from the fan.

btw:
what was the best mh/s value got a sigle board reached with last firmware and driver?

[ztex]

what was the best mh/s value got a sigle board reached with last firmware and driver?

CACoins reported 228 MHz (224 to 228 MH/s) in the hardware thread.

I have seen 224 MHz (about 223 MH/s) on a single.

The speed of the bitstreams for Singles and Quads are the same. There are only some differences in the glue logic. Routing of the rest is the same. On the Quads I have seen 240 MHz (239 MH/s) with a FPGA's from a lucky lot.

[ztex]

I noticed the BTCMiner creates and writes to a log file. This is a problem for me as I'm running the miners as part of BAMT rig running off a USB stick, so I want to avoid any unnecessary writes. My quick fix to this problem was to run with -l /dev/null

Just wanted to share this so someone else will not have the same problem (I ran out of space on USB stick).

Logging is mandatory since the last BTCMiner release. If you run a huge cluster over several moth you will see log files of a few hundred MB. That shouldn't be a problem on a USB stick.

I plan to implement HUP signal support in the next release. This will allow to use logrotate.

[pazor]

what was the best mh/s value got a sigle board reached with last firmware and driver?

CACoins reported 228 MHz (224 to 228 MH/s) in the hardware thread.

I have seen 224 MHz (about 223 MH/s) on a single.

The speed of the bitstreams for Singles and Quads are the same. There are only some differences in the glue logic. Routing of the rest is the same. On the Quads I have seen 240 MHz (239 MH/s) with a FPGA's from a lucky lot.

thank you for your reply.

could you please explain what the column "luckFactor" in the btcminer means ?
and are the errorRate only a result of poor cooling of the fpga or are involved more external factors (like dsl line, ping time, etc.)

if the cooling would be perfect, could be the frequenz rising up ? are any other limit factors ?

thank you in advance for your answers.

best regards

[nelisky]

I'm trying to wrap my head around the 1.15y mining to add support for it on cgminer, but the multi-fpga approach is not completely clear for me, and not having one such device to experiment with I wanted to ask a little help in clarifying things prior to me asking for others to test things. As I read the source, it appears to me that each FPGA on the 1.15y is assigned a separate miner thread, but I see no locking being done in the USB communication, and it appears to me that the same device handle is used for all threads.

As far as I can understand it, a BTCMiner is spawned for each FPGA but only the root miner gets attached to the poll loop, which will then iterate all child miners in sequence to prevent selectFpga() and command interleaving between the miner threads of the device. Is this correct?

Thanks!

[ztex]

could you please explain what the column "luckFactor" in the btcminer means ?
and are the errorRate only a result of poor cooling of the fpga or are involved more external factors (like dsl line, ping time, etc.)

It is the amount (found and) submitted shares in relation to the hash rate (= <frequency>*(1-<error rate>)*<hashes per clock> ). This value is unfluenced by pool reachability and should converge to 1.

[CA Coins]

Anybody with experience going solo with BTCMiner?

[punin]

I just noticed that the efficiency drops tremendously, when primary pool is unavailable. Stales up to 7%, cluster of 8 running pool as backup is getting around 700 Mhash/s to the pool while a cluster of 9 at the same pool, but using it as primary is getting full 1800 Mhash/s

Falling into backup server also makes BTCMiner highly unresponsive (f. ex. re-scanning bus freezes output for over 10s)

Is there a way or plans to improve this?

[ztex]

I just noticed that the efficiency drops tremendously, when primary pool is unavailable. Stales up to 7%, cluster of 8 running pool as backup is getting around 700 Mhash/s to the pool while a cluster of 9 at the same pool, but using it as primary is getting full 1800 Mhash/s

I cannot reproduce this. Backup pools are accessed in the same was as primary pool.

Falling into backup server also makes BTCMiner highly unresponsive (f. ex. re-scanning bus freezes output for over 10s)

Is there a way or plans to improve this?

This is obviously caused by very slow pool server responses (which block the mining  threads).

You should see this if you read the timing statistics.

The effect can be reduced by reducing the number of devices per thread (parameter -n). But the only way to solv this is to choose a faster pool server.

[CA Coins]

The effect can be reduced by reducing the number of devices per thread (parameter -n). But the only way to solv this is to choose a faster pool server.

Does reducing the number of devices also help if you're seeing overflows?