Bitcoin Forum
December 04, 2016, 12:25:16 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 »  All
  Print  
Author Topic: Bounty[PAID OUT] : a bitstream for better utilizing the Cairnsmore1 157-294.5btc  (Read 20197 times)
Cranky4u
Hero Member
*****
Offline Offline

Activity: 770



View Profile WWW
August 03, 2012, 06:09:13 AM
 #161

ok...after 18 hours of testing, well short of the 48 hours I hoped for, here is my 190 bit stream findings;

System - Win 7 64bit, cgminer 2.6.1 + phatk, cm1 #62-0432 & #63-0433
Average hash rate per cm1 = ~725MHs at pool & via cgminer Note: neither board is reaching the bounty threshold of 750MHs
Average U = 17.5~17.8/m
HW & R are very low. HW = 0 & R <5
Maximum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 14 hours
Minimum run time between failures (resulting in need for system reset to recover e.g BSD or non-responsive) - 0.5 hours
Average restarts of cgminer before both boards detect successfully - 3
Identified conflicts - use of 2nd 6770 GPU for mining causes system to BSD on start up of cgiminer or intedpendent start of of phoenix miner when cgminer is FPGA only. Note: Can mine on 1st 6770 GPU though.

I hope this helps developers...
Tweakers, any idea on how to tweak to get up to 750MHs and improve stability?

What are your per worker U values? U=17.5 on 2 boards looks like 1 fpga isn't hashing which is a common issue with that bitstream.
running as pr above but on + poclbm gives (approx)
ICA 0: 360/360    U: 4.30/m
ICA 1: 355/360    U: 4.15/m
ICA 2: 355/355    U: 2.05/m
ICA 3: 360/360    U: 6.75/m

overall U: 17.3/m

hint? is ICA2 not flashed properly despite VM saying it was a success?

1480854316
Hero Member
*
Offline Offline

Posts: 1480854316

View Profile Personal Message (Offline)

Ignore
1480854316
Reply with quote  #2

1480854316
Report to moderator
1480854316
Hero Member
*
Offline Offline

Posts: 1480854316

View Profile Personal Message (Offline)

Ignore
1480854316
Reply with quote  #2

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

Posts: 1480854316

View Profile Personal Message (Offline)

Ignore
1480854316
Reply with quote  #2

1480854316
Report to moderator
1480854316
Hero Member
*
Offline Offline

Posts: 1480854316

View Profile Personal Message (Offline)

Ignore
1480854316
Reply with quote  #2

1480854316
Report to moderator
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
August 03, 2012, 07:48:03 AM
 #162

Hi,

I've sent my second 10 BTCs bounty part.

https://blockchain.info/tx-index/14400138/b6f539f3d23fe868d1e204f88c8e91f417435134b62bd64f79ffbc3844c5ab88

spiccioli
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 03, 2012, 11:11:48 AM
 #163

running as pr above but on + poclbm gives (approx)
ICA 0: 360/360    U: 4.30/m
ICA 1: 355/360    U: 4.15/m
ICA 2: 355/355    U: 2.05/m
ICA 3: 360/360    U: 6.75/m

overall U: 17.3/m

hint? is ICA2 not flashed properly despite VM saying it was a success?
It probably did flash properly, it's just that one of the FPGAs on ICA 2 has frozen. Probably FPGA1, that always seems to be the one that falls over first on ebereon's boards.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Cranky4u
Hero Member
*****
Offline Offline

Activity: 770



View Profile WWW
August 03, 2012, 11:33:00 AM
 #164

so after some time...I stabilise around the U: 5/m ICA line in cgminer...is this right for the 190MHs bitstream?  basically what sort of rate should I be getting? My pool is reporting about 1200~1400MHs for 2 * CM1 190bit flashed systems

ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 03, 2012, 12:28:47 PM
 #165

Multiply U with 71.5827883 to get the MH/s.

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
August 03, 2012, 04:27:40 PM
 #166

@ cranky4u

I've got 2 boards and 1 of my boards does that. The other mines full throttle.
Reflashing sometimes helps. I am 50/50 on if it's a hardware or bitstream issue.

I do figure however since one works perfectly it atleast has a chance of being fixed by an improved bitstream.


Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
Cranky4u
Hero Member
*****
Offline Offline

Activity: 770



View Profile WWW
August 04, 2012, 05:46:48 AM
 #167

ok..so I have finally deduced what functions the cm1 board lights represent and no, I didn't find it in any enterpoint instruction manual.

FPGA on standby or idle (not mining)
Orange, constant - standby

FPGA mining
Green, flash - found a successful result
Orange, flash - normally with green flash, mining
Orange, constant - FPGA not responding  ---shit itself or controller not communicating with it

I have p1 on 62- 0433 presenting a constant orange during mining so I assume it is playing up...will reflash 190MHs bitstream tonight and report back

Cranky4u
Hero Member
*****
Offline Offline

Activity: 770



View Profile WWW
August 04, 2012, 07:42:03 AM
 #168

ny1 know if I can run different bitstreams in each FPGA..eg p0,p2,p3 = 190MHs bitstream whilst p1=180MHs

thinking of this as p1 is unstable and keeps shitting itself. NOTE: "Shitting itself" is a professional engineers term for fucking up or crashing

Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
August 04, 2012, 01:46:25 PM
 #169

To be exact, the LED meanings in the "standard icarus" bitstreams (such as makomk's current 190oc release for example) are:
0 - Found a Share (flashes, then fades out)
1 - RX (FPGA received data on the serial port)
2 - TX (FPGA sending data on serial port)
3 - Idle (this lights when the FPGA has no current work to do)

The colors in order are:
0 - Green
1 - Red
2 - Blue
3 - Amber

Those functions are static (ie: they don't change depending on what "mode" the fpga is in).

For the HashVoodoo bitstream (Still not working right as of yet) the LED meanings are:
0 - Found a Share (flashes, then fades out)
1 - Clock Heartbeat (flashes on a heavily divided clock signal to indicate the FPGA is getting a good clock signal and hasn't locked up)
2 - Serial Activity (blinks on transmit or receive on the serial port)
3 - Idle (lights when the FPGA has no current work to do.

It should be noted that on both bitstreams currently the serial rx/tx LEDs light so fast typically you hardly notice them (if at all). I intend to add a (faster) version of the "fader" code from the share found LED code to the serial activity LED, to stretch out the blink duration some, to allow it to be more obvious when the FPGA is communicating.

To answer your question about multiple bitstreams:

In theory that should work fine. The comm clock, and hashing clock are different clock domains, so the communications code should keep on working just fine, while the hash clock can be at different rates. It may end up resulting in the entire nonce range being missed sometimes though (ie the 190 is in "front" and 180 in "back" the 190 starts the job, and forwards half it's nonce range to the 180 bitstream, but the 190 will finish before the 180 has finished, resulting in a small percentage of the second half of the nonce range being "skipped"). I don't think that will hurt overall hashrate, but it might skew some of the other stats slightly. Ultimately the impact should be nearly nothing.

Hope that helps Smiley

Also a quick status update on HashVoodoo development:

The first test bitstream using LVDS clock signalling was completed, but we're still having communications issues. So I'm now doing some debugging of the comms stuff.

The good news is that the LVDS clocks seem to be stable in all 4 slots, even on my 0001 serial number board! So I think if we can solve the comms issues, we're really onto something with this one!

Please note, I don't reccomend installing this bitstream just yet, (the .bit isn't released) because it's not quite working right. Once I get it hashing on my end, I'll release the full binary bitstream for you all to test out. I don't want to cause more headaches by releasing a malfunctioning bitstream (and I've encountered some wierdness on the jtag lines now, so I want to rule out the bitstream as a cause. The last thing I want to do is release an update that breaks your usb updating ability).

I'll post more when I have it.

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
Cranky4u
Hero Member
*****
Offline Offline

Activity: 770



View Profile WWW
August 04, 2012, 11:00:03 PM
 #170

Glasswalker...thank you for that great update!

steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 08, 2012, 05:11:15 PM
 #171

the escrow held by Zefir is now up to 185 btc. lets go glasswalker/makomk/mystery genius, we need more MH/s!

ASIC miners available for purchase

Those who serve best, profit most.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 08, 2012, 05:57:22 PM
 #172

Right now I'm mostly waiting to hear how Glasswalker's latest bitstream will turn out. It sounds really promising, touch wood.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
August 08, 2012, 08:11:22 PM
 #173

Right now I'm mostly waiting to hear how Glasswalker's latest bitstream will turn out. It sounds really promising, touch wood.

Well I closed timing (175Mhz target, with about 1us to spare) this morning. Unfortunately the build was missing termination on the LVDS clock lines. So that will hurt overall performance. When I get home I'll run that through fpgaeditor and see if I can correct it and do a bitgen from that. Then I'll test that out.

Also I'll try to get the controller fixed so USB programming isn't broken. Then we can get the .bit for the current source code released so everyone can try it out.

If we can get this thing up to 200Mhash, and reliable on all the boards, then I'll shift my focus back to the HashVoodoo core, to replace the ztex/icarus core I'm using now. Which will shift us to a "sea of hashers" style approach.

Anyway I got super busy this past week roughly, so haven't been able to spend as much time on it. Luckily I had a like 5 day long smartxplorer build going, so I wasn't wasting time completely.

Also FYI: the current source code on github is what I've done the current build based on.

If this works (even marginally) then the next step is to backport any of makomk's tweaks into this bitstream, and a few other fixes/adjustments I've thought up. Then provided we can get roughly 200Mhash out of this one, I'll leave it there.

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
Isokivi
Hero Member
*****
Offline Offline

Activity: 924


Items flashing here available at btctrinkets.com


View Profile WWW
August 13, 2012, 06:00:42 PM
 #174

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

Im seeing an average speed of 800Mhs reported at poolside, one troublesome core-pair is pooping out an invalid rate of 3,15%. but it seems like we have a winner, I dont have a long enough test-run yet, but there should be no uptime-issues to be expected.

If you want your word in on wether or not this qualify's for the bounty: the time to act is now, test it, call out about missing or insufficient documentation, do something.

Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 13, 2012, 06:05:46 PM
 #175

I will start testing the 200 MH/s bitstream on my SN 26 board tomorrow.

Review of the Spondoolies-Tech SP10 „Dawson“ Bitcoin miner (1.4 TH/s)

[22:35] <Vinnie_win> Did anyone get paid yet? | [22:36] <Isokivi> pirate did!
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
August 13, 2012, 06:12:42 PM
 #176

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

Im seeing an average speed of 800Mhs reported at poolside, one troublesome core-pair is pooping out an invalid rate of 3,15%. but it seems like we have a winner, I dont have a long enough test-run yet, but there should be no uptime-issues to be expected.

If you want your word in on wether or not this qualify's for the bounty: the time to act is now, test it, call out about missing or insufficient documentation, do something.

I'm running it now on 9 boards. will tell you in 24 hours how it looks.

update:
after 2 hours cgminer shows 6942 total, 771 per , pool shows 6761, 751 per , 99.9% accepted on both.

22 hour update: cgminer shows 6839 total, 759.8 per, pool shows almost exactly the same, 99.98% accepted on both.

ASIC miners available for purchase

Those who serve best, profit most.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 13, 2012, 08:21:50 PM
 #177

The 200Mhs bitstream in this pack seems like a winner. I need more ppl testing it, input on wether or not the documentation is as required.
http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z

I should note that whilst I have released the source corresponding to those bitstreams, there are no instructions to build similar bitstreams from the source because you can't do so trivially. That source is actually back-modified to match several direct edits I made to the compiled .ncd in FPGA Editor - you can download that from http://www.makomk.com/~aidan/shortfin_dcmwd4c_ed_ncd.7z if you want to poke about yourself. You should be able to get fairly close by pointing Smart Guide to that ncd (unzip it, right-click fpgaminer_top in the Hierarchy pane in ISE, choose Smart Guide and point it at the NCD, then click the green Implement arrow in the toolbar) but that dents performance by several tens of MHz. You'll also need to run mkrelease.sh which executes some FPGA Editor scripts that are needed to get the bitstreams to run.

(Honestly, if you want to do development the halffin-dev branch in my git repository is much nicer to work with, it just doesn't quite have the same performance yet. Or there's Glasswalker's stuff, which is quite nice too.)

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Isokivi
Hero Member
*****
Offline Offline

Activity: 924


Items flashing here available at btctrinkets.com


View Profile WWW
August 15, 2012, 01:32:37 PM
 #178

As far as my boards are concerned the latest 200Mhs bitstream takes the bounty. I have been hearing about issues with pre #50 boards,but Im fairly sore most or all of us can agree that that has got to be a hardware issue.

Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 15, 2012, 03:27:47 PM
 #179

My boards (62-0110 and 62-0111) aren't happy yet :

This is with the 190 version in the same batch after 1 hour on cgminer 2.6.4 with --icarus short:
Code:
ICA 0:                | 377.5/375.7Mh/s | A:304 R:3 HW:0 U: 5.19/m
ICA 1:                | 377.3/375.2Mh/s | A: 21 R:0 HW:0 U: 0.36/m
ICA 2:                | 379.3/374.2Mh/s | A:318 R:1 HW:0 U: 5.43/m
ICA 3:                | 384.8/410.8Mh/s | A:213 R:2 HW:0 U: 3.64/m

ICA 1 and ICA 3 are linked to the third ttyUSB interfaces of each cairnsmore 1 board on my systems (the latest udev rules published on the forum are quite nice) :
ICA1: /dev/cm-62-0111-if02
ICA3: /dev/cm-62-0110-if02

From what I can tell (orange LED often on), these are the interfaces linked to the 1st and 2nd FPGA on each board. The #62-111 board has indeed both FPGA 1 and 2 orange leds on most of the time. I can see the FPGA 2 orange LED on #62-111 quite often too.

I had a run with 190 on all FPGAs except FPGA 1 where i put the 160 bitstream from the same batch on each board.
Here is the result after 6 hours :
60-110-if02: 3,84
60-110-if03: 5,03
60-111-if02: 3,44
60-111-if03: 5,05

My main problem is that results are quite inconsistent and most of the time hard to get: the tty interfaces vanish often and unpredictably. Some days I have to reset boards by removing power/USB half a dozen times.

My problem might be that I can't update the controller and still use the 1.1 firmware on it but I don't have any solution for it (no Windows license here).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
August 15, 2012, 03:56:10 PM
 #180

My boards (62-0110 and 62-0111) aren't happy yet :

This is with the 190 version in the same batch after 1 hour on cgminer 2.6.4 with --icarus short:
Code:
ICA 0:                | 377.5/375.7Mh/s | A:304 R:3 HW:0 U: 5.19/m
ICA 1:                | 377.3/375.2Mh/s | A: 21 R:0 HW:0 U: 0.36/m
ICA 2:                | 379.3/374.2Mh/s | A:318 R:1 HW:0 U: 5.43/m
ICA 3:                | 384.8/410.8Mh/s | A:213 R:2 HW:0 U: 3.64/m

ICA 1 and ICA 3 are linked to the third ttyUSB interfaces of each cairnsmore 1 board on my systems (the latest udev rules published on the forum are quite nice) :
ICA1: /dev/cm-62-0111-if02
ICA3: /dev/cm-62-0110-if02

From what I can tell (orange LED often on), these are the interfaces linked to the 1st and 2nd FPGA on each board. The #62-111 board has indeed both FPGA 1 and 2 orange leds on most of the time. I can see the FPGA 2 orange LED on #62-111 quite often too.

I had a run with 190 on all FPGAs except FPGA 1 where i put the 160 bitstream from the same batch on each board.
Here is the result after 6 hours :
60-110-if02: 3,84
60-110-if03: 5,03
60-111-if02: 3,44
60-111-if03: 5,05

My main problem is that results are quite inconsistent and most of the time hard to get: the tty interfaces vanish often and unpredictably. Some days I have to reset boards by removing power/USB half a dozen times.

My problem might be that I can't update the controller and still use the 1.1 firmware on it but I don't have any solution for it (no Windows license here).

I would just try and download a copy of Windows 7 install it without a key, you get 30 Days trial, or borrow someones Win7 Cd and load it from that. That way you could at least get to 1.3, or 1.4 now. You don’t actually need to own the copy just get it installed and use it for 30 days.
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 »  All
  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!