Pages:
Author

Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 12. (Read 119439 times)

hero member
Activity: 504
Merit: 500
FPGA Mining LLC
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.

Well, probably not anymore after this incident... This is a breach of trust/confidence/reliability which especially the large scale miners will take very seriously. On my side you've killed about 7 gigahashes, I'd assume the total from the people running my TML port for x6500/MMQ alone will be in the 50-100GH/s range.

IMO it would have been mandantory for you to publish the information that the bitstreams have a time bomb when you released TML. Your customers have a right to know that they will have to regularly update their systems, and if you had released that information you would surely have been reminded in time that the deadline is approaching.

Has there been a downtime of the signcryption services? Or do you block IPs that repeatedly try to connect with an old gateware version? After I rebased to 1.12 yesterday I wasn't able to contact any signcryption server anymore, they just refused the connection (and I saw that it tried several different IPs).
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.

By the way, something occurred today: can variable difficulty be used to combat withholding attacks?  The higher the share difficulty, the higher the cost of the withholding attack -- the "found a block" shares represent a larger fraction of the submitted shares.  Could even be automated: if the pool sees a suspiciously low fraction of block-found shares from a miner, jack up their difficulty.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
legendary
Activity: 2576
Merit: 1186
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.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.


Quote
Quote
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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!
hero member
Activity: 686
Merit: 564
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.
donator
Activity: 543
Merit: 500
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...
hero member
Activity: 504
Merit: 500
FPGA Mining LLC
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Wow - if that above is true - damn stay away from this
Proprietary FTL ...
newbie
Activity: 54
Merit: 0
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.
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
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.



member
Activity: 85
Merit: 10
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.


 
sr. member
Activity: 290
Merit: 250
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?

donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
FYI I will have limited/unreliable internet and email access until Tuesday 02-Oct.
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
newbie
Activity: 43
Merit: 0
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:[email protected]: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.
donator
Activity: 980
Merit: 1004
felonious vagrancy, personified
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.
hero member
Activity: 504
Merit: 500
Cablepair is Tom, he's with Modminer.
Pages:
Jump to: