kefky
Newbie
Offline
Activity: 50
Merit: 0
|
|
August 10, 2013, 06:36:33 PM |
|
If you haven't already, you have to delete/remove WiFi, not just disable/stop it. Network->Wifi->Remove
I've deleted but after few hours of mining I see the error message again: usb 1-1: clear tt 1 (8030) error -71 usb 1-1: clear tt 1 (8030) error -71 usb 1-1: clear tt 1 (8030) error -71
|
|
|
|
koxman
Newbie
Offline
Activity: 5
Merit: 0
|
|
August 10, 2013, 06:46:09 PM |
|
Did you restart avalon openwrt afert deleting wifi device?
That problem is described well. Wifi chip is taking too much power (maybe due to missing wifi antena).
I have had same problem and solved it by removing wifi interface and rebooting openwrt (wifi kernel module will be not loaded again).
|
|
|
|
kefky
Newbie
Offline
Activity: 50
Merit: 0
|
|
August 10, 2013, 06:58:44 PM |
|
Did you restart avalon openwrt afert deleting wifi device?
hmm I'm not sure I'll reboot it now.
|
|
|
|
crazyearner
Legendary
Offline
Activity: 1820
Merit: 1001
|
|
August 11, 2013, 12:05:51 AM |
|
i see some users running at 350mhz for batch 2?
is it possible to run at greater than 350mhz, at 360mh? for batch 1 with say 1250w 80+ gold psu?
previously it was running at 345mhz on a 1000w psu
so i got a new 1050w and was thinking if i should return and exchange it for a 1250w psu instead for greater hashing rate and make up the shortfall(downtime)
I am running batch 2 3 modual system with 860W Corsair AXi Series 80PLUS Platinum Modular Digital Power Supply am so far close to taking it to the mark of 400MHz per chip I have so far tested upto 360MHz rock solid and thinking to increase and temps at a good rate too then again I have also done air flow mods to it to improve channeling of airflow to the modules. If you are on a 4x moudal I am unsure what to set too as I have seen a lot of people having problems taking above 340MHz due to amount of power it sucks up. I am running 3 at 360 to 365MHz and only taking 760 intake feed of power and using only 700 of it so this Platinum psu is very energy effective while temps never going over 50c Am also wondering if I can get to that target of 400MH/s per chip but even then that's pushing it way too much but will see as I have full monitor status of unit of how much each modual is sucking up and how much amps its using. was wondering how long it'd take people to notice ( and more importantly share the constant that we've released on github.) the number you are all aiming for is 450 of course, that's not really possible on just air cooling.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 11, 2013, 12:24:55 AM |
|
Just a 'somewhat' on topic aside ... I have a BitBurner XX with 20 Avalon chips in it. It runs at 400Mhz with about 1.4% HW BTB 0: 48/ 48C 1223mV | 10.86G/7.669Gh/s | A:149590 R:748 HW:2151 WU:108.6/m
24hrs runtime I put it up to 450MHz and it was about 50% but appropriate cooling would have probably resolved that also. So indeed the chips can do 450MHz Using my numbers above: (7.669 / 20) * 240 = 92GH/s at 400MHz
|
|
|
|
Ghost of USD
Newbie
Offline
Activity: 31
Merit: 0
|
|
August 11, 2013, 12:50:05 AM |
|
If you haven't already, you have to delete/remove WiFi, not just disable/stop it. Network->Wifi->Remove
I've deleted but after few hours of mining I see the error message again: usb 1-1: clear tt 1 (8030) error -71 usb 1-1: clear tt 1 (8030) error -71 usb 1-1: clear tt 1 (8030) error -71 Unload the wifi kernel modules. log into ssh and rmmod the following: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 then cd into /etc/modules.d and comment out, or if you're confident enough, delete the following files in that directory, to prevent them from being loaded on reboot: 20-cfg80211 21-mac80211 26-ath 27-ath9k-common 28-ath9k
|
|
|
|
Ytterbium
|
|
August 11, 2013, 02:41:01 AM |
|
So indeed the chips can do 450MHz
Using my numbers above: (7.669 / 20) * 240 = 92GH/s at 400MHz
You increased the voltage in order to do that, right?
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 11, 2013, 02:45:49 AM |
|
So indeed the chips can do 450MHz
Using my numbers above: (7.669 / 20) * 240 = 92GH/s at 400MHz
You increased the voltage in order to do that, right? No I left it at the 1200mV default for the current run. As you can see it reads 1223mV - but I'm not exactly sure how accurate that is.
|
|
|
|
mdbssm
|
|
August 11, 2013, 02:52:07 AM |
|
So indeed the chips can do 450MHz
Using my numbers above: (7.669 / 20) * 240 = 92GH/s at 400MHz
You increased the voltage in order to do that, right? No I left it at the 1200mV default for the current run. As you can see it reads 1223mV - but I'm not exactly sure how accurate that is. Very nice Kano. Any idea if this would be possible with batch 3 avalon hardware? With better cooling of course. Like 2x 120mm 6000rpm delta fans in the place of the stock 120mm fans in a batch 3 unit.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 11, 2013, 03:06:37 AM |
|
So indeed the chips can do 450MHz
Using my numbers above: (7.669 / 20) * 240 = 92GH/s at 400MHz
You increased the voltage in order to do that, right? No I left it at the 1200mV default for the current run. As you can see it reads 1223mV - but I'm not exactly sure how accurate that is. Very nice Kano. Any idea if this would be possible with batch 3 avalon hardware? With better cooling of course. Like 2x 120mm 6000rpm delta fans in the place of the stock 120mm fans in a batch 3 unit. Well the API stats should pretty much answer that for you. Though, from what I understand about Avalons, you need to pay attention to what PSU you have also. These changes of course use more power. I'd certainly suggest monitoring it at the wall vs the PSU you have and then adjust the frequency as you go and pay close attention to that and the temperature. I added to the API in 3.3.2 the option to change the frequency as it is running ...
|
|
|
|
tarui
|
|
August 11, 2013, 03:52:24 AM |
|
So indeed the chips can do 450MHz
Using my numbers above: (7.669 / 20) * 240 = 92GH/s at 400MHz
You increased the voltage in order to do that, right? No I left it at the 1200mV default for the current run. As you can see it reads 1223mV - but I'm not exactly sure how accurate that is. Very nice Kano. Any idea if this would be possible with batch 3 avalon hardware? With better cooling of course. Like 2x 120mm 6000rpm delta fans in the place of the stock 120mm fans in a batch 3 unit. Well the API stats should pretty much answer that for you. Though, from what I understand about Avalons, you need to pay attention to what PSU you have also. These changes of course use more power. I'd certainly suggest monitoring it at the wall vs the PSU you have and then adjust the frequency as you go and pay close attention to that and the temperature. I added to the API in 3.3.2 the option to change the frequency as it is running ... how much power does it use at 400mhz?
|
|
|
|
BitCoiner2012
|
|
August 11, 2013, 03:56:48 AM |
|
Lowering of frequency with auto avalon is a result of it trying to maintain a certain temperature as well, yes?
What would be the conclusion if a particular machine hashes at over 80, but slowly declines to the mid 70s lowering frequency? Lack of adequate cooling?
|
BTC Long.
|
|
|
Ytterbium
|
|
August 11, 2013, 04:20:17 AM |
|
So indeed the chips can do 450MHz
Using my numbers above: (7.669 / 20) * 240 = 92GH/s at 400MHz
You increased the voltage in order to do that, right? No I left it at the 1200mV default for the current run. As you can see it reads 1223mV - but I'm not exactly sure how accurate that is. Huh. Increasing the clockrate on my B2 over a certain point only increases HW errors. I wonder what the difference is between these boards and the ones Avalon shipped with.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 11, 2013, 04:29:20 AM |
|
Lowering of frequency with auto avalon is a result of it trying to maintain a certain temperature as well, yes?
What would be the conclusion if a particular machine hashes at over 80, but slowly declines to the mid 70s lowering frequency? Lack of adequate cooling?
FYI: Aside: The GH/s reported by the avalon code is not the device hash rate, it is the 1diff share find rate. Thus it will also change with luck.
|
|
|
|
BitCoiner2012
|
|
August 11, 2013, 04:58:12 AM |
|
Lowering of frequency with auto avalon is a result of it trying to maintain a certain temperature as well, yes?
What would be the conclusion if a particular machine hashes at over 80, but slowly declines to the mid 70s lowering frequency? Lack of adequate cooling?
FYI: Aside: The GH/s reported by the avalon code is not the device hash rate, it is the 1diff share find rate. Thus it will also change with luck. But the pool shows sustained lowering of submitted shares, the device seems to agree, and the MHashes are lowering. You are saying that even if it said hashing 3ghash, that's not the "actual hash rate"? Where can I find accurate data on the machine then? Or maybe I misunderstood your reply.
|
BTC Long.
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 11, 2013, 07:06:09 AM Last edit: August 11, 2013, 07:21:31 AM by kano |
|
Lowering of frequency with auto avalon is a result of it trying to maintain a certain temperature as well, yes?
What would be the conclusion if a particular machine hashes at over 80, but slowly declines to the mid 70s lowering frequency? Lack of adequate cooling?
FYI: Aside: The GH/s reported by the avalon code is not the device hash rate, it is the 1diff share find rate. Thus it will also change with luck. But the pool shows sustained lowering of submitted shares, the device seems to agree, and the MHashes are lowering. You are saying that even if it said hashing 3ghash, that's not the "actual hash rate"? Where can I find accurate data on the machine then? Or maybe I misunderstood your reply. With an avalon - the 'actual' hash rate is not available. The hardware is ... for want of a better word ... "difficult" to determine the actual hash rate. (maybe a better word is "crap") Yes if the pool is indeed showing a generally decreasing hash rate over short interval measurements, then your device is slowing down. However, of course, short interval measurements are also unreliable and affected by luck, so you would need a definite clear reduction over many samples over that time period to be sure it was systematic and not luck. However, my point is that the screen average (or API "MHS av") will be affected by "luck" and the higher your work difficulty, the more obvious that effect will be.It may or may not be the case for your observations, but it's just that there is more than one possibility.
|
|
|
|
-ck
Legendary
Offline
Activity: 4256
Merit: 1644
Ruu \o/
|
|
August 11, 2013, 07:08:05 AM |
|
However, my point is that the screen average (or API "MHS av") will be affected by "luck" and the higher your work difficulty, the more obvious that effect will be.
That's not quite correct. The avalon hashmeter is indeed based on share return, but it's based on diff1 return so luck affects it, but difficulty does not.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
tarui
|
|
August 11, 2013, 03:25:40 PM |
|
Is it possible to connect the lan port to a mobile Internet device so that it can hash in public places?
|
|
|
|
koxman
Newbie
Offline
Activity: 5
Merit: 0
|
|
August 11, 2013, 05:09:24 PM |
|
Is it possible to connect the lan port to a mobile Internet device so that it can hash in public places?
Yes you can.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3080
|
|
August 11, 2013, 05:33:09 PM |
|
Is it possible to connect the lan port to a mobile Internet device so that it can hash in public places?
Yes you can. soon we will have Pirate Bay inspired zepellin balloons mining on the mesh-net
|
Vires in numeris
|
|
|
|