Anyone know what this is
[ 11.730000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[ 15.030000] device eth0 entered promiscuous mode
[ 15.380000] eth0: link up (100Mbps/Full duplex)
[ 15.380000] br-lan: port 1(eth0) entered forwarding state
[ 15.390000] br-lan: port 1(eth0) entered forwarding state
[ 17.390000] br-lan: port 1(eth0) entered forwarding state
[ 24.990000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 25.010000] ftdi_sio 1-1.1:1.0: device disconnected
Now wont connect up?
Topic: Avalon ASIC users thread - page 116. (Read 438516 times)
That is definitely far more than you should be getting. There is a good chance you're submitting heaps of duplicates which may also be a different form of instability that the auto mode can't check for. Try setting a lower maximum speed if you're using auto mode because clearly you're not doing 82GH of useful work.
I also have 11% of rejected shares while HW is ~1.3%
Max temp is 48 C, ambient 28 C.
My command line is: --quiet --avalon-auto --avalon-freq 282-375 --avalon-cutoff 60
Last night it somehow stopped dumping rejected shares and so was till today, then I've caught blackout. After resuming it still generates 11% reject shares working at 352 MHz (autotuned).
In my case 11% rejects caused by the auto-tuning process itself. As cgminer starts climbing from 282 to its stable 350 it dumps rejects all the way up
Once it settles at the 350-352 - rejects immediately stops to grow.Now my workaround for this (till you'll have a chance to investigate it) is just set --avalon-freq 340-375. It quickly climbs this 10-12 MHz up and the rejects % is just fine.
P.S. I use http://mmpool.bitparking.com just in case you'd try to reproduce it on your side. But it also the same picture with the Slush's pool.
is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.
Opened it up, checked it and looked good. Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.
In the cgminer stats log, does any value for the match_work_count stand out?
When the ac is on it keeping the temps under 41 the match_work values are pretty similar. Once I pull the ac off and the temp climbs above 41 their is a big difference in values from one to another.
I assume that each of the 24 numbers corresponds to a card of 10 chips, and that swapping the worst one out will be beneficial.
So I attempted to upgrade the power supply on my 3-board Avalon...
It had a 750w Corsair in it already so I don't think it actually needed to be upgraded unless I decided to add a 4th board. I was getting a lot of invalid shares, though, so I figured a bigger power supply might help.
I bought a 850w OCZ ZW power supply and installed it and it didn't work! I'm not sure what was wrong. I could connect to the Avalon through the web interface, log in, and edit the configuration but the fans never spun up and it never started hashing.
I thought maybe I had broken it but I put the old power supply back in and it was fine.
I thought maybe I was missing a cable or something but I guess I just had a defective supply?
I plugged in:
The very wide main connector
The 8 pin connector that said "CPU" on it
The two red cables (GPU) that plug into the side of the supply.
The supply also had an additional connector, 8-pin but a different layout from the CPU power, I believe that looks like it would fit into another connector across from the CPU connector. It wasn't plugged in with the old power supply, so i didn't plug it in for the new one. Not sure what its for. Power supplies were always a mystery to me.
I wish there was a schematic or something that explained it. I haven't been able to find one for the Avalon miner.
PS Damn the Chinese engineer who designed the screws on that case!
It had a 750w Corsair in it already so I don't think it actually needed to be upgraded unless I decided to add a 4th board. I was getting a lot of invalid shares, though, so I figured a bigger power supply might help.
I bought a 850w OCZ ZW power supply and installed it and it didn't work! I'm not sure what was wrong. I could connect to the Avalon through the web interface, log in, and edit the configuration but the fans never spun up and it never started hashing.
I thought maybe I had broken it but I put the old power supply back in and it was fine.
I thought maybe I was missing a cable or something but I guess I just had a defective supply?
I plugged in:
The very wide main connector
The 8 pin connector that said "CPU" on it
The two red cables (GPU) that plug into the side of the supply.
The supply also had an additional connector, 8-pin but a different layout from the CPU power, I believe that looks like it would fit into another connector across from the CPU connector. It wasn't plugged in with the old power supply, so i didn't plug it in for the new one. Not sure what its for. Power supplies were always a mystery to me.
I wish there was a schematic or something that explained it. I haven't been able to find one for the Avalon miner.
PS Damn the Chinese engineer who designed the screws on that case!
is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.
Opened it up, checked it and looked good. Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.
In the cgminer stats log, does any value for the match_work_count stand out?
When the ac is on it keeping the temps under 41 the match_work values are pretty similar. Once I pull the ac off and the temp climbs above 41 their is a big difference in values from one to another.
I get a REALLY large number of invalid shares with my Avalon.
I'm not sure whats going on. It's not consistent.
One day I'll be mining and I'll get 99+% valid shares and the next day or two it will only be 88% valid shares.
I've tried mining on Ozcoin and 50btc and it seems to be bad on both.
I don't think it is my network because my jalapenos only get <1% invalid shares.
I'm using the dynamically adjusting frequency and it usually settle at about 352 MHz or so and 82 GH/s on average. Of course, according to the pool, I'm only getting 70 GH/s or so due to all the invalid shares.
I have an AC feeding directly into the intake on the Avalon and no temperature gets above 48 or 49 or so (very rarely 50).
What could be wrong?
It seems like I have way more than other Avalon users, at least from what I've seen on Ozcoin. Most of them have only a couple percent invalid shares at most, while I will have 12 or 13% invalid shares. Right now I'm standing at about 94% efficiency on average, that's with 400,000 invalid shares in the less than a week I've been mining there.
I also have 11% of rejected shares while HW is ~1.3%
Max temp is 48 C, ambient 28 C.
My command line is: --quiet --avalon-auto --avalon-freq 282-375 --avalon-cutoff 60
Last night it somehow stopped dumping rejected shares and so was till today, then I've caught blackout. After resuming it still generates 11% reject shares working at 352 MHz (autotuned).
It's odd in that it will run for a day or two and get 99.5% efficiency (about 0.5% rejected shares) and then all of a sudden (might coincide with a new round) it will start getting 10+% rejected shares for a day. I tried hard rebooting that when it happens and I'm hoping that might fix it.
I'm also going to play around with different clocks and see if that helps. It usually settles about 352 with max temps at around 49. It's strange that it can run like that for a day before the invalid shares start though. I've determined it is not likely to be my network as my 2 jalapenos only get <0.5% invalid shares.
is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.
Opened it up, checked it and looked good. Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.
In the cgminer stats log, does any value for the match_work_count stand out?
is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.
Opened it up, checked it and looked good. Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.
is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.
Yesterday my avalon started showing a super high number of hw. Almost 75% of the accepted diff1a shares.
For instance shares 100000 hw 75000. Any ideas on what to check?
For instance shares 100000 hw 75000. Any ideas on what to check?
Found out that running any temps higher then 41 starts giving hw higher then 70%. Im using current firmware from cgminer and using ethernet not wifi. Anyone able to help or any have ideas.
What clocks / temps?
Pretty much at any clock, I have tried 282 and once it climbs over 40-41 then it starts with high errors. I currently have an airconditioner by it and running stable on 300 clock with temps at 40 and hw errors less then 2%. If I move the airconditioner the hw starts climbing fast.
Yesterday my avalon started showing a super high number of hw. Almost 75% of the accepted diff1a shares.
For instance shares 100000 hw 75000. Any ideas on what to check?
For instance shares 100000 hw 75000. Any ideas on what to check?
Found out that running any temps higher then 41 starts giving hw higher then 70%. Im using current firmware from cgminer and using ethernet not wifi. Anyone able to help or any have ideas.
What clocks / temps?
Yesterday my avalon started showing a super high number of hw. Almost 75% of the accepted diff1a shares.
For instance shares 100000 hw 75000. Any ideas on what to check?
For instance shares 100000 hw 75000. Any ideas on what to check?
Found out that running any temps higher then 41 starts giving hw higher then 70%. Im using current firmware from cgminer and using ethernet not wifi. Anyone able to help or any have ideas.
That is definitely far more than you should be getting. There is a good chance you're submitting heaps of duplicates which may also be a different form of instability that the auto mode can't check for. Try setting a lower maximum speed if you're using auto mode because clearly you're not doing 82GH of useful work.
I also have 11% of rejected shares while HW is ~1.3%
Max temp is 48 C, ambient 28 C.
My command line is: --quiet --avalon-auto --avalon-freq 282-375 --avalon-cutoff 60
Last night it somehow stopped dumping rejected shares and so was till today, then I've caught blackout. After resuming it still generates 11% reject shares working at 352 MHz (autotuned).
today I have experienced a "bigger problem" for the second time since I have it
the machine was unresponsive on web interface, so I thought it has crashed completely and would need a physical restart, which is very bad for me
however, I tried to connect to SSH and somehow it worked, but extremely slowly, took my a couple of minutes but finally I was able to type reboot command and reboot the machine, which it did and everything is OK again
so, if someone has this totally unresponsive machine, try SSH and be very very patient, it may come up
funny thing is that it did not stop hashing until I reboot it - i.e. even in this strange unresponsive state, it was doing its job, just web interface could not be reached and SSH extremely hardly
since the operation with the whole machine was impossibly slow I could not analyze any logs before reboot, so I have no idea what happened
Out of mem - free?the machine was unresponsive on web interface, so I thought it has crashed completely and would need a physical restart, which is very bad for me
however, I tried to connect to SSH and somehow it worked, but extremely slowly, took my a couple of minutes but finally I was able to type reboot command and reboot the machine, which it did and everything is OK again
so, if someone has this totally unresponsive machine, try SSH and be very very patient, it may come up
funny thing is that it did not stop hashing until I reboot it - i.e. even in this strange unresponsive state, it was doing its job, just web interface could not be reached and SSH extremely hardly
since the operation with the whole machine was impossibly slow I could not analyze any logs before reboot, so I have no idea what happened
WiFi disabled yes/no
dmesg?
just a few basic commands will tell you what went wrong. Make sure you post the output next time
thanks, will try next time
wifi disabled -> yes
I can watch MHS5s slowly drop to 0, and eventually cgminer-monitor will restart cgminer. Why is cgminer stopping hashing?
Common reasons:Wifi kernel problem
Overdoing the overclocking
Pool failure and the cgminer-monitor watchdog is trigger happy and kills cgminer when all it's doing is waiting for a pool to come back online.
FPGA failure in the avalon.
If the fans stop running entirely, does that indicate FPGA failure?
My Batch 1 unit does this sometimes. I now have a script that queries the API, and if it has a zero hashrate for too long, it will call the connected Web Power Switch to cycle the power on the unit, which always brings it back up. (I do have to have it leave the power off for a full 30 seconds.)
Well today power-cycleing the unit did not bring it back to life. I found it stuck repeatedly cycling. The blue LED on the TP-Link would light, and the red LED on the front would come on, but the fans never spun up.
I opened it up, and out came the stock Antec EarthWatts 650 power supply, and in went a new Corsair HX850. It was a tight fit. I had to dismount the PDU board, and reinstall it after the PSU went in.
I'm happy to report that it's once again hashing away. --avalon-auto has now settled on 360MHz and it's been running for over an hour now, whereas before I had to limit it to 345 to keep things stable.
I'm glad I thought ahead to buy that PSU as a spare for exactly this kind of situation. I guess I should now buy another spare.
http://www.newegg.com/Product/Product.aspx?Item=N82E16817139011
I get a REALLY large number of invalid shares with my Avalon.
I'm not sure whats going on. It's not consistent.
One day I'll be mining and I'll get 99+% valid shares and the next day or two it will only be 88% valid shares.
I've tried mining on Ozcoin and 50btc and it seems to be bad on both.
I don't think it is my network because my jalapenos only get <1% invalid shares.
I'm using the dynamically adjusting frequency and it usually settle at about 352 MHz or so and 82 GH/s on average. Of course, according to the pool, I'm only getting 70 GH/s or so due to all the invalid shares.
I have an AC feeding directly into the intake on the Avalon and no temperature gets above 48 or 49 or so (very rarely 50).
What could be wrong?
It seems like I have way more than other Avalon users, at least from what I've seen on Ozcoin. Most of them have only a couple percent invalid shares at most, while I will have 12 or 13% invalid shares. Right now I'm standing at about 94% efficiency on average, that's with 400,000 invalid shares in the less than a week I've been mining there.
I also have 11% of rejected shares while HW is ~1.3%
Max temp is 48 C, ambient 28 C.
My command line is: --quiet --avalon-auto --avalon-freq 282-375 --avalon-cutoff 60
Last night it somehow stopped dumping rejected shares and so was till today, then I've caught blackout. After resuming it still generates 11% reject shares working at 352 MHz (autotuned).
in case you have multiple pools in the list that switch between you will add up diff1shares then do the calculation.
Also, I find setting up miner.php an easier method of lookin at the data =)
Also, I find setting up miner.php an easier method of lookin at the data =)
I had a maximum temp of 51C last night, and my HW values were almost as high as my accepted. The past week, it has stayed below 50 during routine operation.
Are you talking about "Accepted" vs "HW" or "Diff1Shares" vs "HW"?
"Accepted" I don't see a number labeled "Diff1Shares" in the status panel.
it's there. look harder. you should be using that as part of your denominator.
I had a maximum temp of 51C last night, and my HW values were almost as high as my accepted. The past week, it has stayed below 50 during routine operation.
Are you talking about "Accepted" vs "HW" or "Diff1Shares" vs "HW"?
"Accepted" I don't see a number labeled "Diff1Shares" in the status panel.
I had a maximum temp of 51C last night, and my HW values were almost as high as my accepted. The past week, it has stayed below 50 during routine operation.
Are you talking about "Accepted" vs "HW" or "Diff1Shares" vs "HW"?
Jump to: