FPGA development board "Icarus" - DisContinued/ important announcement

[Turbor]

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 !

[1714321795]

1714321795

[1714321795]

1714321795

[ngzhang]

 




simple, rude, effective

[antirack]

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

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.

[TheSeven]

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%

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)

[fizzisist]

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!

[Energizer]

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.

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.

[ngzhang]

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.

[Energizer]

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.

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.

[ngzhang]

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

[DeepBit]

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

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.

[kano]

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

Code:

 cgminer version 2.3.1g - Started: [2012-03-03 19:09:54]
--------------------------------------------------------------------------------
 (5s):1634.6 (avg):1420.8 Mh/s | Q:2091  A:1361  R:8  HW:0  E:65%  U:20.71/m
 TQ: 4  ST: 17  SS: 6  DW: 51  NB: 7  LW: 0  GF: 6  RF: 0
 Connected to http://miku.net:8332 with LP as user luka@rin
 Block: 000001f8776bc874851f45e273806c36...  Started: [19:54:42]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  76.0C 3333RPM | 358.7/355.3Mh/s | A:317 R:0 HW:0 U: 4.82/m I: 9
 GPU 1:  68.5C 2897RPM | 367.5/362.2Mh/s | A:349 R:0 HW:0 U: 5.31/m I: 9
 ICA 2: 527.1/347.8Mh/s | A:332 R:5 HW:0 U: 5.05/m
 ICA 3: 504.8/357.1Mh/s | A:363 R:3 HW:0 U: 5.52/m
--------------------------------------------------------------------------------

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.

[pieppiep]

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.

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

[kano]

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

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)

[Turbor]

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 

[ngzhang]

i want to take this opportunity to talk about international delivery.

most of country are fine to pass with a lower value declared invoice. except: Germany, Italy, Brazil.

Germany: take a long time in the costume, and complex negotiate.
Brazil: no chance to negotiate, just return the package (after 1-2  month delay ).
Italy: the post man told me about it.

by this 3 country, i find air mail parcel more easily pass their customs. but with a slower speed compared to EMS. and the weight can not over 2KG.

[Turbor]

i want to take this opportunity to talk about international delivery.

most of country are fine to pass with a lower value declared invoice. except: Germany, Italy, Brazil.

Germany: take a long time in the costume, and complex negotiate.
Brazil: no chance to negotiate, just return the package (after 1-2  month delay ).
Italy: the post man told me about it.

by this 3 country, i find air mail parcel more easily pass their costumes. but with a slower speed compared to EMS. and the weight can not over 2KG.

It's customs Zhang, not costume   a costume is something you can wear.

[ngzhang]

i want to take this opportunity to talk about international delivery.

most of country are fine to pass with a lower value declared invoice. except: Germany, Italy, Brazil.

Germany: take a long time in the costume, and complex negotiate.
Brazil: no chance to negotiate, just return the package (after 1-2  month delay ).
Italy: the post man told me about it.

by this 3 country, i find air mail parcel more easily pass their costumes. but with a slower speed compared to EMS. and the weight can not over 2KG.

It's customs Zhang, not costume   a costume is something you can wear.

i love and hate automatic spell checking.

and:

we Chinese study English from 10 years old. until i'm a PH.d, there are also some English course.

but my English level is dogshit. 

before i come to this forum, i can not write a complete sentence. but i passed all English test in my life.

[allinvain]

i want to take this opportunity to talk about international delivery.

most of country are fine to pass with a lower value declared invoice. except: Germany, Italy, Brazil.

Germany: take a long time in the costume, and complex negotiate.
Brazil: no chance to negotiate, just return the package (after 1-2  month delay ).
Italy: the post man told me about it.

by this 3 country, i find air mail parcel more easily pass their costumes. but with a slower speed compared to EMS. and the weight can not over 2KG.

It's customs Zhang, not costume   a costume is something you can wear.

i love and hate automatic spell checking.

and:

we Chinese study English from 10 years old. until i'm a PH.d, there are also some English course.

but my English level is dogshit. 

before i come to this forum, i can not write a complete sentence. but i passed all English test in my life.

Don't worry, we understand you for the most part.

Lol..dogshit.

Well, I think it's hard to master the language if you don't use it on a nearly daily basis.

[RoadStress]

ngzhang do you plan to improve the current design or it will stay like this until next gen chips are available?

[rudrigorc2]

I wonder if this is going to work with Raspberry Pi  ARM device... it would be very nice.