Bitcoin Forum
December 08, 2016, 12:20:35 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 »
  Print  
Author Topic: FPGA development board "Icarus" - DisContinued/ important announcement  (Read 184236 times)
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
March 02, 2012, 11:47:53 AM
 #541

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 !

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481199635
Hero Member
*
Offline Offline

Posts: 1481199635

View Profile Personal Message (Offline)

Ignore
1481199635
Reply with quote  #2

1481199635
Report to moderator
ngzhang
Hero Member
*****
Offline Offline

Activity: 592


We will stand and fight.


View Profile
March 02, 2012, 12:06:25 PM
 #542

 Cheesy




simple, rude, effective

CEO of Canaan-creative, Founder of Avalon project.
https://canaan.io/
Business contact: love@canaan.io
All PMs will be unread.
antirack
Hero Member
*****
Offline Offline

Activity: 491


Immersionist


View Profile
March 02, 2012, 12:55:00 PM
 #543

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
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
March 02, 2012, 11:01:36 PM
 #544

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)

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
fizzisist
Hero Member
*****
Offline Offline

Activity: 720



View Profile WWW
March 02, 2012, 11:15:41 PM
 #545

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
Sr. Member
****
Offline Offline

Activity: 274



View Profile
March 03, 2012, 03:42:12 AM
 #546

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
Hero Member
*****
Offline Offline

Activity: 592


We will stand and fight.


View Profile
March 03, 2012, 05:50:53 AM
 #547

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.

CEO of Canaan-creative, Founder of Avalon project.
https://canaan.io/
Business contact: love@canaan.io
All PMs will be unread.
Energizer
Sr. Member
****
Offline Offline

Activity: 274



View Profile
March 03, 2012, 06:11:21 AM
 #548

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
Hero Member
*****
Offline Offline

Activity: 592


We will stand and fight.


View Profile
March 03, 2012, 06:36:56 AM
 #549

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

CEO of Canaan-creative, Founder of Avalon project.
https://canaan.io/
Business contact: love@canaan.io
All PMs will be unread.
DeepBit
Donator
Hero Member
*
Offline Offline

Activity: 532


We have cookies


View Profile WWW
March 03, 2012, 08:23:51 AM
 #550

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.

Welcome to my bitcoin mining pool: https://deepbit.net ~ 3600 GH/s, Both payment schemes, instant payout, no invalid blocks !
Coming soon: ICBIT Trading platform
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 03, 2012, 09:21:51 AM
 #551

Finally got my 2 Icarus to work after messing around with cgminer Smiley
(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.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
pieppiep
Sr. Member
****
Offline Offline

Activity: 402



View Profile
March 03, 2012, 10:07:38 AM
 #552

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 Smiley
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 03, 2012, 10:18:51 AM
 #553

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
March 03, 2012, 04:36:57 PM
 #554

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  Wink

ngzhang
Hero Member
*****
Offline Offline

Activity: 592


We will stand and fight.


View Profile
March 03, 2012, 05:01:13 PM
 #555

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.

CEO of Canaan-creative, Founder of Avalon project.
https://canaan.io/
Business contact: love@canaan.io
All PMs will be unread.
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
March 03, 2012, 07:04:08 PM
 #556

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  Grin Wink a costume is something you can wear.

ngzhang
Hero Member
*****
Offline Offline

Activity: 592


We will stand and fight.


View Profile
March 03, 2012, 07:12:59 PM
 #557

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  Grin Wink a costume is something you can wear.

i love and hate automatic spell checking. Embarrassed

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

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


CEO of Canaan-creative, Founder of Avalon project.
https://canaan.io/
Business contact: love@canaan.io
All PMs will be unread.
allinvain
Legendary
*
Offline Offline

Activity: 2002



View Profile
March 03, 2012, 07:27:33 PM
 #558

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  Grin Wink a costume is something you can wear.

i love and hate automatic spell checking. Embarrassed

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

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
Legendary
*
Offline Offline

Activity: 1470


View Profile
March 03, 2012, 07:45:06 PM
 #559

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

iCEBREAKER is a troll! He and cypherdoc helped HashFast scam 50 Million $ from its customers !
H/w Hosting Directory & Reputation - https://bitcointalk.org/index.php?topic=622998.0
rudrigorc2
Legendary
*
Offline Offline

Activity: 1064



View Profile
March 04, 2012, 03:28:56 AM
 #560

I wonder if this is going to work with Raspberry Pi  ARM device... it would be very nice.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!