Have you seen this wiki post:
About [usb 1-1: clear tt 1 (8030) error -71]
Not all 703n have this problem. ignore this section if you never meet this error
There is a power issue with the 703N, The 703N is drawing to much power it caused the USB HUB chip on Senseless's FPGA controller to nearly destroy itself. See the destruction [ http://www.mysenselesslife.com/avalon/DSCN5212.JPG here]
In order to fix it you need had to power down the WiFi modem by disable it, use Eithernet instead. The kernel no long report -71 errors. thanks to senseless and others who help on identify the issue.
If your avalon was far away from your router. eithernet cable not fit. you may want try those kind of devices
TP-LINK TL-PA500(For mainland China) : http://www.tp-link.com.cn/product_adapter_263.html
TP-LINK TL-PA511 : http://www.tp-link.com/en/products/details/?model=TL-PA511
Topic: Avalon ASIC users thread - page 101. (Read 438516 times)
I am using WIFI...
Today (after 3 days of not checking the unit), i found it with LOAD of over 18, and hashing at 5xxx MH only...
I did a cgminer restart in system-services and hash rates returned to normal... (90.000MH), but load stayed over 15 ...
any ideas?
i checked kernel log, and looks normal until approx 3,5day into operation when bunch of entries like these show:
[316582.730000] usb 1-1: clear tt 1 (9031) error -71
[316584.160000] usb 1-1: clear tt 1 (8030) error -71
[316584.180000] usb 1-1: clear tt 1 (8030) error -71
[316584.190000] usb 1-1: clear tt 1 (8030) error -71
[316584.200000] usb 1-1: clear tt 1 (0030) error -71
[316589.840000] usb 1-1: clear tt 1 (8030) error -71
[316589.850000] usb 1-1: clear tt 1 (8030) error -71
[316589.860000] usb 1-1: clear tt 1 (8030) error -71
...
..
16824.590000] usb 1-1: clear tt 1 (8030) error -71
[316824.620000] usb 1-1: clear tt 1 (0030) error -71
[316828.000000] usb 1-1.1: USB disconnect, device number 3
[316828.150000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
[316828.630000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
[316828.810000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
[316828.850000] usb 1-1.1: Detected FT232RL
[316828.850000] usb 1-1.1: Number of endpoints 2
[316828.850000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
[316828.860000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
[316828.860000] usb 1-1.1: Setting MaxPacketSize 64
[316828.870000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[316830.890000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[316830.900000] ftdi_sio 1-1.1:1.0: device disconnected
No.
If you are using an ethernet connection, you must delete the WWAN device from the 'network' interfaces, and under network/wifi/avalon_ap make sure it shows 'wireless network is disabled'. Until I did both of these step I had the same problem.
Since this describes my problem, i tried this link below, but its not working no more?
ideas?
thanks,
Jaka
Regardless, 3 out of 4 of my batch 3 units end up with <10Gh/s after 3-12hrs of mining, some more frequently than others.
Could this behavior be due to the new temperature throttling feature? I have the default temperature limits of 70C target and 90C cutoff, but I don't see the temps going over 70C.
I'm having this same issue.
EDIT: so is the solution is to disable wifi or to implement the load monitor with auto-restart? Is this issue resolved?
For me, disabling/removing wifi/wlan wasn't enough.
If you already removed wifi and it's still a problem, look at your load avg, if it's spiking, then you probably need the auto-restart I posted at https://bitcointalk.org/index.phptopic=140539.msg2898478#msg2898478
If the load avg is low (under 1.0) then you should check all the connectors inside your avalon. I did have one of the wide ribbon cables wiggle loose (I probably bumped it installing the psu) and the result was about 20%+ lower peak hashes and odd hangups.
Today (after 3 days of not checking the unit), i found it with LOAD of over 18, and hashing at 5xxx MH only...
I did a cgminer restart in system-services and hash rates returned to normal... (90.000MH), but load stayed over 15 ...
any ideas?
i checked kernel log, and looks normal until approx 3,5day into operation when bunch of entries like these show:
[316582.730000] usb 1-1: clear tt 1 (9031) error -71
[316584.160000] usb 1-1: clear tt 1 (8030) error -71
[316584.180000] usb 1-1: clear tt 1 (8030) error -71
[316584.190000] usb 1-1: clear tt 1 (8030) error -71
[316584.200000] usb 1-1: clear tt 1 (0030) error -71
[316589.840000] usb 1-1: clear tt 1 (8030) error -71
[316589.850000] usb 1-1: clear tt 1 (8030) error -71
[316589.860000] usb 1-1: clear tt 1 (8030) error -71
...
..
16824.590000] usb 1-1: clear tt 1 (8030) error -71
[316824.620000] usb 1-1: clear tt 1 (0030) error -71
[316828.000000] usb 1-1.1: USB disconnect, device number 3
[316828.150000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
[316828.630000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
[316828.810000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
[316828.850000] usb 1-1.1: Detected FT232RL
[316828.850000] usb 1-1.1: Number of endpoints 2
[316828.850000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
[316828.860000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
[316828.860000] usb 1-1.1: Setting MaxPacketSize 64
[316828.870000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[316830.890000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[316830.900000] ftdi_sio 1-1.1:1.0: device disconnected
I notice that sometimes the total MHS5s hashrate drops to weird low number (like 4 digits only)... is this normal?
No.
If you are using an ethernet connection, you must delete the WWAN device from the 'network' interfaces, and under network/wifi/avalon_ap make sure it shows 'wireless network is disabled'. Until I did both of these step I had the same problem.
Since this describes my problem, i tried this link below, but its not working no more?
ideas?
thanks,
Jaka
One of my batch 3 avalons is performing very poorly due to a high HW errors. Unplugging all by one module, each module individually has between a 25 and 75% HW error rate at either 256 or 300Mhz.
This degraded performance starting after about 6 hours of mining at 300Mhz.
Is there anything I should try before trying to make a warranty claim?
I was calculating the hardware error rate wrong. It should be HW/LocalWork, which brings the error rates i'm seeing to a much more reasonable 1%.This degraded performance starting after about 6 hours of mining at 300Mhz.
Is there anything I should try before trying to make a warranty claim?
Regardless, 3 out of 4 of my batch 3 units end up with <10Gh/s after 3-12hrs of mining, some more frequently than others.
Could this behavior be due to the new temperature throttling feature? I have the default temperature limits of 70C target and 90C cutoff, but I don't see the temps going over 70C.
I'm having this same issue.
EDIT: so is the solution is to disable wifi or to implement the load monitor with auto-restart? Is this issue resolved?
For me, disabling/removing wifi/wlan wasn't enough.
If you already removed wifi and it's still a problem, look at your load avg, if it's spiking, then you probably need the auto-restart I posted at https://bitcointalk.org/index.phptopic=140539.msg2898478#msg2898478
If the load avg is low (under 1.0) then you should check all the connectors inside your avalon. I did have one of the wide ribbon cables wiggle loose (I probably bumped it installing the psu) and the result was about 20%+ lower peak hashes and odd hangups.
2x 4 module with 1250W PSU and firmware 20130723.
I'm using --avalon-auto --avalon-fan 90-100 and Chip Frequency: 350M, MHS5s shows ~105000 for both.
Questions:
1) Is there a way to determine if the chips are really hashing and not just producing what I know as "Hardware Errors"?
2) One of the machines only shows a number under "Fan3", the other one under "Fan1" and "Fan3". Need I be worried?
I'm using --avalon-auto --avalon-fan 90-100 and Chip Frequency: 350M, MHS5s shows ~105000 for both.
Questions:
1) Is there a way to determine if the chips are really hashing and not just producing what I know as "Hardware Errors"?
2) One of the machines only shows a number under "Fan3", the other one under "Fan1" and "Fan3". Need I be worried?
I flashed with 2013-08-10 yesterday, and my hashrate appears to have dropped. I was using 2013-07-03 earlier.
Yes there's a small regression in the auto code, I'm working on it now.
great:)
http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/
I flashed with 2013-08-10 yesterday, and my hashrate appears to have dropped. I was using 2013-07-03 earlier.
The --avalon-auto option already does precisely that: it uses a rolling average to adjust frequency rather than an all time average.
Yes and it would be nice if one could pull the current % value out of the cgminer process and display it on the stats page (which is what Ben is trying to accomplish)
The --avalon-auto option already does precisely that: it uses a rolling average to adjust frequency rather than an all time average.
I suspect that what SolarSilver would like is a %age of recent hardware errors (over the last 10000 diff1 shares for good precision maybe). SolarSilver, you might want to look at Zabbix and how to use "differential" items to compute this kind of probe.
Ah yes, finally somebody who can read minds ;-) Spot on and thank you for the explanation.
...however, what are you doing with that figure?
OK, at the risk of this being a trick question, I'm going to humiliate myself by saying "we display the value thus adding readability"?
The %age isn't really useful because it's an average over the whole cgminer process lifetime (recent changes won't be detected by looking at it on a long-lived cgminer process). If you restart cgminer on a regular basis, it becomes useful as any large variation is cause for concern and might warrant opening a case, inspecting and maybe resetting, reapplying thermal grease, repairing...
I suspect that what SolarSilver would like is a %age of recent hardware errors (over the last 10000 diff1 shares for good precision maybe). SolarSilver, you might want to look at Zabbix and how to use "differential" items to compute this kind of probe.
...however, what are you doing with that figure?
OK, at the risk of this being a trick question, I'm going to humiliate myself by saying "we display the value thus adding readability"?
overclock the lazy way
...however, what are you doing with that figure?
OK, at the risk of this being a trick question, I'm going to humiliate myself by saying "we display the value thus adding readability"?
...however, what are you doing with that figure?
OK, at the risk of this being a trick question, I'm going to humiliate myself by saying "we display the value thus adding readability"?
I don't have any intention of including the hw error % as a separate statistic. I also don't understand why you'd start deleting statistics from debug output like that, and I have to tell you your calculations are completely wrong.
You don't think adding the hw error% will cut down on all those questions from people what have difficulty interpreting the confusing numbers?
Not sure what you mean by deleting statistics from debug output and for the record, I am only referring to the thread by Ben Turas https://bitcointalksearch.org/topic/modification-to-show-hw-and-rejected-on-avalon-cgminer-status-page-254331
My math is even worse than his ;-)
It's probably
Code:
(100*hw/(diffaccepted+hw))
?
...however, what are you doing with that figure?
I don't have any intention of including the hw error % as a separate statistic. I also don't understand why you'd start deleting statistics from debug output like that, and I have to tell you your calculations are completely wrong.
You don't think adding the hw error% will cut down on all those questions from people what have difficulty interpreting the confusing numbers?
Not sure what you mean by deleting statistics from debug output and for the record, I am only referring to the thread by Ben Turas https://bitcointalksearch.org/topic/modification-to-show-hw-and-rejected-on-avalon-cgminer-status-page-254331
My math is even worse than his ;-)
It's probably
Code:
(100*hw/(diffaccepted+hw))
?
I don't have any intention of including the hw error % as a separate statistic. I also don't understand why you'd start deleting statistics from debug output like that, and I have to tell you your calculations are completely wrong.
Yes there's a small regression in the auto code, I'm working on it now.
great:)
are you considering to include showing %HW? :
https://bitcointalksearch.org/topic/modification-to-show-hw-and-rejected-on-avalon-cgminer-status-page-254331
its not a big problem to do it myself, but I would like it to be included
Here's updated firmware:
http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/
Hey Con,
not sure what you meant to modify between 20130813 and 20130813-1 (small regression in the auto code?) but could you integrate this in a future release?
Code:
--- cgminer.lua-20130813-1 Tue Aug 13 11:03:30 2013
+++ cgminer.lua-benturas Tue Aug 13 11:01:01 2013
@@ -39,6 +39,8 @@
for line in summary do
local elapsed, mhsav, foundblocks, getworks, accepted, rejected, hw, utility, discarded, stale, getfailures, localwork, remotefailures, networkblocks, totalmh, wu, diffaccepted, diffrejected, diffstale, bestshare = line:match("Elapsed=(%d+),MHS av=([%d%.]+),Found Blocks=(%d+),Getworks=(%d+),Accepted=(%d+),Rejected=(%d+),Hardware Errors=(%d+),Utility=([%d%.]+),Discarded=(%d+),Stale=(%d+),Get Failures=(%d+),Local Work=(%d+),Remote Failures=(%d+),Network Blocks=(%d+),Total MH=([%d%.]+),Work Utility=([%d%.]+),Difficulty Accepted=([%d]+)%.%d+,Difficulty Rejected=([%d]+)%.%d+,Difficulty Stale=([%d]+)%.%d+,Best Share=(%d+)")
if elapsed then
+ local mhw = string.format("%d(%1.2f%%)",hw,(100*hw/(diffaccepted+diffrejected+hw)));
+ local mrj = string.format("%d(%1.2f%%)",rejected,(100*rejected/(accepted+rejected)));
local str
local days
local h
@@ -72,8 +74,8 @@
['foundblocks'] = foundblocks,
['getworks'] = getworks,
['accepted'] = accepted,
- ['rejected'] = rejected,
- ['hw'] = hw,
+ ['rejected'] = mrj,
+ ['hw'] = mhw,
['utility'] = utility,
['discarded'] = discarded,
['stale'] = stale,
Does your reply "Not really, no." mean you are NOT putting it in ever, or that you have not thought about doing it yet and are considering it? Just confused ;-)
Yes there's a small regression in the auto code, I'm working on it now.
great:)
are you considering to include showing %HW? :
https://bitcointalksearch.org/topic/modification-to-show-hw-and-rejected-on-avalon-cgminer-status-page-254331
its not a big problem to do it myself, but I would like it to be included
Here's updated firmware:
http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/
Yes there's a small regression in the auto code, I'm working on it now.
great:)
are you considering to include showing %HW? :
https://bitcointalksearch.org/topic/modification-to-show-hw-and-rejected-on-avalon-cgminer-status-page-254331
its not a big problem to do it myself, but I would like it to be included
Yes there's a small regression in the auto code, I'm working on it now.
I gave it a test, but the actual firmware produces more HW errors on my B1 Avalon so its throtteling down to 330-340 MHz (starting @350).
So I'm back on 20130703 and again waving around 357 MHz
So I'm back on 20130703 and again waving around 357 MHz
Jump to: