Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards

[eldentyrell]

Hey eldentyrell, please link up with cablepair so the MMQ can get the benefit of your bitstream.

I've responded to all emails…. FWIW I have a hard time remembering the connection between peoples' email addresses, real names, and businesses.  Is cablepair one of the people on the x6500 email thread with TheSeven and the MODMINER people?  Or is he with a different outfit?

[BR0KK]

He is the one behind btcfpga.

He sells the mod miner quad

[purelithium]

Cablepair is Tom, he's with Modminer.

[eldentyrell]

Loading in the Device works, but now i got this error:

"DCM did not report ready for programming"

That happens in ...miner.DCM.setClockFrequency(DCM.java:151)

Could you please post the complete command line you're using, with all arguments, and the complete log that's printed out?  It's hard to tell what's going on just from this one lone line.  However, I will tell you that this is the error message you get if the clock input to the chip isn't running, so you might want to double check that.

[AxelMi]

Today i have time to test again.

You have to change the Device Identifier Code.
Cause My Spartan 6 have: Device IDCODE= 0x4401d093. That is the latest Revision that Xilinx delivers.

http://www.xilinx.com/support/documentation/user_guides/ug380.pdf page 80, the First 4 Bits Are Revision Codes.

My complete Commandline is:
java -Dbitstream=leibniz -Dclock_pin=csg484.W11 -Dclock_pin_freq=6.666 -jar tml.jar urjtag:flyswatter http://HelloWorld:-1@my.pool.bitcoin:8332

And this is the complete output:

_________________________________________________________________________
Tricone Mining Logic, host software v1.11

   IF YOU EXPERIENCE HIGH ERROR RATES: try running just one ring at a
   time (e.g. use 'ztex:0:0.0' on command line instead of 'ztex:0'). 
   If each ring works error free on its own, but you get errors when 
   running all three, it means your power supply is sagging.         

             adding work source gigaforge.com
             starting long poll thread
[flyswatter     ] found new board urjtag:flyswatter
[urjtag:flyswatter:0] found new chip
[urjtag:flyswatter:0] programming FPGA with bitstream leibniz
             USERCODE before bitstream upload: 0xcafebabe
             USERCODE after bitstream upload: 0xcafebabe
[urjtag:flyswatter:0]   done programming FPGA
[urjtag:flyswatter:0] magic number check ok 
[urjtag:flyswatter:0] chip is running bitstream version 0x50547e78, built 8d8h54m32s ago
[urjtag:flyswatter:0] chip has 3 rings       
[urjtag:flyswatter:0] assuming input clock frequency of 6 Mhz
[urjtag:flyswatter:0] asserting global reset
[urjtag:flyswatter:0.0] disabling DCM bypass mux
[urjtag:flyswatter:0.0] opening signcryption channel
[urjtag:flyswatter:0.0] setting clock to 149 Mhz, mult=45 div=2
H:0 X:0 E:0 T:10s   |  H:0 E:0 A:0 R:0 T:10s java.io.IOException: DCM did not report ready for programming
   at com.triconemining.miner.DCM.setClockFrequency(DCM.java:151)
   at com.triconemining.miner.DCM.setClockFrequency(DCM.java:62)
   at com.triconemining.miner.RingWrapper.setClockFrequency(RingWrapper.java:393)
   at com.triconemining.miner.ChipWrapper.enableRing(ChipWrapper.java:268)
   at com.triconemining.miner.ChipWrapper.enableRing(ChipWrapper.java:184)
   at com.triconemining.miner.BoardWrapper.run_(BoardWrapper.java:101)
   at com.triconemining.miner.BoardWrapper.run(BoardWrapper.java:73)
   at java.lang.Thread.run(Thread.java:722)


My Clock is generated from a Frequency Generator. I also tried with 5, 10 and 20 Mhz. always the same result.

[cablepair]

Elden,


Please review this at your earliest convenience.

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

Thank you for all you do

Tom
BTCFPGA.com

[eldentyrell]

FYI I will have limited/unreliable internet and email access until Tuesday 02-Oct.

[RicRock]

Hello,

I've been happily running on my x6500 until 10 min or so ago.

Now I'm getting:

