Bitcoin Forum
June 19, 2019, 12:10:48 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 »
241  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 12, 2012, 02:22:37 PM
Now I have to wait for eldentyrell to make progress to decide where my money goes next....

Send your money to the board-makers.  The more boards you have, the more money you stand to gain from the release of my design and therefore (hopefully) the more you will be willing to contribute.

Stay tuned on progress (I screwed up last night's build).

Are you planning to release Algorithmic bitstream for Icarus soon? I would like to be the first to donate for such bitstream!

no, you will not. i will the first!  Grin

Sorry Zhang, I will be the first!
Eldentyrell please send me your Bitcoin address, I will contribute today.
242  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 12, 2012, 01:26:54 PM
Now I have to wait for eldentyrell to make progress to decide where my money goes next....

Send your money to the board-makers.  The more boards you have, the more money you stand to gain from the release of my design and therefore (hopefully) the more you will be willing to contribute.

Stay tuned on progress (I screwed up last night's build).

Are you planning to release Algorithmic bitstream for Icarus soon? I would like to be the first to donate for such bitstream!
243  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 11, 2012, 03:39:46 AM
I've edited the Icarus Verilog code to be able to set the nonce while pushing new work to the device. Unfortunately, I am having hard time compiling the code! it always fails @ Place and Route! I also followed Zhang's advice "using smartexplorer", but still couldn't successfully compile the bitstream.

The major problem is that each compilation attempt takes at least 12 hours! Can someone help me by posting clearly defined steps for successfully compiling Icarus bitstreams?
Make sure you have enough memory. I found my compiles crashed (no error msg) due to lack of memory. I think 4 GB is enough but maybe more is better. 2GB definitely no-go.

I have 4GB
244  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 11, 2012, 02:59:21 AM
I've edited the Icarus Verilog code to be able to set the nonce while pushing new work to the device. Unfortunately, I am having hard time compiling the code! it always fails @ Place and Route! I also followed Zhang's advice "using smartexplorer", but still couldn't successfully compile the bitstream.

The major problem is that each compilation attempt takes at least 12 hours! Can someone help me by posting clearly defined steps for successfully compiling Icarus bitstreams?
245  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 10, 2012, 02:28:02 AM
Today I've uploaded the 200MHz bitstream on 6 boards. 4 boards got high % of invalid shares! and 2 boards had normal invalid rate "1 board got 0% and another 0.1%". I have the 6 boards divided on two towers, each has 3 boards. I found out that the 2 boards that got 0 and 0.1 invalids are the top ones! "room temp: ~22C".

If anyone is planning to upgrade to the 200 MHz bitstream without side fans, it is better not to have the boards on top of each other in a tower! and make sure there is enough space between each board!

I will re-test everything soon with side fans!

Roughly how much is "a high percentage"?

around 7%, 10%, 12%, and 3% in just few mints! I then reset those 4 boards to the 190MHz bitstream, and kept the top ones @200MHz. The top ones been mining for more than 12 hours with the same invalid rate almost 0%!

The first one and last one are running @200MHz

Invalid shares│Current│Average
 (K not zero) │MHash/s│MHash/s
      0 (0.0%)│ 400.03│ 393.83
      3 (0.1%)│ 379.83│ 365.15
      2 (0.1%)│ 379.88│ 380.07
      6 (0.2%)│ 380.18│ 374.18
      1 (0.0%)│ 379.79│ 376.41
      3 (0.1%)│ 399.92│ 399.31
246  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 10, 2012, 02:21:37 AM
Today I've uploaded the 200MHz bitstream on 6 boards. 4 boards got high % of invalid shares! and 2 boards had normal invalid rate "1 board got 0% and another 0.1%". I have the 6 boards divided on two towers, each has 3 boards. I found out that the 2 boards that got 0 and 0.1 invalids are the top ones! "room temp: ~22C".

If anyone is planning to upgrade to the 200 MHz bitstream without side fans, it is better not to have the boards on top of each other in a tower! and make sure there is enough space between each board!

I will re-test everything soon with side fans!

Roughly how much is "a high percentage"?

around 7%, 10%, 12%, and 3% in just few mints! I then reset those 4 boards to the 190MHz bitstream, and kept the top ones @200MHz. The top ones been mining for more than 12 hours with the same invalid rate almost 0%!
247  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 10, 2012, 02:07:19 AM
Today I've uploaded the 200MHz bitstream on 6 boards. 4 boards got high % of invalid shares! and 2 boards had normal invalid rate "1 board got 0% and another 0.1%". I have the 6 boards divided on two towers, each has 3 boards. I found out that the 2 boards that got 0 and 0.1 invalids are the top ones! "room temp: ~22C".

If anyone is planning to upgrade to the 200 MHz bitstream without side fans, it is better not to have the boards on top of each other in a tower! and make sure there is enough space between each board!

I will re-test everything soon with side fans!
248  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 09, 2012, 08:22:32 PM
Even if you could do it without horribly bad things happening Wink I doubt you would get any benefit from it.

Reason being the limiting factor right now isn't the clock speed of the chips, but the delay caused by the critical path. If the critical path takes 5ns, your max clock speed attainable will be 200Mhz. If your critical path takes 10ns, it's 100Mhz, and so on... The problem is that by doubling up on rising/falling edge, you're doing work twice per clock. So if it takes 10ns, you need 20ns of clearance because of the "double work" meaning that the same 5ns critical path delay that caused a 200Mhz cap before, will now cause a 100Mhz cap (or lower due to other inefficiencies). So you will AT BEST break even with performance, but more likely make it worse.

Thank you for your detailed answer!
249  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 09, 2012, 07:15:57 PM
I would be grateful if someone with good FPGA programming experience answers this question:

Is it possible to make use of both clock edges to improve the mining speed?

For example: replacing always@(posedge CLK) by always@(posedge CLK or negedge CLK)

Zhang've told me that this would lead to a disaster! I am still wondering if its possible to use a double edged clock design @ lower MHz "100->133"!
250  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 08, 2012, 07:41:31 PM
I am getting 0% invalid shares on 6 boards! I am using MPBM with jobinterval set to 11.3!

By the way I was wrong! the 11->11.3 range is as valuable as any 0.3 seconds within the 11.3 seconds range!
251  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 03, 2012, 06:11:21 AM
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.
252  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 03, 2012, 03:42:12 AM
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.

253  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 02, 2012, 11:42:42 AM
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
254  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 02, 2012, 04:28:37 AM
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%


255  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 01, 2012, 10: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!
256  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 01, 2012, 06: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!
257  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: March 01, 2012, 06: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?
258  Other / Off-topic / Re: Butterfly Labs - Bitforce Single and Rig Box on: February 28, 2012, 05:00:13 PM
@Energizer: We do test all the units for a minimum of 12 hours prior to shipping. This is our endurance test
that is done in a harsh environment to make sure the unit is stable and will not encounter any problem in its
lifetime.


Regards,


It would be great if you can find some time for answering our emails the same way you find time to respond here!

Its amazing how a single chinese engineer "ngzhang" manage to answer emails/design Icarus boards/develop software/test boards, and meet all his customers requirements in time "VIVA CHINA"!
259  Other / Off-topic / Re: Butterfly Labs - Bitforce Single and Rig Box on: February 28, 2012, 03:25:53 PM
I got an email back from Sonny the other day. He's saying late this week for my singles.

I run Mac. Wondering if cgminer will compile for me and support the singles?

@jddebug, when did you place that order? I'm guessing November or December? Would give us an idea of how far along BFL is with their backlog.  Undecided
Not jddebug, but hopefully helping clarification: I placed my order end of January and received wire transfer information the same day. Payment from Europe took about one week and Sonny confirmed receipt immediately, giving me a projected delivery date mid of March.

I also requested updated API specification and received it the same day. That's why I never got impatient with them. OTOH, that were the times when 90% of forum members bashed BFL as scammers and the amount of orders might have been low.

I placed my order in early January and paid via Paypal, and as of today I have received: Nothing. Nada. Zilch.
In other words, this is now the 8th week [of waiting], seven weeks have passed.

Same here! it is almost 9 weeks now! and I've received NOTHING! I accept such delay as long as there would be an overall improvement to performance/cooling! But what is making me so angry is that Sonny started to ignore my emails 2 weeks ago. He used to answer my emails immediately in the first month but now it takes him at least 1 week to respond!

We apologize for any delays you have encountered. The reason behind our silence is that we're working to ship all units
as fast as we can. Delivery has already started, yet not all the people who ordered are participating in this forum.
As a result, out of many that are shipped, a few will post comments here in BitcoinTalk.org.


Regards,


Yeah but more than just giga and luke jr. You are going to need about 10 members of this forum to post in the next 2 weeks for us to believe you did your first batch of 50.

Keep in mind we know you are selling a product with a chip that costs way more than your whole product retail.




I guess their real profit would be in mining! How? They would manage to always keep 300 to 500 devices mining 24/7 in their lab. If they are following such approach, this means that they wouldn't fully ship the first batch up until the second batch will be ready for mining/testing in their lab!
260  Bitcoin / Hardware / Re: FPGA development board "Icarus" - 3rd batch payment start. on: February 28, 2012, 01:38:34 PM
Please correct me if am wrong:

Currently, I am getting the best performance "MH/s" using Modular-Python-Bitcoin-Miner "better than cgminer".

https://github.com/TheSeven/Modular-Python-Bitcoin-Miner
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 »
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!