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

CA Coins

donator

Activity: 305

Merit: 250

Quote from: ztex on May 08, 2012, 03:00:57 AM

Quote from: CA Coins on May 07, 2012, 05:30:46 AM

Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 , 0 bytes got lost; checksum=3 , should be 3; INIT_B_HIST=222): Retrying

That are no USB errors (checksum is correct and nothing gets lost).

Usually that are power problems, i.e. if the load step after configuration cannot be handled (also see my last email). It is also possible that the core voltage regulator gets to hot. If you use the coolers delivered with the board the heat sinks should orientated (can be rotated by 90°) so that the fans blow at the regulators.

Just a note: Stop the cluster using the 'q' command. This puts the boards in suspend mode. (But this is not the cause of you problem)

It's weird that it was running fine and only happened after I stopped the cluster then tried to restart it. I have noticed it before with the q command so I stopped using it. While running, I haven't noticed this problem.

In terms of the power issue, thanks for the recommendation. I re-routed the power cables and the quads have been running smoothly. I'll send you the details/logs via email.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: CA Coins on May 07, 2012, 05:30:46 AM

Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 , 0 bytes got lost; checksum=3 , should be 3; INIT_B_HIST=222): Retrying

That are no USB errors (checksum is correct and nothing gets lost).

Usually that are power problems, i.e. if the load step after configuration cannot be handled (also see my last email). It is also possible that the core voltage regulator gets to hot. If you use the coolers delivered with the board the heat sinks should orientated (can be rotated by 90°) so that the fans blow at the regulators.

Just a note: Stop the cluster using the 'q' command. This puts the boards in suspend mode. (But this is not the cause of you problem)

CA Coins

donator

Activity: 305

Merit: 250

Any way to fix this remotely without powering off/on the board?

EDIT: Did a rescan ~10hrs after the initial failed attempt and the board loaded the firmware without problems. Maybe it needed to wait until the old firmware is unloaded after a control-c?

BR0KK

hero member

Activity: 784

Merit: 500

USB Problem .... I have that too some times.

CA Coins

donator

Activity: 305

Merit: 250

Quote from: ztex on May 07, 2012, 05:20:41 AM

Quote from: CA Coins on May 07, 2012, 04:49:07 AM

Quote

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?

Usually yes. This depends on the amount of CPU cores, the size of the cluster and the OS. It's probably not wise to run 200 threads on a single core Atom.

Thanks, I will give it a try. Also, not sure if anybody has already mentioned, the block log option is listed as -lb on the help instead of -bl

EDIT: Just terminated the process remotely with control-c. When trying to restart, got:

Code:

ztex_ufm1_15y1-2012-L5-A1: New device: bitfile=ztex_ufm1_15y1   f_default=200.00MHz  f_max=240.00MHz  HpC=1.0H
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high, possible USB transfer errors (INIT_B_HIST=222): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high, possible USB transfer errors (INIT_B_HIST=222): Retrying it ...
Warning: High speed FPGA configuration failed, trying low speed mode:Error uploading bitstream: FPGA configuration failed: DONE pin does not go high, possible USB transfer errors (INIT_B_HIST=222): Trying low speed mode
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes got lost;  checksum=3 , should be 3;  INIT_B_HIST=222): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes got lost;  checksum=3 , should be 3;  INIT_B_HIST=222): Retrying it ...

I have noticed this before with the quads that went away with a power-cycle. any thoughts?

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: CA Coins on May 07, 2012, 04:49:07 AM

Quote

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?

Usually yes. This depends on the amount of CPU cores, the size of the cluster and the OS. It's probably not wise to run 200 threads on a single core Atom.

CA Coins

donator

Activity: 305

Merit: 250

Quote

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?

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: punin on May 06, 2012, 12:02:11 AM

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.

Quote

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.

punin

hero member

Activity: 560

Merit: 500

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?

CA Coins

donator

Activity: 305

Merit: 250

Anybody with experience going solo with BTCMiner?

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: pazor on April 30, 2012, 05:43:47 AM

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 (= *(1-)* ). This value is unfluenced by pool reachability and should converge to 1.

nelisky

legendary

Activity: 1540

Merit: 1002

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!

pazor

legendary

Activity: 966

Merit: 1000

Quote from: ztex on April 30, 2012, 05:27:07 AM

Quote from: pazor on April 30, 2012, 04:57:47 AM

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

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: punin on April 28, 2012, 03:35:12 PM

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.

ztex

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: pazor on April 30, 2012, 04:57:47 AM

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.

pazor

legendary

Activity: 966

Merit: 1000

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

donator

Activity: 367

Merit: 250

ZTEX FPGA Boards

Quote from: ztex on April 30, 2012, 03:53:29 AM

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.

Quote

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.

Quote

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.

CA Coins

donator

Activity: 305

Merit: 250

Quote from: punin on April 28, 2012, 08:05:36 PM

Quote from: CA Coins on April 28, 2012, 05:16:04 PM

@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.

punin

hero member

Activity: 560

Merit: 500

Quote from: CA Coins on April 28, 2012, 05:16:04 PM

@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

donator

Activity: 305

Merit: 250

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?

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