Bitcoin Forum
December 09, 2016, 09:41:52 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   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 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 ... 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251382 times)
wildemagic
Member
**
Offline Offline

Activity: 112



View Profile
June 18, 2012, 04:22:32 AM
 #721

But the limit at the moment may not be a timing issue, it may be something else - however I've no idea and also have no details about the device except what everyone here has posted.

We were told that the initial bitstream was only 50mhz so that may be why the hashrates are so low even with 2/4 fpgas hashing in icarus mode.

kind regards

.,-._|\     Offgrid 1.7kW Solar and 3G wireless internet powering my mining rig.
/ .Oz. \
\_,--.x/     [219.5btc of successful trades total] with : rastapool, miernik, flatronw & OneFixt
       o
Unlike traditional banking where clients have only a few account numbers, with Bitcoin people can create an unlimited number of accounts (addresses). This can be used to easily track payments, and it improves anonymity.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481319712
Hero Member
*
Offline Offline

Posts: 1481319712

View Profile Personal Message (Offline)

Ignore
1481319712
Reply with quote  #2

1481319712
Report to moderator
1481319712
Hero Member
*
Offline Offline

Posts: 1481319712

View Profile Personal Message (Offline)

Ignore
1481319712
Reply with quote  #2

1481319712
Report to moderator
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
June 18, 2012, 09:59:07 AM
 #722

Also I read 200Mh/s from someone?

Yes, I get ~200Mh/s average with SW6 1 off, 234 on with mpbm 115200 baud rate. Only one unit is working when i startup, but when i restart the second unit it will come up and working too. I have to restart the second unit more often to get it working, but then it will work and i get ~200Mh/s.


ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
June 18, 2012, 12:09:24 PM
 #723

But the invalids are horrible for the second pair ~60%!

My pool say's 127MH/s.
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
June 18, 2012, 01:01:52 PM
 #724

With my approve settings and SW4 1 off, 234 on (this FPGA deactivated) i get ~143Mh/s on my pool. No more invalids  Still invalids ~30% Grin
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
June 18, 2012, 02:42:40 PM
 #725

moved this to the next page ...

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
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
June 18, 2012, 04:03:12 PM
 #726

Moved this to this page in case anyone was looking for it Smiley
-----
Daemonic visited me in #cgminer

Looking at his API stats figures certainly suggests it's running at just under 100MH/s
For 99.87MH/s the setting I'd suggest are:

--icarus-timing 10.001=426

10.01 10.001 is ns per hash (100MH/s is exactly 10ns/hash)
420 426 is the number of 1/10ths of a seconds to run up to before it completes (42.6 seconds)

The actual full value to use would be 429 428 (not 420 426)
However, reducing that amount a bit allows for a little leeway in the performance of the FPGA
(the performance affect of reducing that is well below displayed accuracy)

If you want to get these numbers yourself:
cgminer --api-listen --icarus-timing short .....

The timing values will be displayed on the cgminer screen, but you can check them at any time, after the first re-estimate, with the API
If you have java installed, then while cgminer --api-listen is running:
java API stats
Re-estimates are displayed on the cgminer screen like:
Icarus %d Re-estimate: Hs=%e W=%e read_count=%d fullnonce=%.3fs

The API numbers of interest are "Hs" and "read_count"
"Hs" is the seconds per hash (convert it to ns by multiplying by 1000000000.0)
"read_count" is a 1 less than how long it takes to do a full nonce range (in 1/10ths of a second)

You should let it run on a quiet machine for about 4 hours for "short" to complete at 100Mh/s
("long" runs timing forever)

so you get: --icarus-timing Hs*10^9=read_count

I've used 10.01 10.001 for Hs since Daemonic's quick test run was an average of that over 2 sets of data over 2 hours


Now if you want to know if everything is running at ~100MH/s, then U: should be 1.40 +/- 10% after a few hours

Edit: updated above in red after Daemonic has given me his 2hr run stats

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

Activity: 49


View Profile
June 18, 2012, 04:04:46 PM
 #727

Daemonic visited me in #cgminer

</snip>

--icarus-timing 10.001=426

</snip>

Edit: updated above in red after Daemonic has given me his 2hr run stats

Thanks for all your help Smiley
mem
Hero Member
*****
Offline Offline

Activity: 644


Herp Derp PTY LTD


View Profile
June 18, 2012, 04:09:31 PM
 #728

Back on topic, Ive got 2 of the orders Im about to pay for (test sample Cheesy ).

Been out off the community for a few weeks (flu) which is a long time in bitcoin terms (wow +$6 ).
Just got the email saying, ready to ship when you are ready to pay, Cheesy very nice surprise.

100mh with the beta firmware hey ?, lol Tongue still they did warn us (what a refreshing show of honesty from a btc FPGA company compared to other unmentionables).

Questions
  • How is current firmware development going
  • Any news on a new firmware for us to test (if nothing official Im happy with gossip)
  • Any settings etc I should be wary of when getting these going ? (dont want to blow them 1st round)

Im impressed how well you kept to the timeline so far, the future looks bright Smiley .

Will be organizing payment shortly, Ive been holding off cashing out my banked 500btc while watching the price spike Wink

ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
June 18, 2012, 04:17:44 PM
 #729

...
Questions
  • Any settings etc I should be wary of when getting these going ? (dont want to blow them 1st round)
...

I'm sure you can't blow it, i switched everything and it's hashing ~140Mh/s and cold as an refrigerator Grin

As Yohan stated some pages befor, the shipping switches should be:
SW1 all on
SW6 all on (57600 baud 100Mh/s, 1 off 115200 baud ~140Mh/s)

SW2 all on
SW3 134 on, 2 off
SW4 134 on, 2 off
SW5 all on

daemonic
Jr. Member
*
Offline Offline

Activity: 49


View Profile
June 18, 2012, 04:44:15 PM
 #730

...
Questions
  • Any settings etc I should be wary of when getting these going ? (dont want to blow them 1st round)
...

I'm sure you can't blow it, i switched everything and it's hashing ~140Mh/s and cold as an refrigerator Grin

As Yohan stated some pages befor, the shipping switches should be:
SW1 all on
SW6 all on (57600 baud 100Mh/s, 1 off 115200 baud ~140Mh/s)

SW2 all on
SW3 134 on, 2 off
SW4 134 on, 2 off
SW5 all on
Mine came shipped as;
SW6 All on
SW1 1 off, 234 on

SW2 All on
SW3 1 off 234 on
SW4 1 off 234 on
SW5 All on

With your dip settings above, the amber led switches periodically between the FPGA next to SW4/SW5 and sometimes both on for a few seconds.
With my original settings, the amber led is always on for the FPGA next to SW3/SW4
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
June 18, 2012, 04:46:53 PM
 #731

With my original settings, the amber led is always on for the FPGA next to SW3/SW4

That means these FPGA's are idle (deactivated)

With your dip settings above, the amber led switches periodically between the FPGA next to SW4/SW5 and sometimes both on for a few seconds.

I know, it looks like the bitstream is buggy here, but i get ~140Mh/s with this settings instead of 100Mh/s
DiabloD3
Legendary
*
Offline Offline

Activity: 1162


DiabloMiner author


View Profile WWW
June 18, 2012, 05:17:23 PM
 #732

Please can a mod split this offtopic stuff to another thread.
Or delete it.
Whichever is easier.

I split, stickied and locked it.

This is how BFL will do their penance.

https://bitcointalk.org/index.php?topic=88363.0

ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
June 18, 2012, 05:21:20 PM
 #733

Please can a mod split this offtopic stuff to another thread.
Or delete it.
Whichever is easier.

I split, stickied and locked it.

This is how BFL will do their penance.

https://bitcointalk.org/index.php?topic=88363.0

Nice move, thank you!
wildemagic
Member
**
Offline Offline

Activity: 112



View Profile
June 18, 2012, 05:33:29 PM
 #734

Thanks Diablo !

kind regards

.,-._|\     Offgrid 1.7kW Solar and 3G wireless internet powering my mining rig.
/ .Oz. \
\_,--.x/     [219.5btc of successful trades total] with : rastapool, miernik, flatronw & OneFixt
       o
Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
June 18, 2012, 05:54:48 PM
 #735

I *thought* the Icarus bitstream could, was reported as able to, produce 400mh/s from these things while using only two of the four FPGAs. Is no one getting that?

It should, the problem with the default icarus bitstream is clock stability, it does it, but it seems to have clocking problems at the default rate. Anyone with the ability to reflash their boards should be able to reflash the default icarus bitstream to these, and try connecting, it should work with the first 2 chips only. at about 200MHash/s per chip. Provided they can get the clock stable. Ideally we need to modify the icarus bitstream to run at a lower clock source (say 50Mhz) and clock it up using an internal DCM to clock it up for hashing.

It should be noted that they initially designed the board with the hope that the icarus bitstream would run out of the box on this. The problem was there was a swap on 2 of the tx/rx pins from the first to second fpga in each "Icarus Chain". This means that only one of the chips hashes on the stock icarus bitstream.

Icarus is opensource, so several people (myself among them) have been working our butts off to do 2 things:
- Synthesize the icarus source code to a new "Cairnsmore" bitstream, which we've marginally succeeded at (resulting in the 50Mhz bitstream out now).
- Design a new bitstream from scratch that should easily beat the icarus bitstream.

The problem with re-synthesizing the icarus bitstream is that:
A) The source is distributed in a raw HDL format. Not including project files, compiler flags, pinouts, and other important bits needed to synthesize it. this requires a LOT of work to get the project ready to "compile" so to speak. Ultimately the open source project is "incomplete" in it's existing state.
B) Most of the time synthesis outright fails. P&R on this source is bad, and it has a hard time placing it all on the chip (I believe ngzhang did this by using a combination of Xilinx ISE and Synplify, without a "legit" license for these, which may be legal in his country but not here, and synplify is expensive)
C) Each run takes MANY hours, so you can only get a couple attempts in a single day (and yes I know you can fire up a cluster in EC2 and run PAR there, I've done that, on a cluster of about a dozen Double Extra Large instances in EC2, for a day, still didn't help matters so far, and yes it was expensive lol).
D) The code is a bit strange, several things are... Wierd... in it. And it causes some problems, such as the boundry between clock domains between the comms code and the hashing cores, this causes in the default setup a clocking breakdown and the comms core fails, leaving the chip useless until it's restarted. There is also some over-sensitive settings on the hashing clock, which is why we had to underclock it to 50Mhz (over that the clock becomes unstable), which since the icarus code runs one hash per clock, that means 50MHash per chip. And a few other issues. Essentially it needs A LOT of hand holding to get it into a useful state at all.

Since getting the basic build done (which was used to produce the 50Mhz bitstream), I've since given up on porting icarus over and moved back to building my own bitstream from scratch, designed for Cairnsmore. But that's also not a simple task. The reason I focused on Icarus initially was in the hope it would only take me a few days to hack together a usable 200Mhash bitstream. Unfortunately the level of effort is increasing drastically, and that time is better spent on the fresh bitstream.

At the same time the Enterpoint guys are still working to get the icarus bitstream "hacked" into a working state pulling at least close to 200MHash per chip.

Also the Tricone bitstream is an option as well which should be doable on these chips. Hopefully someone drives that forward as well, as it would be a good option for people to have (as it should pull close to 1GHash/s on these boards)

Lastly enterpoint has the skillset to make their own bitstream, but they have said that will be several months away. Right now their developers are all tied up, but their hardware team had cycles (which is why the boards could be made quickly). Once their developers are freed up they can likely bang out a nice bitstream for these boards.

