Bitcoin Forum
December 11, 2016, 02:31:42 AM *
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 ... 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 [95] 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251460 times)
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
August 11, 2012, 07:52:46 AM
 #1881

I've only got 2 boards, so don't expect 10 to react the same, but ubuntu and windows do react abit differently to a boards and their tty/com ports.
In ubuntu the order they are plugged in usually chooses their number, lowest first. In windows generally it remembers the one that board had last time.

So the first plugged in will always get 0/1/2/3 and the second always 4/5/6/7.

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

Posts: 1481423502

View Profile Personal Message (Offline)

Ignore
1481423502
Reply with quote  #2

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

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 11, 2012, 07:54:07 AM
 #1882

...
my biggest 'problem' was not mapping ICAn to ttyUSBn, but ttyUSBn to the 'correct' board (I have ten of them) so that, for example, I can flash a slower bitstream to the pair with too many errors.

spiccioli
Yep, I was just adding the extra bit on the end after that in case anyone wanted to know Smiley
The mapping (ICAn -> /dev/...) is simple - since cgminer knows it and you can ask it.
Also note that if any /dev/... fails to be detected properly, the ICAn number will not increment past it i.e. there won't be a gap
So the ICAn numbers can change if there are any detection problems

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

Activity: 686


View Profile
August 11, 2012, 03:34:03 PM
 #1883

What on the board knows to turn the yellow LED on when the FPGA is waiting on work?  And if it knows to turn that on, why can't it send a request for more work?
It could do, but none of the existing mining software would understand the request. In theory you could (for instance) have the miner send a nonce of zero, which is never returned by the Icarus miner as a genuine nonce, when it reaches the end of the current work and then modify mining software to understand this.

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

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 11, 2012, 04:24:36 PM
 #1884

What on the board knows to turn the yellow LED on when the FPGA is waiting on work?  And if it knows to turn that on, why can't it send a request for more work?
It could do, but none of the existing mining software would understand the request. In theory you could (for instance) have the miner send a nonce of zero, which is never returned by the Icarus miner as a genuine nonce, when it reaches the end of the current work and then modify mining software to understand this.

The current software adds minor complexity to handle the fact that the Icarus bitstream DOESN'T send a completion reply.
It must decide when to abort the work before it is idle, but making it ~99% means fewer requests for work
Sending a completion reply would of course be easier to handle.

There are, however, 2 estimates for the Icarus bitstream:
1) When to abort work (and thus how much work was done if it doesn't find a share before that)
2) How much work was done when the work is aborted due to an LP

Adding a completion message removes the estimate for 1) but not 2)

A reply to an abort saying how much work was done at the time of the abort would also be required to perfect the MH/s calculation (though the estimate is highly accurate now anyway for a normal Icarus and can be made accurate with --icarus-timing for any other Icarus bitstream FPGA)

Interestingly enough, the way that Icarus returns a share and stops is actually the current best method of mining.

The only way to improve it would be for the Icarus to also continue working on the rest of the nonce range - thus the code would keep requesting a reply and keep getting nonce's until it got a 'finished' reply.

Nonce-range processing is good if you have to wait for the processing to complete, but the Icarus method is better.

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

Activity: 1376

nec sine labore


View Profile
August 11, 2012, 05:14:01 PM
 #1885

OK, with a bit of help from ebereon running lots of SmartXplorer runs, the following should apparently hit 200 MHz on the pairs that couldn't manage it before: http://www.makomk.com/~aidan/shortfin-eb-20120809.zip Unfortunately, it doesn't have a functioning DCM watchdog, so you have to watch out for pairs falling over. Apparently ebereon has managed to get all of his FPGAs running reasonably stably at 200 MHz by combining this with the dcmwd2 ones. A good starting guess would probably be 200 MHz http://www.makomk.com/~aidan/shortfin-dcmwd-20120808.zip on FPGA0/1, 200MHz shortfin-eb on 2/3, switch to shortfin-eb if you have too many invalids on 0/1, switch to dcmwd if the U/m of 2/3 drops off spectacularly after a few hours (should be 5+, if it's 2 to low 4s something's up), fall back to 190MHz dcmwd if either of those still doesn't work reliably.

makomk,

are you going to build a version which has the dcm watchdog again or is the dcm watchdog a problem when trying to reach higher hashrates?

spiccioli
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
August 11, 2012, 06:19:08 PM
 #1886

makomk,

are you going to build a version which has the dcm watchdog again or is the dcm watchdog a problem when trying to reach higher hashrates?

spiccioli
I am, it's just that was built with an older non-functional version of the DCM watchdog and I ran into a whole bunch of irritating technical issues when trying to merge the newer version in. http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z should have the higher potential hashrates and the DCM watchdog, with a bit of luck it should reach 200+ MHz on most boards. I'm seeing some really weird behaviour from the 210 MHz bitstream though - it's consistently getting a lower U/m than it should on one half of my test board (about 5.3ish when it should be closer to 5.86).

Note that I'm trying out a new archive format with this set of bitstreams to reduce the download size. You may need to download 7-Zip to unpack them if you don't have any other unarchiving software installed that can open .7z files; it's of course free, open source and adware-free and all that good stuff. Linux users should install p7zip instead. (The new archive plus the 7-Zip installer still comes in at a quarter the download size of using ZIP, so it's a definite saving.) Try starting off with the 200 MHz bitstream.

Hope this works. Donations to 1CCorPPK8X6Px5iNxCBc5Eciw81iZPVBPh are welcome as always.

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

Activity: 24


View Profile
August 11, 2012, 10:05:53 PM
 #1887

http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z should have the higher potential hashrates and the DCM watchdog, with a bit of luck it should reach 200+ MHz on most boards.

Are these DCM bitstreams also suitable for pre #0050 boards? (I tested the shortfin_dcmwd2_test_200_overclock.bit some days ago and it didn't seem to be hashing very stable on my #0005 board)

Currently the best bitstream for my board seems to be the shortfin_icarus_cm1_test_190_overclock.bit, closely followed by shortfin_eb_test_210_overclock.bit, but that last one isn't stable (1 Icarus device stops performing work after some time)
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 11, 2012, 11:51:12 PM
 #1888

...
Maybe so, but as you say, not processing the complete range is a bug.

I can't be bothered to make a complete proof, but it's demonstrable that terminating after finding a share lowers overall utility.

If valid solutions are independent and have a uniform probability, failing to complete the range will miss clusters of valid shares.  A nonce range will have an integer number of valid shares - 0, 1, 2, 3 etc.  Binomial theorem would allow you to calculate the expected distribution of valid shares per range.  In any range with 2 or higher solutions, terminating after the first one will lower the ultimate utility of the system and, effectively the 'luck' of the miner.  

Actually the net effect would be distribution dependent.  If % of nonce ranges with only 1 solution exceeds the % of ranges with 2-99 solutions, you are better off moving to the next range.  (I chose 99 as an arbitrarily large number where the probability of having that many solutions in a range becomes vanishingly small)
No, sorry, it doesn't reduce U due to probability.
(and no it's not a bug)

It only reduces MH/s due to processing more work to do the same number of hashes
Having a slightly lower MH/s will of course also mean a slightly lower U - though the difference is very small.

The distance from one share to the next is random and independent of the work being done
i.e. you can look at it this the simple way: every hash done has an equal chance of being a share.
So it doesn't matter if you do 10% of each nonce range, or 90% of each nonce range, over time the average expected number of 1 difficulty shares will converge to 1 in each 2^32 hashes, no matter where they come from
(as long as they are not duplicates of course Tongue)

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

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
August 12, 2012, 09:44:32 AM
 #1889

Going to give the 210 Bitstream a go today. Great work Makomk.

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

Activity: 106


View Profile
August 12, 2012, 06:20:31 PM
 #1890

I just flashed shortfin_dcmwd4c_ed_test_200_overclock.bit and it seems to be a definitive improvement over shortfin_dcmwd2_test_190_overclock.bit @ board #62-0017.
If this runs stable for a day or two, I probably should cancel my RMA request.
Thank you makomk.

shortfin_dcmwd2_test_190_overclock.bit:


shortfin_dcmwd4c_ed_test_200_overclock.bit:
ShadesOfMarble
Donator
Hero Member
*
Offline Offline

Activity: 543



View Profile
August 12, 2012, 07:27:42 PM
 #1891

@hm please keep us updated.

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!
hm
Member
**
Offline Offline

Activity: 106


View Profile
August 12, 2012, 08:29:52 PM
 #1892

shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:


the drop was caused by a cgminer crash.



perhaps i should flash 190mh bitstream to fpga2/3 to get better U/m results on ICA 1.
Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
August 12, 2012, 09:16:32 PM
 #1893

2.6.3 has a bug that makes it segfault after a certain amount of time, 2.6.4 doesn't have that bug in it.
hm
Member
**
Offline Offline

Activity: 106


View Profile
August 12, 2012, 09:49:34 PM
 #1894

thank you Doff, updated to 2.6.4.

edit: 1h15m running cgminer 2.6.4, shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:
Code:
cgminer version 2.6.4 - Started: [2012-08-12 23:47:49]
--------------------------------------------------------------------------------
 (15s):344.2 (avg):792.5 Mh/s | Q:236  A:834  R:4  HW:0  E:353%  U:10.4/m
 TQ: 0  ST: 4  SS: 0  DW: 50  NB: 14  LW: 1601  GF: 0  RF: 0
 Connected to http://mining.eligius.st:8337 with LP as user
 Block: 000004a396dc614ecfd9419f9a7f0dd9...  Started: [01:07:34]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 398.8/397.4Mh/s | A:456 R:2 HW:0 U:5.67/m
 ICA 1:                | 398.6/397.8Mh/s | A:379 R:2 HW:0 U:4.71/m
--------------------------------------------------------------------------------

 [2012-08-13 01:05:17] Accepted 9135665a.5f85ee88 ICA 0
 [2012-08-13 01:05:34] Accepted ba914994.b8bd0df3 ICA 1
 [2012-08-13 01:05:35] Accepted be1cf531.aa60e9a9 ICA 0
 [2012-08-13 01:05:41] Accepted 75836e8b.04df23e9 ICA 1
 [2012-08-13 01:05:47] Accepted a6aa3caf.d5f50486 ICA 0
 [2012-08-13 01:05:48] Accepted ff0f5fe5.27d88c89 ICA 0
 [2012-08-13 01:05:50] Accepted c2235c3e.8fd2d100 ICA 0
 [2012-08-13 01:05:50] Accepted 08d131d0.4629ffef ICA 0
 [2012-08-13 01:05:51] Accepted 6084d797.7a355cf2 ICA 1
 [2012-08-13 01:06:19] Accepted 5083cfc3.374f42cd ICA 0
 [2012-08-13 01:06:19] Accepted bab5e764.5d3716ff ICA 1



power consumption of the psu is just below 46W, using an usb cable with disabled power line.
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
August 13, 2012, 09:04:29 AM
 #1895

Going to give the 210 Bitstream a go today. Great work Makomk.

Not having much luck with the 210 bitstream, going to move back to the new 200 one by your Makomk. I've found it to be a little more stable.
The 210 has brillant results for about 3-4 hours, but once left unattended over night, It had the lame duck effect, where one half would start mining at about half capacity.

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

Activity: 648


View Profile
August 13, 2012, 02:42:17 PM
 #1896

update:

flashed the boards to the dcm4d200 bitstream, and after 24 hours 8 boards are chugging away @ an avg of U: 5.4, and one pair of chips on one board is @ 4.12. much more stable than the pre-dcm 190 bitstream i was using before. Very happy and can't wait for you guys to release an update. /cheers

ASIC miners available for purchase

Those who serve best, profit most.
toxicocean
Newbie
*
Offline Offline

Activity: 24


View Profile
August 13, 2012, 03:50:30 PM
 #1897

I'm currently using 2 different bitstreams on my #0005 board: shortfin_eb_test_210_overclock.bit on p0 and p1, and shortfin_icarus_cm1_test_190_overclock.bit on p2 and p3. 210 Did great for a while on all 4, but after a few hours 2 FPGA's would stop performing work, so I switched those back to the 190 bitstream.

Stats with this setup:
(5s):770.2 (avg):774.7 Mh/s | Q:11545  A:26708  R:190  HW:0  E:231%  U:10.6/m
ICA0                | (5s):400.8 (avg):395.2 Mh/s | A:13732 R:102 HW:0 U:5.5/m
ICA1                | (5s):378.5 (avg):379.5 Mh/s | A:12978 R:88 HW:0 U:5.2/m

pool reports 771 Mhash/s
hm
Member
**
Offline Offline

Activity: 106


View Profile
August 13, 2012, 04:19:20 PM
 #1898

cgminer 2.6.4, shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:

Code:
cgminer version 2.6.4 - Started: [2012-08-12 23:47:49]
--------------------------------------------------------------------------------
 (15s):977.7 (avg):795.8 Mh/s | Q:3039  A:10706  R:65  HW:0  E:352%  U:9.7/m
 TQ: 0  ST: 4  SS: 1  DW: 545  NB: 120  LW: 20703  GF: 4  RF: 4
 Block: 00000630832d26eb96ea5b5c6b6fb89b...  Started: [17:53:05]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 396.2/398.0Mh/s | A:5863 R:29 HW:0 U:5.30/m
 ICA 1:                | 397.8/397.8Mh/s | A:4843 R:36 HW:0 U:4.38/m
--------------------------------------------------------------------------------



3 hour average691.17 MH/s
15 minute average706.28 MH/s
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 13, 2012, 05:50:59 PM
 #1899

cgminer 2.6.4, shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:

Code:
cgminer version 2.6.4 - Started: [2012-08-12 23:47:49]
--------------------------------------------------------------------------------
 (15s):977.7 (avg):795.8 Mh/s | Q:3039  A:10706  R:65  HW:0  E:352%  U:9.7/m
 TQ: 0  ST: 4  SS: 1  DW: 545  NB: 120  LW: 20703  GF: 4  RF: 4
 Block: 00000630832d26eb96ea5b5c6b6fb89b...  Started: [17:53:05]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 396.2/398.0Mh/s | A:5863 R:29 HW:0 U:5.30/m
 ICA 1:                | 397.8/397.8Mh/s | A:4843 R:36 HW:0 U:4.38/m
--------------------------------------------------------------------------------



3 hour average691.17 MH/s
15 minute average706.28 MH/s

@hm
Please watch the LED's on ICA 1, sometimes one of the both fpga's should show you a orange LED for "some" seconds. On my boards is mostly the second fpga. Flash only this fpga with the dcmwd2 190Mhz bitstream and the ICA 1 should have around 5.2 U.

The dcmwd2 have the best DCM Watchdog and will work better on fpga's with the dcm problem which is ICA 1 on your board.

Give it a try, i'm sure your board will be much more stable in the average Mh.

ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
August 13, 2012, 09:07:46 PM
 #1900

Update for 10 boards with makomk's bitstreams wd4c 200, 210 and 220(special from makomk) !!!Attention! Please use with caution!!!.

I have optimiced every fpga for it's best bitstream version and this is a 4 hours run with cgminer:
Code:
cgminer version 2.6.4a - Started: [2012-08-13 18:06:46]
--------------------------------------------------------------------------------
 (5s):9372.2 (avg):8165.4 Mh/s | Q:6029  A:29736  R:340  HW:0  E:493%  U:112.0/m
 TQ: 0  ST: 22  SS: 0  DW: 1549  NB: 29  LW: 54437  GF: 25  RF: 0
 Connected to http://xxxxxxxxxxxxxxxxx:xxxx with LP as user xxxxxxxxxx
 Block: 0000072baf258bce9edfb9fd104b3549...  Started: [22:25:17]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 415.9/420.3Mh/s | A:1547 R:14 HW:0 U:   5.83/m
 ICA  1:                | 400.3/401.2Mh/s | A:1508 R:21 HW:0 U:   5.68/m
 ICA  2:                | 413.3/414.5Mh/s | A:1519 R:18 HW:0 U:   5.72/m
 ICA  3:                | 407.6/409.8Mh/s | A:1496 R:20 HW:0 U:   5.64/m
 ICA  4:                | 410.0/408.9Mh/s | A:1491 R:14 HW:0 U:   5.62/m
 ICA  5:                | 427.3/420.1Mh/s | A:1553 R:17 HW:0 U:   5.85/m
 ICA  6:                | 411.1/410.9Mh/s | A:1542 R:17 HW:0 U:   5.81/m
 ICA  7:                | 413.3/412.1Mh/s | A:1438 R:17 HW:0 U:   5.42/m
 ICA  8:                | 407.9/410.4Mh/s | A:1540 R:12 HW:0 U:   5.80/m
 ICA  9:                | 399.0/399.5Mh/s | A:1419 R:15 HW:0 U:   5.35/m
 ICA 10:                | 409.6/413.1Mh/s | A:1510 R:15 HW:0 U:   5.69/m
 ICA 11:                | 414.3/411.4Mh/s | A:1503 R:19 HW:0 U:   5.66/m
 ICA 12:                | 403.1/405.8Mh/s | A:1466 R:27 HW:0 U:   5.52/m
 ICA 13:                | 399.2/399.2Mh/s | A:1404 R:18 HW:0 U:   5.29/m
 ICA 14:                | 407.7/409.4Mh/s | A:1502 R:10 HW:0 U:   5.66/m
 ICA 15:                | 399.8/400.0Mh/s | A:1432 R:12 HW:0 U:   5.39/m
 ICA 16:                | 401.9/400.0Mh/s | A:1449 R:13 HW:0 U:   5.46/m
 ICA 17:                | 411.6/409.9Mh/s | A:1469 R:18 HW:0 U:   5.53/m
 ICA 18:                | 411.9/408.6Mh/s | A:1513 R:18 HW:0 U:   5.70/m
 ICA 19:                | 400.6/400.7Mh/s | A:1436 R:25 HW:0 U:   5.41/m
--------------------------------------------------------------------------------

Pool reports a 60 minutes average of 8115Mh/s.

A full optimisation is only doable with MPBM. MPBM tells you on an invalid share which FPGA have produced it. It is the second last digit on the share, 0-7 means FPGA0, 8-9+a-f means FPGA1(Thanks to TheSeven for this information!) on that specific pair. If you get a freezing unit, you will notice it when after some hours/days a unit falls under 5 U and more, you have to watch the pair and you will see one of the both FPGA's will have a orange LED for some seconds. This FPGA need a "lower" bitstream or if it is still freezing with the 190 wd4c bitstream, take the dcmwd2 190 bitstream.

As you see on my boards, all running 200Mh+ bitstreams.

Thank you again to makomk for nice success with the ICARUS modified sources!

eb
Pages: « 1 ... 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 [95] 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 »
  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!