Topic: FPGA development board "Icarus" - DisContinued/ important announcement - page 23. (Read 207288 times)

Received my Icarus board today. Took less than one week from China to Switzerland. Running RG7Miner now at around 360 to 380 MH/s. So far so good 

What cgminer does it gets work before it is needed.
So when Icarus says it needs more work, some is already there.
So yeah I guess basically what you were thinking.

However, I think the timing of that may need some adjustment for Icarus so that it's timed right.
The way around that is also to increase the work queue size with -Q n
I'll need to work out the best values for that also but 4 seems good if the pool doesn't handle RollNTime
(I'll have to work out what effect RollNTime has on the queue value)

The chance to find a share in the 11->11.3 seconds range is the same as find one in the 0->0.3 or 5.5->5.8 or anywhere for 0.3 seconds.


I think people are talking about different meanings for the term efficiency.
There is an efficiency where you want to find as many shares possible per jobs. You want to set the interval large enough so the job is completed in that time.
There is an efficiency where you want to find as many shares possible per time. You want the FPGA have new work before it completes the current job.

If you set the interval between jobs to low the first one drops, thats a higher load for the pool.
If you set the interval between jobs to high the second one drops, the FPGA has nothing to do.

If I had a FPGA miner I would try to set the interval to the time it takes to complete a job minus the maximum time it takes to get a new job.
That way I know the FPGA has new work to do on time and the pool don't get to high load.

But, I don't have any real world experience, so I can ofcourse be wrong somewhere. It's just my software engeneer point of view

Finally got my 2 Icarus to work after messing around with cgminer
(I had too many options available that messed it up ...)

Firstly a screen shot showing 2x6950 + 2xIcarus
At the moment, the code still needs a little tuning for the Icarus

Regarding the comments above about efficency:
Yep as DeepBit said, it's not really that big a performance hit.
What actually happens with cgminer in the current settings (which I will change soon) is that it simply starts a new nonce range every 8 seconds if it hasn't already found a share
If it has found a share, it starts a new range then.
You don't lose anything except the overhead of starting more nonce ranges.
This simply means that you are doing more setup work for the same amount of hashes (thus Icarus processing time lost there) but nothing more.

What the new code will be doing is actually calculating that perfect finish time (minus some small %) based on the history of shares found (for a given time interval in the past)
i.e. the time to find a particular share nonce is in very basic terms T = S + Xn
where T is the time it took to find it, S is some setup overhead and 'n' is the (nonce number & 0x7fffffff)+1 that was found
The numbers to be adjusted/determined over time are the S setup overhead, and X being the time to process 2 nonce

What I'll use that for is to adjust the expected run time to get it closer to the full nonce finish time (minus some small %)
This is relevant since all hardware will run at slightly different speeds over time and just assuming 11.3s will of course not always be correct either ... a later revision of the Icarus code may get that number higher on the same hardware.

Looks like they use the word "efficiency" meaning "shares per one getwork" which is mostly useless in sane intervals.
It only affects work reloading pauses and pool load.

Lower interval "lower than 11" = more jobs with no shares = more jobs in equal time =  equal efficiency.

The job will be done in 11.3 seconds. So maximum interval is 11.3 seconds. Shares are rarely found in the 11->11.3 seconds range. The more you decrease the interval "lower than 11" the lower efficiency you will get.

Lower interval "lower than 11" = more jobs with no shares = lower efficiency.

due to my poor english, i just sum up.

the job job interval  will not effect the efficiency obviously by any value lower than 11.3S.


the efficiency test at least need a week time. not 10 or 100 shares.

Its not really ~25% more shares in 30% more time. But its more like getting ~25% more shares in less than 5% more time! How?

Lets say ~20% of the jobs will contain no shares, so these are the only jobs that will take 30% more time "while increasing the interval by 30%". So its not really 30% more time but 30% more time for only 20% of the jobs = 6% more time!

Lets say ~80% of jobs will contain shares, 25% of which should be found in more than 8 seconds. So setting the interval to 8 seconds will result in reducing the possibility of finding shares in a job by 25%; so only ~60% of the jobs will contain shares!

So by setting the interval to 11.3 seconds "better 10.9" you will be investing 6% more time to increase the possibility of finding shares in jobs by 30% "~25% higher efficiency"! and probably thats the main reason why my speed @ pool remains in range(380,480) MH/s.

Ok, I have email notifications for this thread, but I hate not seeing it in my "new replies" so I'm subbing. I gotta keep an eye on our competition!

So, in your example, when you set 8 seconds, you have mined 23% less shares in 30% less time, than when you set 11.3 seconds. So you get 10% more efficiency with the 8 second setting, compared to 11.3 seconds, and that's plain luck.
If you measure this during a longer time frame (let's say 100k shares), you'll see that the share distribution across time is almost linear between 0 and 10 seconds. 11 seconds will be much lower, and there shouldn't be any shares beyond 12 seconds.
Conclusion: The optimum interval is 11.3 seconds. At 8 seconds, you'll get 0.0203% less efficiency on average, which is negligible. At 1 second, you would get 0.507% less efficiency on average.
However, at 11.4 seconds, you'll already get 0.878% less efficiency, so that would already be worse than 1 second. At 12 seconds it would already be 5.83% less efficiency. And because there's always some risk that the requested sleep time is being exceeded for various reasons (OS threading behavior, internal latencies in MPBM, USB bus latencies, ...), I decided to add some safety margin into the other direction, which hurts way less.

Also, the hashrate reported by pools varies greatly because it highly depends on share luck. It should however correspond somewhat to the efficiency value shown in MPBM. Average it out across a couple of weeks, and it's very unlikely that you exceed 380MH/s, regardly of your work interval setting. The current bitstream just can't do more than that.



based on this formula: efficiency = min(seconds, 4294967296/380000000) / (640/115200 + seconds)

It's pointing at abcpool.co now with 10.9, but honestly it's not much different. ~1940 MH/s at the pool and 1885 in the miner, efficiency 98%. Average hashrate of boards 377ish mh/s.

 




simple, rude, effective

My experiences with ztex d boards have shown that wind straight from the side helps a lot. I'd go with variant two. Going to do the same thing with my icarus. A 92mm fan should be perfect. Be quiet ftw !

If the board gets hot it could be that the heatsink is lose or not making contact the way it should. If this is the case it gets very hot. I know this from experience !

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

double post.

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

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%

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


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


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

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.