The speeds that this board is currently getting is with a rather high room ambient temp (~27C), high enough to send my BFL single into a very routine throttle down.
Excuse the off-topic reply, but if your Single is throttling more often than once per 10 minutes, you may be able to mitigate that (and gain a higher net hashrate) by flashing a slower bitstream into it. See: https://bitcointalksearch.org/topic/m.945019.
Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards - page 11. (Read 182443 times)
June 14, 2012, 12:37:41 PM
June 14, 2012, 11:34:45 AM
The speeds that this board is currently getting is with a rather high room ambient temp (~27C), high enough to send my BFL single into a very routine throttle down.
Very impressive.
June 14, 2012, 07:05:23 AM
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?
Maybe using that bitstream will allow some non ztex boards to run at speeds as if they were...
The speeds that this board is currently getting is with a rather high room ambient temp (~27C), high enough to send my BFL single into a very routine throttle down.
June 14, 2012, 05:02:00 AM
My Quad is Performing in Same lvls
June 14, 2012, 03:48:14 AM
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
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???
Code:
001-1: ztex_ufm1_15y1-0012110013-1: f=232.00MHz, errorRate=0.48%, maxErrorRate=0.97%, hashRate=230.9MH/s, submitted 13 new nonces, luckFactor=0.88
001-1: ztex_ufm1_15y1-0012110013-2: f=232.00MHz, errorRate=0.60%, maxErrorRate=1.82%, hashRate=230.6MH/s, submitted 16 new nonces, luckFactor=1.04
001-1: ztex_ufm1_15y1-0012110013-3: f=236.00MHz, errorRate=0.07%, maxErrorRate=0.54%, hashRate=235.8MH/s, submitted 13 new nonces, luckFactor=0.71
001-1: ztex_ufm1_15y1-0012110013-4: f=228.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=228.0MH/s, submitted 14 new nonces, luckFactor=0.87
001-1: ztex_ufm1_15y1-0012110013-2: f=232.00MHz, errorRate=0.60%, maxErrorRate=1.82%, hashRate=230.6MH/s, submitted 16 new nonces, luckFactor=1.04
001-1: ztex_ufm1_15y1-0012110013-3: f=236.00MHz, errorRate=0.07%, maxErrorRate=0.54%, hashRate=235.8MH/s, submitted 13 new nonces, luckFactor=0.71
001-1: ztex_ufm1_15y1-0012110013-4: f=228.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=228.0MH/s, submitted 14 new nonces, luckFactor=0.87
I have one super fast quad too. But the average hashrate is only 859 MHashes/s per quad.
Measurements per batch which are more meaningful than the average rating can be found in the initial posting of this thread. Some of the newer FPGA's even achieve almost 240 MH/s.
June 14, 2012, 01:33:52 AM
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
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???
Code:
001-1: ztex_ufm1_15y1-0012110013-1: f=232.00MHz, errorRate=0.48%, maxErrorRate=0.97%, hashRate=230.9MH/s, submitted 13 new nonces, luckFactor=0.88
001-1: ztex_ufm1_15y1-0012110013-2: f=232.00MHz, errorRate=0.60%, maxErrorRate=1.82%, hashRate=230.6MH/s, submitted 16 new nonces, luckFactor=1.04
001-1: ztex_ufm1_15y1-0012110013-3: f=236.00MHz, errorRate=0.07%, maxErrorRate=0.54%, hashRate=235.8MH/s, submitted 13 new nonces, luckFactor=0.71
001-1: ztex_ufm1_15y1-0012110013-4: f=228.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=228.0MH/s, submitted 14 new nonces, luckFactor=0.87
001-1: ztex_ufm1_15y1-0012110013-2: f=232.00MHz, errorRate=0.60%, maxErrorRate=1.82%, hashRate=230.6MH/s, submitted 16 new nonces, luckFactor=1.04
001-1: ztex_ufm1_15y1-0012110013-3: f=236.00MHz, errorRate=0.07%, maxErrorRate=0.54%, hashRate=235.8MH/s, submitted 13 new nonces, luckFactor=0.71
001-1: ztex_ufm1_15y1-0012110013-4: f=228.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=228.0MH/s, submitted 14 new nonces, luckFactor=0.87
I have one super fast quad too. But the average hashrate is only 859 MHashes/s per quad.
June 14, 2012, 12:24:44 AM
if I have read correctly ztex will go up to 240mhz if error rate is okay.
June 14, 2012, 12:21:01 AM
EldenTyrell thought that Ztex's bitstream only achieved 213 Mh/s, so he decided to target only slightly higher as a proof-of-concept.
June 13, 2012, 11:57:45 PM
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?
June 13, 2012, 11:47:19 PM
Is this already Eldentyrell's bitstream???
No, it is running ztex_ufm1_15y1 bitstream from ZtexBTCMiner-120417.
June 13, 2012, 10:40:32 PM
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
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???
June 13, 2012, 09:57:23 PM
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
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!
June 13, 2012, 07:00:42 AM
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-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).
June 13, 2012, 06:54:39 AM
The third fpga on his quad is failing. All the others behave normal 
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
Was just pointing Out that the third fpga of the User was failing.
Sorry, this was not addressed to you.
June 13, 2012, 06:45:29 AM
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?
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.
June 13, 2012, 06:40:19 AM
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).
June 12, 2012, 03:00:13 PM
The third fpga on his quad is failing. All the others behave normal
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
Was just pointing Out that the third fpga of the User was failing.
June 12, 2012, 11:25:47 AM
for the early morning problem..
my log says dsl connection was (re)established
miner was startet (not regarding the login data) with that one:
resulting finally in full stop with error msg
after some problem with pool data / a string (not sure how to read that properly):
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.
my log says dsl connection was (re)established
Quote
12.06.2012, 04:31
- so I dont think that was the problem 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
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.
June 12, 2012, 10:27:53 AM
And here can you find the patch: https://bitcointalksearch.org/topic/m.957636
June 12, 2012, 09:50:26 AM
@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
*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.
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
*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.
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
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.
Jump to: