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

[BR0KK]

had that when i was trying my Rpi for a Miner Computer .... I was connected to it via SSH. After a little while (a day of mining) the SSH Connection broke down (randomly)...

[ztex]

Code:

Warning (try 1): error sending control message: Broken pipe

Any idea what is causing errors like this? They are not showing up in the logs as far as I can tell, just on the screen. Sometimes quite often. However, it doesn't exit and it seems to mine without problems.

That are USB errors. The ZTEX API retries it and if another attempt work no error is printed in the log.

[BR0KK]

im getting alot of these since yesterday:

Code:

Summary:
  Bus bus-0-0   : 10 miners
  Bus bus-0-1   : 7 miners
  Total         : 17 miners


Disconnect all devices or enter `q' for exit. Enter `h' for help.

bus-0-1: ztex_ufm1_15y1-04A3461185-4: Using LongPolling URL http://eu.eclipsemc.com:8337/LP
bus-0-0: ztex_ufm1_15y1-04A34644C6-3: Warning: Rejected block: high-hash
bus-0-1: ztex_ufm1_15y1-04A3461185-2: Warning: Rejected block: high-hash
bus-0-0: ztex_ufm1_15d4-04A32E1205-1: 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_15d4-04A3468E00-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 3 new nonces,  luckFactor=1,08
bus-0-0: ztex_ufm1_15d4-04A3469756-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 3 new nonces,  luckFactor=1,08
bus-0-0: ztex_ufm1_15d4-04A346D523-1: 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_15d4-04A346E12C-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 2 new nonces,  luckFactor=0,72
bus-0-0: ztex_ufm1_15y1-04A34644C6-1: 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_15y1-04A34644C6-2: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 3 new nonces,  luckFactor=1,08
bus-0-0: ztex_ufm1_15y1-04A34644C6-3: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 3 new nonces,  luckFactor=1,08
bus-0-0: ztex_ufm1_15y1-04A34644C6-4: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 2 new nonces,  luckFactor=0,72
bus-0-0: ztex_ufm1_15y1-04A36E24F2-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 3 new nonces,  luckFactor=1,08
bus-0-1: ztex_ufm1_15y1-04A3461185-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 2 new nonces,  luckFactor=0,72
bus-0-1: ztex_ufm1_15y1-04A3461185-2: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 6 new nonces,  luckFactor=2,15
bus-0-1: ztex_ufm1_15y1-04A3461185-3: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 1 new nonces,  luckFactor=0,36
bus-0-1: ztex_ufm1_15y1-04A3461185-4: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 5 new nonces,  luckFactor=1,79
bus-0-1: ztex_ufm1_15y1-04A36E24F2-2: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 7 new nonces,  luckFactor=2,51
bus-0-1: ztex_ufm1_15y1-04A36E24F2-3: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 1 new nonces,  luckFactor=0,36
bus-0-1: ztex_ufm1_15y1-04A36E24F2-4: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 4 new nonces,  luckFactor=1,43
bus-0-0: poll loop time: 124ms (USB: 42ms network: 82ms)   getwork time: 211ms  submit time: 212ms
bus-0-1: poll loop time: 114ms (USB: 46ms network: 68ms)   getwork time: 220ms  submit time: 207ms
Total hash rate: 3400,0 MH/s
Total submitted hash rate: 3432,7 MH/s
 --------
bus-0-0: ztex_ufm1_15y1-04A34644C6-3: Warning: Rejected block: high-hash
bus-0-1: ztex_ufm1_15y1-04A3461185-1: Warning: Rejected block: high-hash
bus-0-1: ztex_ufm1_15y1-04A3461185-2: Warning: Rejected block: high-hash
bus-0-0: ztex_ufm1_15y1-04A34644C6-2: Warning: Rejected block: high-hash
......

im at EMC Pool and inaba (the pool operator) changed the way shares are accepted. They are >1 Diff?

[ztex]

Code:

bus-0-0: ztex_ufm1_15y1-04A34644C6-3: Warning: Rejected block: high-hash
bus-0-1: ztex_ufm1_15y1-04A3461185-1: Warning: Rejected block: high-hash
bus-0-1: ztex_ufm1_15y1-04A3461185-2: Warning: Rejected block: high-hash
bus-0-0: ztex_ufm1_15y1-04A34644C6-2: Warning: Rejected block: high-hash
......

im at EMC Pool and inaba (the pool operator) changed the way shares are accepted. They are >1 Diff?

Ask the pool operator what this message means.  If it is caused by a to low difficulty it can be ignored.

[BR0KK]

Looks to me like that software does not support > difficulty 1 shares. 

Thats his answer ?

[BR0KK]

Looks to me like that software does not support > difficulty 1 shares. 

Thats his answer ?

and i'm facing massive USB Connection errors out of no reason (i cant think of one, since it worked flawless for several month now).

My Setup:
A Windows 7 VM on a MAX OSX Mountain Lion Host ( Since i'm totally unable to get BTC miner < or anything else that can mine with OSX> working natively on MAC)

A 7 Port USB Hub.
A Silex SWX2000W+ device Server (All boards connected to this device server)

It worked realy good for at least 4 month now .... All of a sudden, after a small Software update and a brief restart of my MAC all my board are facing massive USB Connection errors ....

If i connect them to the device server or directly to my mac they wont be stable at all. After some time <in the clocking phase or while mining for hours with no problem> they randomly shut down with libusb connection errors.


--> Im buying a video card tomorrow .... need to ged rid of the MAC / VM solution.

[randomguy7]

Looks to me like that software does not support > difficulty 1 shares. 

Thats his answer ?

and i'm facing massive USB Connection errors out of no reason (i cant think of one, since it worked flawless for several month now).

My Setup:
A Windows 7 VM on a MAX OSX Mountain Lion Host ( Since i'm totally unable to get BTC miner < or anything else that can mine with OSX> working natively on MAC)

A 7 Port USB Hub.
A Silex SWX2000W+ device Server (All boards connected to this device server)

It worked realy good for at least 4 month now .... All of a sudden, after a small Software update and a brief restart of my MAC all my board are facing massive USB Connection errors ....

If i connect them to the device server or directly to my mac they wont be stable at all. After some time <in the clocking phase or while mining for hours with no problem> they randomly shut down with libusb connection errors.


--> Im buying a video card tomorrow .... need to ged rid of the MAC / VM solution.

Does it help when you pull the power plugs from the boards and then plug them in again (while keeping the usb cables connected!)?

[BR0KK]

Code:

ztex_ufm1_15y1-04A36E24F2-4: Set frequency to 200,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-4: added
2 new devices found.

Summary:
  Bus bus-0-0   : 5 miners
  Total         : 5 miners


Disconnect all devices or enter `q' for exit. Enter `h' for help.

bus-0-0: ztex_ufm1_15y1-04A36E24F2-4: Using LongPolling URL http://127.0.0.1:9332/long-polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
Warning (try 1): libusb0-dll:err [control_msg] sending control message failed, win error: Ein an das System angeschlossenes GerΣt funktioniert nicht.


New block detected by long polling
New block detected by long polling
bus-0-0: ztex_ufm1_15d4-04A32E1205-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 4 new nonces,  luckFactor=1,43
bus-0-0: ztex_ufm1_15y1-04A36E24F2-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 3 new nonces,  luckFactor=1,08
bus-0-0: ztex_ufm1_15y1-04A36E24F2-2: 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_15y1-04A36E24F2-3: 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_15y1-04A36E24F2-4: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 6 new nonces,  luckFactor=2,15
bus-0-0: poll loop time: 57ms (USB: 57ms network: 0ms)   getwork time: 1ms  submit time: 1ms
Total hash rate: 1000,0 MH/s
Total submitted hash rate: 1071,3 MH/s
 --------
New block detected by long polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
bus-0-0: ztex_ufm1_15d4-04A32E1205-1: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-2: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-1: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-3: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-4: Set frequency from 200,00MHz to 204,00MHz
Warning (try 1): libusb0-dll:err [control_msg] sending control message failed, win error: Ein an das System angeschlossenes GerΣt funktioniert nicht.


New block detected by long polling
New block detected by long polling
New block detected by long polling
Warning (try 1): libusb0-dll:err [control_msg] sending control message failed, win error: Ein an das System angeschlossenes GerΣt funktioniert nicht.


New block detected by long polling

i dont need to reset the boards.  they are just dying one by one.
Sometines a Single FPGA and then two to four. (all randomly x and y boards).


I Checked the HUPS and the Cables ... everything is at least bought from "good quality" vendors (Hubs are from Belkin and trust) cables are shielded etc...


I'm thinking about buying a small Netbook or a router (i have tried TPlink but ddnt succeed ...) that's going to be my miner ...
 

[ztex]

Code:

ztex_ufm1_15y1-04A36E24F2-4: Set frequency to 200,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-4: added
2 new devices found.

Summary:
  Bus bus-0-0   : 5 miners
  Total         : 5 miners


Disconnect all devices or enter `q' for exit. Enter `h' for help.

bus-0-0: ztex_ufm1_15y1-04A36E24F2-4: Using LongPolling URL http://127.0.0.1:9332/long-polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
Warning (try 1): libusb0-dll:err [control_msg] sending control message failed, win error: Ein an das System angeschlossenes GerΣt funktioniert nicht.


New block detected by long polling
New block detected by long polling
bus-0-0: ztex_ufm1_15d4-04A32E1205-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 4 new nonces,  luckFactor=1,43
bus-0-0: ztex_ufm1_15y1-04A36E24F2-1: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 3 new nonces,  luckFactor=1,08
bus-0-0: ztex_ufm1_15y1-04A36E24F2-2: 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_15y1-04A36E24F2-3: 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_15y1-04A36E24F2-4: f=200,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=200,0MH/s,  submitted 6 new nonces,  luckFactor=2,15
bus-0-0: poll loop time: 57ms (USB: 57ms network: 0ms)   getwork time: 1ms  submit time: 1ms
Total hash rate: 1000,0 MH/s
Total submitted hash rate: 1071,3 MH/s
 --------
New block detected by long polling
New block detected by long polling
New block detected by long polling
New block detected by long polling
bus-0-0: ztex_ufm1_15d4-04A32E1205-1: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-2: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-1: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-3: Set frequency from 200,00MHz to 204,00MHz
bus-0-0: ztex_ufm1_15y1-04A36E24F2-4: Set frequency from 200,00MHz to 204,00MHz
Warning (try 1): libusb0-dll:err [control_msg] sending control message failed, win error: Ein an das System angeschlossenes GerΣt funktioniert nicht.


New block detected by long polling
New block detected by long polling
New block detected by long polling
Warning (try 1): libusb0-dll:err [control_msg] sending control message failed, win error: Ein an das System angeschlossenes GerΣt funktioniert nicht.


New block detected by long polling

i dont need to reset the boards.  they are just dying one by one.
Sometines a Single FPGA and then two to four. (all randomly x and y boards).


I Checked the HUPS and the Cables ... everything is at least bought from "good quality" vendors (Hubs are from Belkin and trust) cables are shielded etc...


I'm thinking about buying a small Netbook or a router (i have tried TPlink but ddnt succeed ...) that's going to be my miner ...
 

Check the PSU. They often die slowly / become unstable over time if they run permanently  at high temperatures (liquid electrolytic capacitors).

[ztex]

Looks to me like that software does not support > difficulty 1 shares. 

Thats his answer ?

If Inaba means that BTCminer does not support difficulty >1 checking he is right. This is obsolete because it is done by the bitcoin server / pool.

Maybe I will add this on the next release.
 
You can ignore these warnings.

[BR0KK]

Thx for the answer ill try other power supplies.

[slush]

If Inaba means that BTCminer does not support difficulty >1 checking he is right. This is obsolete because it is done by the bitcoin server / pool.

You probably cannot be more wrong with this. All pools were working with diff1 shares for almost two years, but with rising hashrates of miners, submitting diff1 shares is wasting of resources - too much traffic and pool load for no reason. So all modern pools are slowly implementing dynamic difficulty for their workers. Submitting low-diff shares to the pool may be considered as a flooding and may be a reason for ban.

Please add checking difficulty for next release, it is literally five lines of code.

[BR0KK]

changed the power supplies.

and now im testing if it works ....

i really do have to make some connectors for my pc power supply. Couldn't be that hard to do it myself?

[rupy]

I'm still getting (not your fault):

001-0: ztex_ufm1_15d4-04A346E2B9-1: Error: connect timed out: Disabling URL http://pit.deepbit.net:8332 for 30s

But after a few of these in a row the whole cluster shuts down (problem with BTCMiner)!?

[BR0KK]

it should switch to your backup pool, if you enabled one in your config?

@Ztex
Yes my power supplies died ore wer slowly dying. After six month of contious mining.
 

[rupy]

How do you enable backup pool with BTCMiner?

EDIT: Nevermind found it! '-b host name pass'...

[Turbor]

How do you enable backup pool with BTCMiner?

-b http://us2.eclipsemc.com:8337 Turbor_XXXX XXXXXX

Turbor_XXXX is your worker and XXXXXX your password

[antirack]

Check the PSU. They often die slowly / become unstable over time if they run permanently  at high temperatures (liquid electrolytic capacitors).

What effect does a dying or unstable PSU have? Dropping voltage, interruptions, anything else?

[ztex]

If Inaba means that BTCminer does not support difficulty >1 checking he is right. This is obsolete because it is done by the bitcoin server / pool.

You probably cannot be more wrong with this. All pools were working with diff1 shares for almost two years, but with rising hashrates of miners, submitting diff1 shares is wasting of resources - too much traffic and pool load for no reason. So all modern pools are slowly implementing dynamic difficulty for their workers. Submitting low-diff shares to the pool may be considered as a flooding and may be a reason for ban.

Please add checking difficulty for next release, it is literally five lines of code.

At difficulty=1 the get-work frequency is approximately twice as high as the submit-work frequency. I hope this is not considered as flooding too.

[ztex]

Check the PSU. They often die slowly / become unstable over time if they run permanently  at high temperatures (liquid electrolytic capacitors).

What effect does a dying or unstable PSU have? Dropping voltage, interruptions, anything else?

Liquid electrolytic capacitors loose their capacity over the time if they run permanently at high temperatures.  This causes voltage drops or interruptions at the load step after configuration. Possible effects are:

* Full loss of configuration ==> bitstream upload errors
* Partial loss of configuration ==> FPGA delivers wrong results ==> dowclocking
* device disappears from the USB if PSU interrupts (e.g. due to undervoltage or overload protection)

The same effects occur is PSU is to weak or output capacitance of PSU us to small.