Prohashing Mining Pool Forums

Not sure if this is what it is supposed to be or if this just happens to me on my L3+s.

I have Prohash setup as the first pool, with a specific coin static mined.
I have Prohash setup as the 2nd pool, with autoswitch pool, no static set.
I have a 3rd backup pool.

When the static coin the primary pool is mining goes offline from the pool.
Prohash then shows up as DEAD for both the primary and secondary.
It goes to the third pool.

Sometimes minutes later they will see Prohash is ALIVE again on the 2nd pool and join the autoswitch
Sometimes they will eventually see the 1st pool and move or at least try to go back to static. If it has too many statics on it.
Then it gets kicked from making the connection, again sees both prime and secondary pools for Prohash as dead again and moves down to the 3rd pool.
One miner stayed on the 3rd pool for 10+ hours and never saw prohash as ALIVE to connect to it, meanwhile 9 others are happily hashing away.

So does getting kicked from a static coin also force a kick from the whole system? I get the coin I wanted isn't up or has too many on it, but isnt the autoswitch non static option always up? Why is getting booted from a static coin killing the ability to connect to the pool at all?


And no its not a reboot, lag, or anything like that, I have 5 other miners sitting on the autoswitch pool that have yet to move, or lose connection during this whole time. I can log in and see them and their stats, and they do NOT lose connection on straight autopool mining, but when static coins drop out, they take the whole site offline for my L3+s.

What is the point of kicking someone from a static coin? Cant that person just go solo mine that coin by themselves anyway? What are they trying to prevent?

this post has been delete by its poster.

hashingpro wrote:Not sure if this is what it is supposed to be or if this just happens to me on my L3+s.

I have Prohash setup as the first pool, with a specific coin static mined.
I have Prohash setup as the 2nd pool, with autoswitch pool, no static set.
I have a 3rd backup pool.

When the static coin the primary pool is mining goes offline from the pool.
Prohash then shows up as DEAD for both the primary and secondary.
It goes to the third pool.

Sometimes minutes later they will see Prohash is ALIVE again on the 2nd pool and join the autoswitch
Sometimes they will eventually see the 1st pool and move or at least try to go back to static. If it has too many statics on it.
Then it gets kicked from making the connection, again sees both prime and secondary pools for Prohash as dead again and moves down to the 3rd pool.
One miner stayed on the 3rd pool for 10+ hours and never saw prohash as ALIVE to connect to it, meanwhile 9 others are happily hashing away.

So does getting kicked from a static coin also force a kick from the whole system? I get the coin I wanted isn't up or has too many on it, but isnt the autoswitch non static option always up? Why is getting booted from a static coin killing the ability to connect to the pool at all?


And no its not a reboot, lag, or anything like that, I have 5 other miners sitting on the autoswitch pool that have yet to move, or lose connection during this whole time. I can log in and see them and their stats, and they do NOT lose connection on straight autopool mining, but when static coins drop out, they take the whole site offline for my L3+s.

my backup prohashing pools work fine when my primary fails, so idk what the issue would be. its not a case of ph kicking you off the coin and kicking you off the whole network.

dog1965 wrote:Then just use all auto switching then you will have no problems. you know its very buggy software still in development. look at what d=2048 did.

The d=2048 issue isn't a bug. It worked as designed, and the design was in response to a previous bug. When the number of shares per second exceeded 5,000, the system automatically adjusted to provide good service to all miners without losing shares. In the past, the issue would have crashed the system.

The d=2048 issue isn't a bug. It worked as designed, and the design was in response to a previous bug which means its still a bug no ??

didnt mean to use the word bug I was just wondering why the system responds better to lower diffs ???

it would have crashed the system because it would have flooded the hell out of the server overloaded it like a ddos attack would ooooppppsss just learning sorry to ask these questions I know you guys work hard for all of us.

did you mean 5000 shares per second or minute ?

The d=2048 issue isn't a bug. It worked as designed, and the design was in response to a previous bug. When the number of shares per second exceeded 5,000, the system automatically adjusted to provide good service to all miners without losing shares. In the past, the issue would have crashed the system.[/quote]

Yes Steve, I was very impressed how well the system handled the load compared to past system limitations. I estimated that the current system capacity was somewhere less that 10,000 shares per second.

At 5000 shares per second the system could theoretically handle 37.5 TH/s or about 75,000 L3+ equivalent if everyone set their difficulty high enough to submit 4 shares per minute or less per miner.

The entire LTC hashrate is currently 28.5 TH/s or 57,000 L3+ equivalent.

Interesting that if all current 7000 workers on PH were using a difficulty that submitted 4 shares per minute or a 2 hour share count of 480 or less the system would only be processing 466 shares per second. So we would be currently be operating at less that 10% of the systems limit.

Maxumark wrote:The d=2048 issue isn't a bug. It worked as designed, and the design was in response to a previous bug. When the number of shares per second exceeded 5,000, the system automatically adjusted to provide good service to all miners without losing shares. In the past, the issue would have crashed the system.

Yes Steve, I was very impressed how well the system handled the load compared to past system limitations. I estimated that the current system capacity was somewhere less that 10,000 shares per second.

At 5000 shares per second the system could theoretically handle 37.5 TH/s or about 75,000 L3+ equivalent if everyone set their difficulty high enough to submit 4 shares per minute or less per miner.

The entire LTC hashrate is currently 28.5 TH/s or 57,000 L3+ equivalent.

Interesting that if all current 7000 workers on PH were using a difficulty that submitted 4 shares per minute or a 2 hour share count of 480 or less the system would only be processing 466 shares per second. So we would be currently be operating at less that 10% of the systems limit.[/quote]

WAKA would be nice to see a share per second and a share per minute display instead of that 2 hour share rate display.

would be nice to see a share per second and a share per minute display instead of that 2 hour share rate display that would really help as all thanks.