[x6500:AH01ABH9:0.0]   new cipher state = 0x4a1ab2152fd629d276cd6299
             restarting blocked threads for com.triconemining.signcryption.SCClient$Connection@20d9896e
               finished restarting blocked threads for com.triconemining.signcryption.SCClient$Connection@20d9896e
             opening signcryption connection to limp.tricone-mining.com/23.23.249.133:7778
listener thread for limp.tricone-mining.com/184.82.49.28:7778 exiting due to java.io.IOException: please update your TML to the latest version.

I'm running tml.1.11 from the website and do not see a newer version... anyone else having this problem?

[Plazzman]

Hello,

  I'm running 2 mod miners and mine died about the same time.
I don't have remote access to them yet and I'm not in front of them so I have know Idea what the error is yet.
Just weird that mine died at roughly the same time as yours.


 

[cablepair]

Elden blocked a huge group of miners from using his system because he claims we need a "TML Update"

His mining software says that you need to upgrade to the latest version of TML and it effectively knocked everyone's rigs offline (overnight for most of us I might ad) without any prior notice either on the forum or on his tricone-miners subscription news letter.

So since a lot of people have lost some significant mining time due to this complete act of irresponsibility

my team has done a full analysis of this update and here are their findings:

No Bugfixes found / changes appear to be insignificant

Actual Changes from TML 1.11 to 1.12:
* a bit of whitespace here and there
* changed the default bitstream name from kreisel to leibniz
* fixed a misspelled parameter name in the usage info screen
* changed a couple of copyright headers
* bumped the version number to 1.12

Current Known TML Bugs:
* MakeFile Bug -- still unfixed
* Clocking Bug -- still unfixed
* Bitstream Upload Bug -- still unfixed


I am sorry elden but if you want people to feel secure using a centralized proprietary system like this you really need to do things in a way to increase our confidence and surprising us in the middle of the night by inexplicably taking down our mining rigs for no apparent reason is not a good way to do that.




[Borzoi]

Actual Changes from TML 1.11 to 1.12:
* a bit of whitespace here and there
* changed the default bitstream name from kreisel to leibniz
* fixed a misspelled parameter name in the usage info screen
* changed a couple of copyright headers
* bumped the version number to 1.12

Looks if code changed to avoid send of shares below difficulty.  May be because of load on TML servers.  It would be excuse for not allowing connections from older client.

Bitstreams significantly differ, but could be result of compilation of minor change.  Appears some midstate java code calls simplified.  Could be reason for larger bitstream, to move into fpga.  Midstate changes relate to signcryption and could be server affecting as well.

I am guessing based on simple analysis of available source code and eyeball + tools of bitstreams.

[kano]

Wow - if that above is true - damn stay away from this
Proprietary FTL ...

[TheSeven]

Actual Changes from TML 1.11 to 1.12:
* a bit of whitespace here and there
* changed the default bitstream name from kreisel to leibniz
* fixed a misspelled parameter name in the usage info screen
* changed a couple of copyright headers
* bumped the version number to 1.12

Looks if code changed to avoid send of shares below difficulty.  May be because of load on TML servers.  It would be excuse for not allowing connections from older client.

Bitstreams significantly differ, but could be result of compilation of minor change.  Appears some midstate java code calls simplified.  Could be reason for larger bitstream, to move into fpga.  Midstate changes relate to signcryption and could be server affecting as well.

I am guessing based on simple analysis of available source code and eyeball + tools of bitstreams.

Indeed, besides pushing a new bitstream he also implemented difficulty >1 support, wow!
But why on earth does this warrant a breaking protocol change AT ALL? (Not to even mention that there was no prior notice.)
Well, maybe the old bitstream contained some critical flaw in the signcryption code that was fixed in the new one? I can't think of a different (rational) explanation. But OTOH it wouldn't be the first time for ET to act in a completely irrational way.

[ShadesOfMarble]

I still don't get why he didn't opt to open source his bitstream. Donations worth hundred of BTC instead of zero revenue from forced donations.
Yes, his next project will yield "much more than those few BTC" but what does this project has to do with that? FPGA mining will be dead in a few months.

In my opinion this already *was* irrational...

[makomk]

Indeed, besides pushing a new bitstream he also implemented difficulty >1 support, wow!
But why on earth does this warrant a breaking protocol change AT ALL? (Not to even mention that there was no prior notice.)
Well, maybe the old bitstream contained some critical flaw in the signcryption code that was fixed in the new one? I can't think of a different (rational) explanation. But OTOH it wouldn't be the first time for ET to act in a completely irrational way.

I suspect he accidentally released enough information for a clever hacker to bypass the signcryption. Been resisting the temptation to try.

[kano]

Indeed, besides pushing a new bitstream he also implemented difficulty >1 support, wow!
But why on earth does this warrant a breaking protocol change AT ALL? (Not to even mention that there was no prior notice.)
Well, maybe the old bitstream contained some critical flaw in the signcryption code that was fixed in the new one? I can't think of a different (rational) explanation. But OTOH it wouldn't be the first time for ET to act in a completely irrational way.

I suspect he accidentally released enough information for a clever hacker to bypass the signcryption. Been resisting the temptation to try.

So ... someone was hashing with his bitstream for free ... instead of ?

Sounds like a good reason to kill off everyone (without notification) mining using his bitstream until they work out what is happening ... NOT!

[eldentyrell]

Elden blocked a huge group of miners from using his system because he claims we need a "TML Update"

Below is an excerpt from an email I sent to TheSeven which does a good job of explaining the situation.

All of the anger is completely justified.  This was a screwup on my part.  The only consolation I offer is that this wasn't the result of me doing something, it was the result of me failing to do something.

The leibniz bitstream doesn't expire for another 40 days.  Long before then I will make sure this doesn't happen again, most likely by removing the ntime check.

FWIW, I had no idea so many people were using the TML.  I suppose that means that when I turn on the commissions I will get a nontrivial income from this, in which case I will have a strong motivation to take uptime very seriously.

On Oct 4, 2012, at 11:07 AM, theseven wrote:
((theseven being justifiably cranky about the service interruption))

TL;DR: it was not intentional, nor was it something done "on my end".  It has nothing to do with signcryption.

The pre-commission (i.e. free) bitstreams have a two-month expiration, something left over from back before I really trusted the signcryption.  The circuit won't work on jobs with an ntime more than 60 days past the date I built the bitstream -- it deliberately corrupts them.  The signcryption server simply gives you a helpful message instead of sending back invalid nonces -- the "is gateware version more than 60 days old" check is on the server side rather than in the client software.  If you don't believe me, modify your client software to lie about the gatewareVersion and try sending a piece of work from two days ago -- it'll hash just fine.

This will be removed once (if) I start charging money.  It was an insurance policy in case the signcryption backend servers got hacked or I did something wildly stupid like post a bitstream that works on non-signcrypted jobs, although I haven't built any of those in at least three months now.  My own rigs use the signcryption servers and run the same bitstream as everybody else, and I get a text message if they stop mining in the middle of the night.  This is why there was a fix posted within 15 minutes of the expiration.

At least one other ultra-high-performance bitstream has the same feature.  It has absolutely nothing to do with the signcryption.  You're going to find it in any bitstream that somebody has put a serious amount of work into.

I still have limited email until Monday.

Blue portions were edited relative to the email I sent him (due to wider audience).  Bold added for those who are skimming.

[eldentyrell]

Indeed, besides pushing a new bitstream he also implemented difficulty >1 support, wow!

Yeah, because I had a similar unexpected-downtime experience with EclipseMC -- they recently started rejecting two-low-difficulty shares.

Unfortunately since the X-Reject-Reason headers aren't standardized the safest thing to do is assume that when a share is rejected that work ought to be thrown out.  This wrecks the hashrate.

[Luke-Jr]

Indeed, besides pushing a new bitstream he also implemented difficulty >1 support, wow!

Yeah, because I had a similar unexpected-downtime experience with EclipseMC -- they recently started rejecting two-low-difficulty shares.

Unfortunately since the X-Reject-Reason headers aren't standardized the safest thing to do is assume that when a share is rejected that work ought to be thrown out.  This wrecks the hashrate.

Well, the reasons are standardized as part of BIP 22.
Obviously it's not necessarily a rule for the now-obsolete getwork protocol, but there's no reason not to use the same strings either.

But more importantly: if your miner had supported the target - which has been standard since getwork was created - you wouldn't have these rejects at all.

[eldentyrell]

But more importantly: if your miner had supported the target - which has been standard since getwork was created - you wouldn't have these rejects at all.

I know, I know.

So many features, so little time.