The low performance is not indicitive of this board's actual performance, it's simply the fact that the icarus code is painful to work with, and due to one minor oversight (the swapped tx/rx, which is partially due to unclear source and lack of documentation on the icarus project), the icarus bitstream doesn't run out of the box on it. So the current options from a bitstream perspective are a bit lacking.

Overall this was all made clear in the beginning, Enterpoint has been awesome at keeping everyone in the loop during development and shipping. So hopefully either we get a hack working using the icarus based bitstream, or someone releases another bitstream for this board very soon that takes advantage of it's real potential.

I don't want to make any promises at all on my bitstream as it's too early to tell, and my time is limited (I have a day job to keep up with too lol).

So right now the way it stands, I managed to re-package and synthesize the icarus code into a usable bitstream, but it had issues. I sent that "complete" project and bitstream (along with ncd files and such) to Enterpoint, which they were able to tweak/adjust to get the current bitstreams in distribution. I'm not doing any further work on the icarus stuff, but hopefully they will make more progress.

I should have posted some of this info earlier, but I've been so busy the little time I have has been spent with blinders on working on the bitstream. So I had no idea this thread had progressed this far lol.

Hopefully this helps clarify some of the current bitstream situation.

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

Activity: 49


View Profile
June 18, 2012, 06:40:41 PM
 #736

Glasswalker, thanks for the well thought/laid out explanation and thanks for everyone's efforts to get us this far Smiley
swapper
Newbie
*
Offline Offline

Activity: 17


View Profile
June 18, 2012, 07:15:57 PM
 #737

yohan, mail sent for ordering a unit of this promising fpga miner.
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
June 18, 2012, 07:38:40 PM
 #738

With my approve settings and SW4 1 off, 234 on (this FPGA deactivated) i get ~143Mh/s on my pool. No more invalids  Still invalids ~30% Grin

Thanks for this info! I now have 100Mh/s from 3 of my 4 Cairnsmore1 COM ports (I have two Cairnsmore1's).

I'm not sure why only one of them isn't working though. Any ideas?

It's just showing 0Mh/s, whereas the others all show 100Mh/s each.

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
ebereon
Sr. Member
****
Offline Offline

Activity: 407


View Profile
June 18, 2012, 07:54:06 PM
 #739

It's just showing 0Mh/s, whereas the others all show 100Mh/s each.

The one pair is not starting propably, that's why i use mpbm atm. In mpbm i can restart only one COM and i do this until it starts up.

At the moment my unit is hashing @ ~175Mh/s checked on my pool 15 minutes average. One pair have over 60% invalids, that's the bitstream issue. Every time one of the fpga's on the bad pair is stopping (orange led) and don't get new work. It's waiting until it get's new job from the miner software.

I testing some settings atm to get it faster hashing with little succes. In mpbm i can change the job submit for each COM in seconds, standard is 60 and i changed that to 5 on the bad fpga pair.

I really don't know what i'm doing, but it's working so i'm happy Grin
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
June 18, 2012, 08:14:09 PM
 #740

It's just showing 0Mh/s, whereas the others all show 100Mh/s each.

The one pair is not starting propably, that's why i use mpbm atm. In mpbm i can restart only one COM and i do this until it starts up.

At the moment my unit is hashing @ ~175Mh/s checked on my pool 15 minutes average. One pair have over 60% invalids, that's the bitstream issue. Every time one of the fpga's on the bad pair is stopping (orange led) and don't get new work. It's waiting until it get's new job from the miner software.

I testing some settings atm to get it faster hashing with little succes. In mpbm i can change the job submit for each COM in seconds, standard is 60 and i changed that to 5 on the bad fpga pair.

I really don't know what i'm doing, but it's working so i'm happy Grin

Ah thanks, I didn't know that was what I had to do Smiley I'm running mpbm at the moment too, it's great IMO.

Same here with the invalids. Very very high but hashrate is still decent taking that into account.

Well kudos to you for fiddling around and pushing it to the limits Smiley

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
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 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 ... 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!