FPGA development board "Icarus" - DisContinued/ important announcement

[Energizer]

You've mentioned before that job submission to the Icarus device should be in 12 seconds intervals. However the modular python bitcoin miner is submitting jobs in around 7.85 seconds intervals!

I have just edited the MPBM interval to 15 seconds to watch what would be the highest time taken to find a valid share in a job, and I found that the highest is around 12 seconds! and some jobs would return 2 shares!

What would happen if I submit jobs is intervals lower than 12 seconds? that means that valid shares that would be found in 12 seconds will be lost?

Submitting a new job to Icarus will result in overwriting the old one? will that result in messing up the current job process? for example: a collision between the old job and the newly submitted one, thus corrupting both jobs?

[randomguy7]

What would happen if I submit jobs is intervals lower than 12 seconds? that means that valid shares that would be found in 12 seconds will be lost?

They will be lost but it doesn't matter because in the time you would spend searching the complete range, you could as well find valid shares in the next job. Note that not every job will lead to valid shares.

[antirack]

I have just edited the MPBM interval to 15 seconds to watch what would be the highest time taken to find a valid share in a job, and I found that the highest is around 12 seconds! and some jobs would return 2 shares!

Are you talking about this (icarus.py, line 183):

Code:

        # Calculate the time that the device will need to process 2**32 nonces.
        # This is limited at 30 seconds so that new transactions can be included into the block
        # by the work source. (Requirement of the bitcoin protocol and enforced by most pools.)
        interval = min(30, 2**32 / 1000000. / self.mhps)
        # Add some safety margin and take user's interval setting (if present) into account.
        self.jobinterval = min(self.jobinterval, max(0.5, interval * 0.8 - 1))

[ngzhang]

You've mentioned before that job submission to the Icarus device should be in 12 seconds intervals. However the modular python bitcoin miner is submitting jobs in around 7.85 seconds intervals!

I have just edited the MPBM interval to 15 seconds to watch what would be the highest time taken to find a valid share in a job, and I found that the highest is around 12 seconds! and some jobs would return 2 shares!

What would happen if I submit jobs is intervals lower than 12 seconds? that means that valid shares that would be found in 12 seconds will be lost?

Submitting a new job to Icarus will result in overwriting the old one? will that result in messing up the current job process? for example: a collision between the old job and the newly submitted one, thus corrupting both jobs?

you know, it is a equal opportunity to find a valid share in a work.
so, push work faster will not influence the work efficiency.
you can increase the job interval to a time no more than 11.xxx seconds, if longer, FPGA will IDLE.

[TheSeven]

you can increase the job interval to a time no more than 11.xxx seconds, if longer, FPGA will IDLE.

11.30 seconds, to be exact.
MPBM adds a 20% + 1 second safety margin to that, to make sure that the 11.3 seconds are never exceeded, even if it is currently very busy and has trouble to push data around fast enough. It should end up pushing new work to the FPGA every 8.042 seconds plus some internal latencies.

Pushing work to the FPGA more often than every 11.3 seconds has three adverse effects:

• It puts (proportionally) more load on the mining pool server (up to 40% in this case)
• It increases network traffic (by up to 40% in this case)
• It increases the amount of time that the FPGA is calculating garbage because new work is currently being uploaded (also by up to 40%, but the wasted time because of that is still about 0.066% of the total running time at maximum).

Getting rid of this, without risking that the FPGA might run idle if there's a little congestion or something else on the machine is taking away CPU time in the wrong moment, would require a bitstream/firmware chainge (adding a work queue on the FPGA side).

[ngzhang]

orders processed to 2/8

any one pre-ordered before 2/8 but didn't received my payment mail, please re-send a mail to me. i maybe miss you.

[Energizer]

I have just edited the MPBM interval to 15 seconds to watch what would be the highest time taken to find a valid share in a job, and I found that the highest is around 12 seconds! and some jobs would return 2 shares!

Are you talking about this (icarus.py, line 183):

Code:

        # Calculate the time that the device will need to process 2**32 nonces.
        # This is limited at 30 seconds so that new transactions can be included into the block
        # by the work source. (Requirement of the bitcoin protocol and enforced by most pools.)
        interval = min(30, 2**32 / 1000000. / self.mhps)
        # Add some safety margin and take user's interval setting (if present) into account.
        self.jobinterval = min(self.jobinterval, max(0.5, interval * 0.8 - 1))

Yes!
you can set self.jobinterval here!

[RoadStress]

http://www.enterpoint.co.uk/shop/en/93-xc6slx150-x2-coprocessor.html
http://enterpoint.co.uk/wp-content/uploads/2011/10/XC6SLX150_X2_COPROCESSOR_USER_MANUAL_ISSUE_1_0.pdf


Thanks

What would someone need to mine on those boards?

[this time]

http://www.enterpoint.co.uk/shop/en/93-xc6slx150-x2-coprocessor.html
http://enterpoint.co.uk/wp-content/uploads/2011/10/XC6SLX150_X2_COPROCESSOR_USER_MANUAL_ISSUE_1_0.pdf


Thanks

What would someone need to mine on those boards?

You'd need another board with usb to host it. Also it would probably have power problems mining just from looking at it.

[Energizer]

I have just edited the MPBM interval to 15 seconds to watch what would be the highest time taken to find a valid share in a job, and I found that the highest is around 12 seconds! and some jobs would return 2 shares!

Are you talking about this (icarus.py, line 183):

Code:

        # Calculate the time that the device will need to process 2**32 nonces.
        # This is limited at 30 seconds so that new transactions can be included into the block
        # by the work source. (Requirement of the bitcoin protocol and enforced by most pools.)
        interval = min(30, 2**32 / 1000000. / self.mhps)
        # Add some safety margin and take user's interval setting (if present) into account.
        self.jobinterval = min(self.jobinterval, max(0.5, interval * 0.8 - 1))

Yes!
you can set self.jobinterval here!

I am getting better performance "~430 MH/s" by setting self.jobinterval to 10.3!

[antirack]

I have the 3rd batch units with pre-installed bitstream and I do about 370-380 MH/s on all units (once in a while I get a negative average MHash with MPBM on one of my 5 Icarus units). 

It's been like this for one day on slush (300ms ping) on one day on EclipseMC (200ms ping). Have you installed another bitstream for 430+ MH/s? Changing self.jobinterval to 10.3 didn't make a difference for me. Is that what your miner displays, or what the pool displays?

[antirack]

My test setup looks exactly like this. I had it running for a couple of days with room temperatures of about 22C. Today the weather changed and the thermometer on the desk next to the Icarus boards says is around 27C (25C actually after a while with the Icarus OFF).

When I touch the boards under the FPGAs I can't keep my finger there for 3 seconds. Especially the lowest Icarus board is much hotter than the others. I have an infrared thermometer but I can only measure at an angle not straight down on the PCB. The lowest unit has double the temperature of the upper ones. This might be because it doesn't get any airflow from a unit sitting below it.

I have switched my boards off for now and will think about some additional airflow for the complete tower.

ADD@1/28

some proposal of heat control.

the boards and standard cooling system is tested under the ambient temperature of 23 centigrade. if your temp is over 30 centigrade, an additional cooling is recommended. an airflow pass the whole board is a good choice.

notice the power module is very heatproof, but the FPGA will generate error data when they reach a high temperature. a simple method to sense if the temperature is touch the back side of the PCB, just under the FPGA chip. notice before do this you need a electro static discharge.
if you can not hold your finger at  the back side of the FPGA for 3 seconds. then a additional cooling is needed.
the FPGA chip uses whole PCB for heat dissipation, so an airflow passing the PCB is more important than the fan above the heat-sink.

[allinvain]

I have just edited the MPBM interval to 15 seconds to watch what would be the highest time taken to find a valid share in a job, and I found that the highest is around 12 seconds! and some jobs would return 2 shares!

Are you talking about this (icarus.py, line 183):

Code:

        # Calculate the time that the device will need to process 2**32 nonces.
        # This is limited at 30 seconds so that new transactions can be included into the block
        # by the work source. (Requirement of the bitcoin protocol and enforced by most pools.)
        interval = min(30, 2**32 / 1000000. / self.mhps)
        # Add some safety margin and take user's interval setting (if present) into account.
        self.jobinterval = min(self.jobinterval, max(0.5, interval * 0.8 - 1))

Yes!
you can set self.jobinterval here!

I am getting better performance "~430 MH/s" by setting self.jobinterval to 10.3!

That could be a bug in the miner. MPBM has some weird bugs. For example if a long string of failed connections to the pool happen the hashrate and efficiency can go in negative territory.

[allinvain]

Where are you guys finding those long metal stand-offs? I'd like to build a similar setup.

As for the backside of the PCB running hot, I think I have an idea. I was thinking one can attach some sort of mesh 2 cm or more underneath the PCB and put a fan there Then you just repeat for the next one and voila - cool Icarus backside.

[antirack]

Where are you guys finding those long metal stand-offs? I'd like to build a similar setup.

As for the backside of the PCB running hot, I think I have an idea. I was thinking one can attach some sort of mesh 2 cm or more underneath the PCB and put a fan there Then you just repeat for the next one and voila - cool Icarus backside.

In electronics components stores. Also saw it on eBay:

http://www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem&item=130626750145&ssPageName=ADME:X:AAQ:US:1123

As for cooling the underside, I think it's much easier to just use some bigger fan to introduce airflow over all boards just like ngzhang suggests. Or put them all in a good ventilated area (ie. under the aircon in the office at an angle that the air is forced between the boards and doesn't blow at the PCB directly). In a larger setup, I can imagine a shelf with plenty of Icarus or FPGA miners, and fans on the side so that the air constantly moves through the shelf and takes the heat away. Basically just like a server case would work.

[ngzhang]

 
by my test, even no fan, the boards also can operate with a 1% invalid rate.
so, don't worry.

orders processed to 2/8

any one pre-ordered before 2/8 but didn't received my payment mail, please re-send a mail to me. i maybe miss you.

ngzhang,

How do your boards compare with

http://www.enterpoint.co.uk/shop/en/93-xc6slx150-x2-coprocessor.html
http://enterpoint.co.uk/wp-content/uploads/2011/10/XC6SLX150_X2_COPROCESSOR_USER_MANUAL_ISSUE_1_0.pdf


Thanks

i think the power module is not power enough for mining.

A Micrel MIC22950 regulator supplies 1.2V with a maximum current available of
10A. This is used for the core voltage of the FPGAs.

5A /each FPGA. so .....

[Energizer]

I have the 3rd batch units with pre-installed bitstream and I do about 370-380 MH/s on all units (once in a while I get a negative average MHash with MPBM on one of my 5 Icarus units). 

It's been like this for one day on slush (300ms ping) on one day on EclipseMC (200ms ping). Have you installed another bitstream for 430+ MH/s? Changing self.jobinterval to 10.3 didn't make a difference for me. Is that what your miner displays, or what the pool displays?

Miner displays "370/390" and pool displays "380/490". The point is by setting jobinterval to 10.3 seconds the miner speed remains almost the same but the efficiency will get higher! Higher efficiency means finding more shares in the same number of jobs. Finding more shares will reflect on your speed @ pool.

Increasing the jobinterval "in range(8,11)" will indeed post your minner efficiency, but this comes with a price, as your miner will spend more time mining jobs that doesn't contain shares. If you have high "ms ping to your pool" I suggest increasing the interval by at least one second "self.jobinterval +=1".

While setting my miner jobinterval to 11.3, I've collected this data for 100 shares:

{0: 16, 1: 13, 2: 7, 3: 7, 4: 7, 5: 9, 6: 8, 7: 10, 8: 6, 9: 8, 10: 8, 11: 1}

As you can see 16 shares been found in less than 1 second "0:16", and 8 shares been found in 10.xxx seconds "10:8". Currently by default MPBM jobinterval is around 8 seconds, so you are lossing these shares: {8: 6, 9: 8, 10: 8, 11: 1} = 6+8+8+1 = 23 shares ~25%

[antirack]

Some temporary cooling. I am just wondering how I best blow on the boards for effective cooling. At an angle with the legs on one side longer (as in the second picture) or straight (last image).

They are 220-240V fans with a power consumption of around 15W each. I used every last one of my power sockets. And it's just temporary.

Maybe I am just that sensitive, or it is still too hot. Can't keep my finger under the FPGA for 3 seconds. Infrared thermometer says 50C-60C (It was $40 definitely not one of the high end ones, here).

[antirack]

double post.

[Energizer]

double post.

Thats so cool!

Try jobinterval 10.9 @ abcpool.co

With such setting the speed "pool side" should keep moving between 370 to 480 MH/s