Bitcoin Forum
December 07, 2016, 10:28:18 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 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 »
  Print  
Author Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards  (Read 174156 times)
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
June 11, 2012, 09:47:33 PM
 #781

Turbor, what you see in your first log is called the "downclock of death" and people, including me, have seen this for a long time. What you see in your second log is just normal behavior.
What do you mean by normal behavior?

Oh, I thought that the last two lines (212 MHz and 208 MHz) mean that everything is fine and dandy again.
I didn't see the "FPGA is shut down to prevent damage" line.
If it's shut down, why does it then have normal frequencies like 212 MHz, 216 MHz and 208 MHz again?

Anyway, this sounds like a classical RMA situation to me.

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

Posts: 1481149698

View Profile Personal Message (Offline)

Ignore
1481149698
Reply with quote  #2

1481149698
Report to moderator
1481149698
Hero Member
*
Offline Offline

Posts: 1481149698

View Profile Personal Message (Offline)

Ignore
1481149698
Reply with quote  #2

1481149698
Report to moderator
1481149698
Hero Member
*
Offline Offline

Posts: 1481149698

View Profile Personal Message (Offline)

Ignore
1481149698
Reply with quote  #2

1481149698
Report to moderator
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 11, 2012, 10:18:37 PM
 #782

Quote
bus-0-0: ztex_ufm1_15y1-0001-02-07-3: Set frequency to 68.00MHz
bus-0-0: ztex_ufm1_15d4-0001-02-05-1: f=208.00MHz,  errorRate=0.50%,  maxErrorRa
te=1.57%,  hashRate=207.0MH/s,  submitted 13 new nonces,  luckFactor=1.14
bus-0-0: ztex_ufm1_15d4-0001-02-06-1: f=208.00MHz,  errorRate=0.00%,  maxErrorRa
te=0.66%,  hashRate=208.0MH/s,  submitted 8 new nonces,  luckFactor=0.82
bus-0-0: ztex_ufm1_15y1-0001-02-07-1: f=212.00MHz,  errorRate=0.75%,  maxErrorRa
te=0.87%,  hashRate=210.4MH/s,  submitted 12 new nonces,  luckFactor=0.99
bus-0-0: ztex_ufm1_15y1-0001-02-07-2: f=208.00MHz,  errorRate=0.01%,  maxErrorRa
te=0.59%,  hashRate=208.0MH/s,  submitted 16 new nonces,  luckFactor=0.97
bus-0-0: ztex_ufm1_15y1-0001-02-07-3: f=68.00MHz,  submitted 2 new nonces,  luck
Factor=0.96
The third fpga on his quad is failing. All the others behave normal Smiley

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
June 12, 2012, 07:53:26 AM
 #783

The third fpga on his quad is failing. All the others behave normal Smiley

I asked you to return the board a feew weeks ago.

So please don't complain about a non working board without giving me the chance to repair / replace it.

vv01f
Sr. Member
****
Offline Offline

Activity: 314


View Profile
June 12, 2012, 10:36:24 AM
 #784

@ztex: I dont think he "complains" but only tries to point out for understanding Smiley
although I estimate him having bad luck on country borders without knowing about his place - cant imagine other reason to run it that way all the time.

/*! break !*/

Another question due to possible failing on long (ok, here it was <24h with -oh 0.08) running the boards:
Is it possible to exit BTCMiner on errors and read some error-number or parse the logs for dealing with the problem?
Until now BTCMiner wont exit but trying to keep running (waiting for input q or s) and throwing error msg .. so I had to rerun manually

I will add another log in the evening where such a problem with bad string stopped BTCMiner of working - could be due to the pool (but neither of the two backup pools was used) or my internet connection (error message does not say so) .. or perhaps my failing core is into that .. (will first check reconnect time of the router and get the log). But perhaps you have already some idea ...
One simple solution coming to my mind, though not sure it is sufficient: running the startup-script $0 again after exiting BTCMiner (until now I stop it doing that until user agrees with some key using read -s)

Or simpler: How to run clusters automatically (e.g. headless without monitoring) and handling errors best?
Or: How to monitor another way than checking the logs?



donations to me please send via bitcoin 1vvo1FDwSAwNdLVA1mFkM7v76XPZAAUfb
a good European exchange: bitcoin.de (ref-link)
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
June 12, 2012, 10:40:31 AM
 #785

The third fpga on his quad is failing. All the others behave normal Smiley

I asked you to return the board a feew weeks ago.

So please don't complain about a non working board without giving me the chance to repair / replace it.


I never complained about the bad FPGA. Things like that happen and I can live with that. That was and is our agreement.

Just tried to give the other guy some advice. If a FPGA shuts down all the time -oh is the only way to find out where the problem is imo. Because if you don't set it, it shuts down after 3 to 4 drops. That can be too early for a bad set heatsink.

rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
June 12, 2012, 01:44:22 PM
 #786

I think the whole -oh ratio variable is hard to grasp... could it be "how many frequency jumps per second" or something we can understand professor?

0.7 equals 70% hashrate drop. 0.6 60% and so far. Base frequency seems to be 200 MHz.


70% hashrate drop per what second?

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
vv01f
Sr. Member
****
Offline Offline

Activity: 314


View Profile
June 12, 2012, 02:13:14 PM
 #787

70% hashrate drop per what second?
As I understand it, yes - but thats not really important.
Its 70% of the Number in MHz. And that one translates (counting in luck and errors) estimated 1:1 into MH/s.
So due to the hash rate counted in MH/s it is estimated 70% of that. If you would count it in MH/h it still would be relative to your calculation/numbering in MH/h.

The only term I do not really understand in regards of calculation is "submitted hash rate". Is it the number of total nonces translated to MH/s ?

donations to me please send via bitcoin 1vvo1FDwSAwNdLVA1mFkM7v76XPZAAUfb
a good European exchange: bitcoin.de (ref-link)
gr0bi42
Full Member
***
Offline Offline

Activity: 158


View Profile WWW
June 12, 2012, 02:50:26 PM
 #788

@ztex:
after trying to get one quad-board (labeled 1.15x) running on Linux (Ubuntu 12.04) I have growing problems with one of the FPGAs
that chip already was the slowest in my setup leveling in to 208 MHz (all others do at least 216 Mhz) previously on Windows 7 .
after realizing to utilize sudo also the linux-client ran right off, but it shut down the FPGA #2 due to increasing hash rate drop (4-10%). That I already had with -oh 0 on Windows 7, but with -oh 0.04 it was OK on 208 MHz.
Now reconnecting to Windows for double-checking the hash rate drop also occurred there, #2 is disconnected due to that.
I already remounted the cooler two times, covering of the chip with MX4 looked ok, nothing besides the chip.

Any ideas what to check/try next  Huh


*edit, replaced "error" with correct term "hash rate drop" :
while writing also #1 is disconnected for hash rate drop rate 4% and the others are leveling down to 212 MHz .. I think it better to power that one off.  Undecided


Hi,

I have the same problem with one of my Quad's. One FPGA's frequency toggles right after starting BTCMiner:
Code:
001-1: ztex_ufm1_15y1-04A36E054A-1: Change from frequency 200.00MHz to 196.00MHz
001-1: ztex_ufm1_15y1-04A36E054A-1: Change from frequency 196.00MHz to 200.00MHz
001-1: ztex_ufm1_15y1-04A36E054A-1: Change from frequency 200.00MHz to 196.00MHz
001-1: ztex_ufm1_15y1-04A36E054A-1: Change from frequency 196.00MHz to 192.00MHz
001-1: ztex_ufm1_15y1-04A36E054A-1: Change from frequency 192.00MHz to 196.00MHz

Got a tip from ztex to reset the error and performance counter (c-command) after a while. After the c-command  the FPGA goes up to 220 Mhz and runs stable.

I had two other boards with permanent hashrate drop errors. Sent them in for repair... quick return... now they are running fine.

But one problem remains: every once in a while one or two FPGA's of my cluster were shut down by BTCMiner due to this hashrate drop error. This does not happen with cgminer. I'm sure, it's not a cooling problem. Maybe it's a power problem (loose contact). I don't know.

BUT, I've started to modify BTCMiner for my needs. And one change I've made is to autoreset the error and performance counter every hour. In this way the cluster hashes always at max. speed and especially at night, then temps come down, I gain some extra MHashes. As an interesting sideeffect, since then I never got a hashrate drop error shutdown. Cluster runs super stable since 2 days now, without any issue.

Donations are welcome: 1Btf3BqUegfe5iFdWsgfBf1Ew3YsAvsrLT
gr0bi42
Full Member
***
Offline Offline

Activity: 158


View Profile WWW
June 12, 2012, 03:27:53 PM
 #789

And here can you find the patch: https://bitcointalk.org/index.php?topic=40047.msg957636#msg957636

Donations are welcome: 1Btf3BqUegfe5iFdWsgfBf1Ew3YsAvsrLT
vv01f
Sr. Member
****
Offline Offline

Activity: 314


View Profile
June 12, 2012, 04:25:47 PM
 #790

for the early morning problem..
   
my log says dsl connection was (re)established
Quote
12.06.2012, 04:31
- so I dont think that was the problem  Huh

miner was startet (not regarding the login data) with that one:

Code:
java -cp /home/wolf/btcminer/ZtexBTCMiner-120417.jar BTCMiner -f ztex_ufm1_15y1.ihx -host http://mmpool.bitparking.com:15098 -u vv01f -p testpw -b http://de.btcguild.com:8332 vv01f_fpga testpwd -b http://eu.ozco.in:8332 accnumber testpw -l /home/wolf/btcminer/fpga.log -bl /home/wolf/btcminer/fpga-submitted.log -m c -oh 0.08

resulting finally in full stop with error msg

Code:
2012-06-12T05:03:48: Stopped thread for bus 001-0

after some problem with pool data / a string (not sure how to read that properly):

Code:
2012-06-12T04:59:28: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T04:59:32: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:10: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:16: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:30: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:57: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:23: 001-0: ztex_ufm1_15y1-04A36E0711-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:40: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:56: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Invalid length of string: Disabling device
2012-06-12T05:01:56: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Invalid length of string: Disabling device
2012-06-12T05:01:57: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Invalid length of string: Disabling device
2012-06-12T05:01:57: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Invalid length of string: Disabling device
2012-06-12T05:02:11: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Invalid length of string: Disabling device
2012-06-12T05:02:41: 001-0: ztex_ufm1_15y1-04A36E0711-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:02:46: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Invalid length of string: Disabling device
2012-06-12T05:02:59: Warning: Invalid length of string
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Invalid length of string: Device disabled since 2012-06-12T05:02:46
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-2: Error: Hash rate drop of 10,0% detect. This may be caused by overheating. FPGA is shut down to prevent damage.  50.0: Device disabled since 2012-06-11T06:43:14
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:57
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:57
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Invalid length of string: Device disabled since 2012-06-12T05:02:11
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:56
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-3: f=216,00MHz,  errorRate=0,11%,  maxErrorRate=1,23%,  hashRate=215,8MH/s,  submitted 10 new nonces,  luckFactor=0,91
2012-06-12T05:03:29: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Invalid length of string: Device disabled since 2012-06-12T05:01:56
2012-06-12T05:03:29: 001-0: poll loop time: 236ms (USB: 11ms network: 225ms)   getwork time: 362ms  submit time: 407ms
2012-06-12T05:03:29: 001-0: Warning: 3 overflows occured. This is usually caused by a slow network connection.
2012-06-12T05:03:29: Total hash rate: 215,8 MH/s
2012-06-12T05:03:29: Total submitted hash rate: 195,7 MH/s
2012-06-12T05:03:29:  --------
2012-06-12T05:03:48: 001-0: ztex_ufm1_15y1-04A36E0711-3: Error: Invalid length of string: Disabling device

full log for that run: Log 4 BTCMiner failing on some string error - it will expire in ~30d.

Thanks for the hint with c-command while runtime.. it seems I didnt read that help properly.
But for now I see no lasting effekt. Just randomly the # of 2nd fpga on the problematic board (also slowing down) changes, right now #4 is slowed down to 200 MHz and #3 I also saw disabled at first try until manual q-command.
For some time the hash rate will go up, but I fear it having bad impact done to often.

No offence, I will not change the setup to your firmware until ztex says its Ok for same reasons I will not set -oh above 0.1 - just prevent further damage he has nothing to do with. Instead I will try to keep at least 3 cores of that board running stable until Friday.

donations to me please send via bitcoin 1vvo1FDwSAwNdLVA1mFkM7v76XPZAAUfb
a good European exchange: bitcoin.de (ref-link)
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 12, 2012, 08:00:13 PM
 #791

The third fpga on his quad is failing. All the others behave normal Smiley

I asked you to return the board a feew weeks ago.

So please don't complain about a non working board without giving me the chance to repair / replace it.


Nooooo Mine is working perfectly so everything is ok Smiley

Was just pointing Out that the third fpga of the User was failing.


ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
June 13, 2012, 11:40:19 AM
 #792

70% hashrate drop per what second?

Time plays no role.

Quote
Its 70% of the Number in MHz. And that one translates (counting in luck and errors) estimated 1:1 into MH/s.

It's relative to the hash rate (i.e. frequency minus error rate) as stated in the logs. E.g. if the maximum frequncy is 212 MHz and the error rate at this frequency is 1% a frequency drop to 200 MHz is equal to a hash rate drop of (at least) 4.707%.

Quote
The only term I do not really understand in regards of calculation is "submitted hash rate". Is it the number of total nonces translated to MH/s ?

"Submitted hash rate" is calculated based on the amount of successfully submitted shares to pool(s).

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
June 13, 2012, 11:45:29 AM
 #793

Another question due to possible failing on long (ok, here it was <24h with -oh 0.08) running the boards:
Is it possible to exit BTCMiner on errors and read some error-number or parse the logs for dealing with the problem?
Until now BTCMiner wont exit but trying to keep running (waiting for input q or s) and throwing error msg .. so I had to rerun manually
...
Or simpler: How to run clusters automatically (e.g. headless without monitoring) and handling errors best?
Or: How to monitor another way than checking the logs?

I think the easiest way is to add a secondary input method for command entering. Then everyone can write its own scripts to deal with errors by sending commands through a named pipe.

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
June 13, 2012, 11:54:39 AM
 #794

The third fpga on his quad is failing. All the others behave normal Smiley

I asked you to return the board a feew weeks ago.

So please don't complain about a non working board without giving me the chance to repair / replace it.


Nooooo Mine is working perfectly so everything is ok Smiley

Was just pointing Out that the third fpga of the User was failing.

Sorry, this was not addressed to you.

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
June 13, 2012, 12:00:42 PM
 #795

Code:
2012-06-12T04:59:28: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T04:59:32: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:10: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:16: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:30: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:00:57: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:23: 001-0: ztex_ufm1_15y1-04A36E0711-3: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:40: 001-0: ztex_ufm1_15y1-04A36DE0AA-1: Error: Read timed out: Disabling URL http://mmpool.bitparking.com:15098 for 60s
2012-06-12T05:01:56: 001-0: ztex_ufm1_15y1-04A36E0711-4: Error: Invalid length of string: Disabling device
2012-06-12T05:01:56: 001-0: ztex_ufm1_15y1-04A36E0711-2: Error: Invalid length of string: Disabling device
2012-06-12T05:01:57: 001-0: ztex_ufm1_15y1-04A36DE0AA-3: Error: Invalid length of string: Disabling device
2012-06-12T05:01:57: 001-0: ztex_ufm1_15y1-04A36DE0AA-4: Error: Invalid length of string: Disabling device
2012-06-12T05:02:11: 001-0: ztex_ufm1_15y1-04A36E0711-1: Error: Invalid length of string: Disabling device
...

These errors probably occur if the pool returns erroneous responses. BTCMiner does not handle these exception properly. (Correct behavior would be to disable the pool for 60s, ATM I'm not sure where these exception occur).

Quote
Instead I will try to keep at least 3 cores of that board running stable until Friday.

Return it, if you can't find the error.  (You have my email address because you already wrote me emails).

SamHa1n
Member
**
Offline Offline

Activity: 67


View Profile
June 14, 2012, 02:57:23 AM
 #796

Code:
001-0: ztex_ufm1_15y1-04A36DF26A-1: f=232.00MHz,  errorRate=0.23%,  maxErrorRate=1.83%,  hashRate=231.5MH/s,  submitted 11 new nonces,  luckFactor=0.90
001-0: ztex_ufm1_15y1-04A36DF26A-2: f=232.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=232.0MH/s,  submitted 15 new nonces,  luckFactor=1.15
001-0: ztex_ufm1_15y1-04A36DF26A-3: f=232.00MHz,  errorRate=0.21%,  maxErrorRate=1.87%,  hashRate=231.5MH/s,  submitted 18 new nonces,  luckFactor=0.94
001-0: ztex_ufm1_15y1-04A36DF26A-4: f=228.00MHz,  errorRate=0.00%,  maxErrorRate=0.59%,  hashRate=228.0MH/s,  submitted 17 new nonces,  luckFactor=0.94

Sweet!
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
June 14, 2012, 03:40:32 AM
 #797

Code:
001-0: ztex_ufm1_15y1-04A36DF26A-1: f=232.00MHz,  errorRate=0.23%,  maxErrorRate=1.83%,  hashRate=231.5MH/s,  submitted 11 new nonces,  luckFactor=0.90
001-0: ztex_ufm1_15y1-04A36DF26A-2: f=232.00MHz,  errorRate=0.00%,  maxErrorRate=0.00%,  hashRate=232.0MH/s,  submitted 15 new nonces,  luckFactor=1.15
001-0: ztex_ufm1_15y1-04A36DF26A-3: f=232.00MHz,  errorRate=0.21%,  maxErrorRate=1.87%,  hashRate=231.5MH/s,  submitted 18 new nonces,  luckFactor=0.94
001-0: ztex_ufm1_15y1-04A36DF26A-4: f=228.00MHz,  errorRate=0.00%,  maxErrorRate=0.59%,  hashRate=228.0MH/s,  submitted 17 new nonces,  luckFactor=0.94

Sweet!

Is this already Eldentyrell's bitstream???
SamHa1n
Member
**
Offline Offline

Activity: 67


View Profile
June 14, 2012, 04:47:19 AM
 #798

Is this already Eldentyrell's bitstream???

No, it is running ztex_ufm1_15y1 bitstream from ZtexBTCMiner-120417.
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
June 14, 2012, 04:57:45 AM
 #799

Is this already Eldentyrell's bitstream???

No, it is running ztex_ufm1_15y1 bitstream from ZtexBTCMiner-120417.

I was asking, because in a different thread, EldenTyrell wrote: "the first Bitstream I'll post will be a 230 MH/s design"

So, if the standard Ztex Bitstream already achieves 230 MH/s, what's the f***cking point of bothering with ET's clever scheme of only accepting encrypted start vectors, and then decrypting them in his Bitstream, and only generating encrypted golden nonces?

<confused>
mrb
Legendary
*
Offline Offline

Activity: 1120


View Profile WWW
June 14, 2012, 05:21:01 AM
 #800

EldenTyrell thought that Ztex's bitstream only achieved 213 Mh/s, so he decided to target only slightly higher as a proof-of-concept.
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 »
  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!