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.
Topic: FPGA development board "Icarus" - DisContinued/ important announcement - page 24. (Read 207288 times)
March 01, 2012, 09:07:26 PM
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.
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. March 01, 2012, 09:04:48 PM
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.
March 01, 2012, 08:59:11 PM
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.
Quote from: ngzhang
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.
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.
March 01, 2012, 08:48:25 PM
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?
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?
March 01, 2012, 05:09:24 PM
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!
March 01, 2012, 04:22:31 PM
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.
March 01, 2012, 04:07:36 PM
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?
March 01, 2012, 01:37:32 PM
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!
March 01, 2012, 07:55:43 AM
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.
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.
March 01, 2012, 06:13:35 AM
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).
March 01, 2012, 05:38:46 AM
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?
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.
March 01, 2012, 04:04:04 AM
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))
March 01, 2012, 02:42:21 AM
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.
March 01, 2012, 01:00:59 AM
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?
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?
February 29, 2012, 06:36:22 PM
In Thailand it's like this: If a motorbike rider ignores a stop sign and is therefore injured or killed by a "farang" (foreigner) driving a car, the "farang" is automatically at fault, because if the car hadn't been there, the accident wouldn't have happened.
Is is similar in China, or is it a little bit more rational?
---
On another note: For the first time ever there was presence of China-based security vendors at this year's RSA conference. For years and years, Germany had a huge pavilion for several vendors from Germany, and this year as a first, China had the same thing.
Specifically, the pavilion was rented by "Beijing Zhongguancun Overseas Science Park" and subdivided among several vendors.
Wow, that's just wrong. By farang do they mean a white dude or any person without Thai nationality?
On a different note: Ngzhang, do you have any extra boards? I am contemplating upgrading my pre-order :p
February 29, 2012, 06:08:31 PM
(here if you kill a person in a car accident, you should compensate for about 100,000$. )
Regardless of FAULT?
In Thailand it's like this: If a motorbike rider ignores a stop sign and is therefore injured or killed by a "farang" (foreigner) driving a car, the "farang" is automatically at fault, because if the car hadn't been there, the accident wouldn't have happened.
Is is similar in China, or is it a little bit more rational?
---
On another note: For the first time ever there was presence of China-based security vendors at this year's RSA conference. For years and years, Germany had a huge pavilion for several vendors from Germany, and this year as a first, China had the same thing.
Specifically, the pavilion was rented by "Beijing Zhongguancun Overseas Science Park" and subdivided among several vendors.
February 29, 2012, 06:51:06 AM
ok,
next 300 chips arrived, i send them to the factory today. the planed complete date is 3/6. the test will cost another 4 days. so the planed delivery date is around 3/10-11.
tonight i will contact with next half pre-ordered customers.
the chips maybe about 1-2KG weight include package, and the value is much more than 30,000$.
(here if you kill a person in a car accident, you should compensate for about 100,000$. )
next 300 chips arrived, i send them to the factory today. the planed complete date is 3/6. the test will cost another 4 days. so the planed delivery date is around 3/10-11.
tonight i will contact with next half pre-ordered customers.
the chips maybe about 1-2KG weight include package, and the value is much more than 30,000$.
(here if you kill a person in a car accident, you should compensate for about 100,000$. )
February 28, 2012, 06:15:54 PM
I see. I think I fall into the "small order" category. I did send you a formal pre-order request a while back and you responded as having received and confirmed it.
The main question here is if someone writes you an e-mail with a pre-order request or wants to get in on a batch I presume you actually write/store their info/request, no? lol otherwise having to go through e-mails will result in lost orders and lost customers. I'm not questioning your organizational skills, I just am curious to know _what_ they're like
The main question here is if someone writes you an e-mail with a pre-order request or wants to get in on a batch I presume you actually write/store their info/request, no? lol
otherwise having to go through e-mails will result in lost orders and lost customers. I'm not questioning your organizational skills, I just am curious to know _what_ they're like i actually feel your displeased, and i must say that's all my fault.
EDIT
and: small order is in a higher priority.
EDIT
i write down all pre-order emails, and will give the payment information by the time sequence. you know, i never withdraw when there are no boards in my hands, at least they must pass the preliminary test. i already dispose of half pre-orders, and send them out. next i will deal with another half, after that, if any one pre-ordered but didn't get my respond, i will ask here and process them immediately, by my reserved boards.
this will be totally finished in 9 days.
Well I will be displeased if I do not get the board that I pre-ordered lol :p Check your e-mails. Hint: I ordered form a gmail address that has my forum handle in it - ie "allinvain" .
I really hope I don't miss out on this batch.
February 28, 2012, 05:57:32 PM
I'm thinking maybe the problem is that we need to help him out by getting distribution channels set up. I *just* formed an LLC earlier this month for my mining, but I'm wondering if maybe I should instead be working to get bulk orders done to the US, then reselling them to interested parties?
Biggest problem is I'm in the Midwest, so shipping here isn't exactly cheap. What about MemoryDealers? They usually seem to be okay with working with other people in the Bitcoin world, maybe they'd be a better outfit to handle the shipping?
Biggest problem is I'm in the Midwest, so shipping here isn't exactly cheap. What about MemoryDealers? They usually seem to be okay with working with other people in the Bitcoin world, maybe they'd be a better outfit to handle the shipping?
Get in touch with the folks over at "Bit-Pay". They are set up 3 blocks form me, so I wouldn't have to pay shipping fees again.
February 28, 2012, 01:49:42 PM
I'm thinking maybe the problem is that we need to help him out by getting distribution channels set up. I *just* formed an LLC earlier this month for my mining, but I'm wondering if maybe I should instead be working to get bulk orders done to the US, then reselling them to interested parties?
Biggest problem is I'm in the Midwest, so shipping here isn't exactly cheap. What about MemoryDealers? They usually seem to be okay with working with other people in the Bitcoin world, maybe they'd be a better outfit to handle the shipping?
Biggest problem is I'm in the Midwest, so shipping here isn't exactly cheap. What about MemoryDealers? They usually seem to be okay with working with other people in the Bitcoin world, maybe they'd be a better outfit to handle the shipping?
Jump to: