Owners of A4 General Discussion and Help

Steve Sokolowski wrote:

tradewiz wrote:

CritterDog wrote: Hi Steve I wrote Chis last night.. It seems my router has gone out completely. I am dead in the water on the A4 until I get a replacement which is on order.. Lets hope that was the problem all along.. Also on Monday I have another A4 arriving just one piece @ 136Mhs with control board. So that will put me around 400Mhs.. These A4s are going to be a hit. Way better then the A2. I expect to start seeing many come on line.. I got mine before the pre-order group.. So they are just now starting to roll in.. Be ready
Ok thanks and I wrote Chris a PM about the failing router. So we are in a waiting mode.

I am having the same issues as you with dropping hash rate. On Litecoinpool the units are stable around 265 MH. Working on different solutions now and will share when I get some conclusions. You may know it already but one control board can be used on 3 units, while they supply a control board for every 2 units.

I did some research into this and determined that exactly half the shares you would expect to be submitted are being submitted by these miners. At first, it sends all the shares, and then the share frequency gets cut in half. Since the hashrate is a 2h average, it appears to decline over the course of 2h when the drop was actually instantaneous.

There are a few possibilities for this that I think everyone should try, and depending on what is found, this fix may be a pool software bug, a miner configuration issue, or a defective miner.

The first theory is that these miners are "forgetting" the current difficulty and getting stuck at a previous difficulty setting. The pool only sends difficulty settings when a new difficulty is required, but perhaps these miners missed the difficulty set message. The broken router or some other connection problem would cause this problem by dropping packets. The result would be that the miners think the difficulty is twice as high as the pool does, and therefore they withhold shares that they should be paid for. The issue is more likely to occur here because the difficulty never changes at a litecoin-only pool.

To try to resolve this problem, there are several choices. The first is to try omitting the "d=" password argument, so that the difficulty gets changed by the system more often. The other is to try setting "d=32768," because all of the miners I've seen this issue with have their difficulty setting at 65536. Perhaps 32768 is the setting that these miners use as default when they miss an override setting. If the problem improves, then I will modify the software to send the same difficulty every 2m to all miners, so that the longest this issue could possibly occur for is 2m instead of permanently.

Another possibility is that one of the boards in the miner goes offline because of a hardware fault. The shares coming out of the miner would drop by half, and we would see the same statistics reported, but the cause would be a hardware error. This would be a more likely cause if it's always the same miners causing the problem every time.

Hi Steve,
I am glad you found this info.. I got my router bridge working again.. And went back up on on your pool but same problem.. It ran fine for about a hour and 15 mins then bam Hashrate dropped again.. I am mining over at litecoinpool right now and it has been holding around 253Mhs.. On this pool I have tried just about all of the diff settings with the same result. Good for around a hour then massive drop usually one hash card stops accepting shares completly. I have noticed when I set it on a high difficulty like 32768 what will happen is the miner will get stuck on a coin and stop submitting shares all together and I get a very high re-start rate that usually drops after 45 mins of mining but sometimes never drops and I get lots of orphans maybe because of high re-start .. This will happen set on dynamic also when it starts to get feed a very high difficulty it seems to start haveing problems. But the kicker is these problems do not duplicate on every start up is a bit diff...I have thought it was running great on just about every setting but then bam hash rate drops the hash cards swing wildly in cgminer they never seem to hold steady. On litecoin pool it starts the miners at a low hash rate and gradually over a hour they get up to speed. But if we can figure this out now that you have found this information I will try whatever you like.

Last night I also tried connecting just one unit direct to my att uverse router as opposed to the Bridge I had set up out in the garage that I thought was bad but now its working. I finally got into it and did a re-set last night.. So as of now I am up and running over at litecoinpool and as of this writing after about 8 hours of mining it is still sitting at 254.7Mhs-260Mhs.. Thanks for your help..PS.. Getting stale shares over at litecoinpool about .20 percent.. Here is what cgminer is reporting over at litecoinpool after 9 hours (5s):272.6M (avg):270.0Mh/s | A:144045648 R:327680 WU:236293.8/m

CritterDog wrote:

Steve Sokolowski wrote:

tradewiz wrote:
I am having the same issues as you with dropping hash rate. On Litecoinpool the units are stable around 265 MH. Working on different solutions now and will share when I get some conclusions. You may know it already but one control board can be used on 3 units, while they supply a control board for every 2 units.

I did some research into this and determined that exactly half the shares you would expect to be submitted are being submitted by these miners. At first, it sends all the shares, and then the share frequency gets cut in half. Since the hashrate is a 2h average, it appears to decline over the course of 2h when the drop was actually instantaneous.

There are a few possibilities for this that I think everyone should try, and depending on what is found, this fix may be a pool software bug, a miner configuration issue, or a defective miner.

The first theory is that these miners are "forgetting" the current difficulty and getting stuck at a previous difficulty setting. The pool only sends difficulty settings when a new difficulty is required, but perhaps these miners missed the difficulty set message. The broken router or some other connection problem would cause this problem by dropping packets. The result would be that the miners think the difficulty is twice as high as the pool does, and therefore they withhold shares that they should be paid for. The issue is more likely to occur here because the difficulty never changes at a litecoin-only pool.

To try to resolve this problem, there are several choices. The first is to try omitting the "d=" password argument, so that the difficulty gets changed by the system more often. The other is to try setting "d=32768," because all of the miners I've seen this issue with have their difficulty setting at 65536. Perhaps 32768 is the setting that these miners use as default when they miss an override setting. If the problem improves, then I will modify the software to send the same difficulty every 2m to all miners, so that the longest this issue could possibly occur for is 2m instead of permanently.

Another possibility is that one of the boards in the miner goes offline because of a hardware fault. The shares coming out of the miner would drop by half, and we would see the same statistics reported, but the cause would be a hardware error. This would be a more likely cause if it's always the same miners causing the problem every time.

Hi Steve,
I am glad you found this info.. I got my router bridge working again.. And went back up on on your pool but same problem.. It ran fine for about a hour and 15 mins then bam Hashrate dropped again.. I am mining over at litecoinpool right now and it has been holding around 253Mhs.. On this pool I have tried just about all of the diff settings with the same result. Good for around a hour then massive drop usually one hash card stops accepting shares completly. I have noticed when I set it on a high difficulty like 32768 what will happen is the miner will get stuck on a coin and stop submitting shares all together and I get a very high re-start rate that usually drops after 45 mins of mining but sometimes never drops and I get lots of orphans maybe because of high re-start .. This will happen set on dynamic also when it starts to get feed a very high difficulty it seems to start haveing problems. But the kicker is these problems do not duplicate on every start up is a bit diff...I have thought it was running great on just about every setting but then bam hash rate drops the hash cards swing wildly in cgminer they never seem to hold steady. On litecoin pool it starts the miners at a low hash rate and gradually over a hour they get up to speed. But if we can figure this out now that you have found this information I will try whatever you like.

Last night I also tried connecting just one unit direct to my att uverse router as opposed to the Bridge I had set up out in the garage that I thought was bad but now its working. I finally got into it and did a re-set last night.. So as of now I am up and running over at litecoinpool and as of this writing after about 8 hours of mining it is still sitting at 254.7Mhs-260Mhs.. Thanks for your help..PS.. Getting stale shares over at litecoinpool about .20 percent.. Here is what cgminer is reporting over at litecoinpool after 9 hours (5s):272.6M (avg):270.0Mh/s | A:144045648 R:327680 WU:236293.8/m

Hi CritterDog,

I talked with tradewiz and he tried h=50 g=off d=65536 and that works for him. But he doesn't seem to be able to reproduce the problems that you're having; is it possible that this particular miner is simply defective?

We'll find out more once tradewiz has his miners running overnight using the new settings. Why don't you try h=50 g=off d=4096? Perhaps your miners actually require a lower difficulty, and that will prevent them from getting set too high.

If tradewiz's miners all work fine by the morning, then we might want to look into whether the company may have sent you a non-working product.

-Steve

Ok will try it do you know what voltage he has set? I have been using 800mv and tried 810mv but no difference


Update: The setting recomended Lasted 1 hour 20 minutes and it was great during that time. I was watching cgminer the whole time and about 10:00pm one of my hash cards started dropping steady then at 10:10pm it was at zero. But just like before everything runs great and then just all a sudden I loose a hash card. It is not always the same card that fails. So before I say something to the seller saying I have a defective miner I need to be sure I have covered all possible reasons this might be happening.. I was comparing the cgminer submitted shares with what is reported on the site and they matched exactly the whole time. Going to raise the difficulty and try again

CritterDog wrote:Ok will try it do you know what voltage he has set? I have been using 800mv and tried 810mv but no difference

Update: The setting recomended Lasted 1 hour 20 minutes and it was great during that time. I was watching cgminer the whole time and about 10:00pm one of my hash cards started dropping steady then at 10:10pm it was at zero.

Have you been monitoring temperatures? Inno suggested in one of their releases that these devices would control hash frequency as a function of temperature, so I'm wondering if you're loosing a card because it's too hot.

"In addition, newly added system reliability features that allow for maximized performance under any condition, such as automatic temperature and frequency control, as well as DCDC-less automatic on-board chip pass/fail self-test, maximize system performance and avoid heat damage." from http://www.innosilicon.com/html/news/14.html

I've been running one of mine in short bursts of testing in my home office (I'm waiting on my 300A feed to be turned on tomorrow ) and have noticed that they run in the 45-50 degree C range even with lots of cool air on hand (<10 degrees C).

I've also been tinkering with the power and have dropped from 810mV to 780mV so far with no negative affects. This has dropped 50W at the wall and roughly 1-2 degrees C per card.

Cheers

Because of a communication error I was not able to change the settings last night, however I had a few different settings working.
Setting one: Running d=1024 on two units. They don't seem to "stall" after a few hours, but one of them only had 188 MH in hash this morning.
Two units running H=100 d=65536. One unit fell to 150 MH overnight (stalling) the other one stayed at around 250.
All units had g=off
So inconclusive. I will change the settings now to d=32768 H=50 and g=off

Would it be much work to change that restart as you mentioned Stephen so that on d=32768 it will send the same diff to miners every two mins?

Frode

tradewiz wrote:Because of a communication error I was not able to change the settings last night, however I had a few different settings working.
Setting one: Running d=1024 on two units. They don't seem to "stall" after a few hours, but one of them only had 188 MH in hash this morning.
Two units running H=100 d=65536. One unit fell to 150 MH overnight (stalling) the other one stayed at around 250.
All units had g=off
So inconclusive. I will change the settings now to d=32768 H=50 and g=off

Would it be much work to change that restart as you mentioned Stephen so that on d=32768 it will send the same diff to miners every two mins?

Frode

I can do that, but it will take a day and I want to release it on the development server first. I think what I'll do is ask you to connect to Dev, and then just give you some money on the side for the lost mining time on the production server. Expect to hear more about this later tonight.

Before then, I was thinking that perhaps you or CritterDog or someone else can try a different approach. Try "c=litecoin g=off." That setting should be exactly the same as litecoinpool or any pool that mines only litecoins.

We should see the exact same results as your mining there - no crashes. If we see crashes, then that implies that they are sending a different sequence of commands than we are, and I can connect a miner to them and see what they are doing.

Steve Sokolowski wrote:

tradewiz wrote:Because of a communication error I was not able to change the settings last night, however I had a few different settings working.
Setting one: Running d=1024 on two units. They don't seem to "stall" after a few hours, but one of them only had 188 MH in hash this morning.
Two units running H=100 d=65536. One unit fell to 150 MH overnight (stalling) the other one stayed at around 250.
All units had g=off
So inconclusive. I will change the settings now to d=32768 H=50 and g=off

Would it be much work to change that restart as you mentioned Stephen so that on d=32768 it will send the same diff to miners every two mins?

Frode

I can do that, but it will take a day and I want to release it on the development server first. I think what I'll do is ask you to connect to Dev, and then just give you some money on the side for the lost mining time on the production server. Expect to hear more about this later tonight.

Before then, I was thinking that perhaps you or CritterDog or someone else can try a different approach. Try "c=litecoin g=off." That setting should be exactly the same as litecoinpool or any pool that mines only litecoins.

We should see the exact same results as your mining there - no crashes. If we see crashes, then that implies that they are sending a different sequence of commands than we are, and I can connect a miner to them and see what they are doing.

Happy to try it on the Dev server. As you can see I changed all units to d=32768 H=50 g=off - that looks good so far lets see in a few hours.

Hi tradewiz,
How do I you see the temperature? On my software the temperature box is blank. Also what are your rejects looking like. Thanks


PS Oh wait I just found temperature..LOL Here is what I am running right now I was running 810. I am going to go down to 805 for a bit

STATS ID Elapse TEMP(AVG) TEMP(SOLO)
0 BA20 7h 37m 13s 2 45.00 45
0 1 BA21 7h 37m 13s 3 44.00 44
0 2 BA22 7h 37m 13s 4 46.00 46
0 3 BA23 7h 37m 13s 5 44.00 44

I wonder if the temperature is running high because the fan is pulling air instead of pushing it through the miner

CritterDog wrote:Hi tradewiz,
How do I you see the temperature? On my software the temperature box is blank. Also what are your rejects looking like. Thanks


PS Oh wait I just found temperature..LOL Here is what I am running right now I was running 810. I am going to go down to 805 for a bit

STATS ID Elapse TEMP(AVG) TEMP(SOLO)
0 BA20 7h 37m 13s 2 45.00 45
0 1 BA21 7h 37m 13s 3 44.00 44
0 2 BA22 7h 37m 13s 4 46.00 46
0 3 BA23 7h 37m 13s 5 44.00 44

I wonder if the temperature is running high because the fan is pulling air instead of pushing it through the miner

Hi Critterdog, those temps dont look that crazy. One of the units I have seem to have some temp issue, but one should be able to push them quite a bit higher than 45c. Maybe reduce the voltage slightly.
I have now been running with those settings I wrote about earlier for about 4.5 hours. So far it looks very good, much more stable and they are not "falling like flies". Would need some more time to confirm though. Will update the group later tonight.

CritterDog wrote:Hi tradewiz,
How do I you see the temperature? On my software the temperature box is blank. Also what are your rejects looking like. Thanks


PS Oh wait I just found temperature..LOL Here is what I am running right now I was running 810. I am going to go down to 805 for a bit

STATS ID Elapse TEMP(AVG) TEMP(SOLO)
0 BA20 7h 37m 13s 2 45.00 45
0 1 BA21 7h 37m 13s 3 44.00 44
0 2 BA22 7h 37m 13s 4 46.00 46
0 3 BA23 7h 37m 13s 5 44.00 44

I wonder if the temperature is running high because the fan is pulling air instead of pushing it through the miner

and to answer your question about rejects - very few.