[ANN] profit switching auto-exchanging pool - www.middlecoin.com

[h2odysee]

So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying.

Yeah. I don't believe it affects profits. But lots of people are saying it is. So I'm still thinking about it to see if I'm wrong.


With https://github.com/CryptoManiac/stratum-mining, I'm getting:

  File "/home/pushpool/stratum-mining-novacoin-testnet-cryptomaniac2/mining/DBInterface.py", line 33, in connectDB
    if settings.DATABASE_DRIVER == "sqlite":
exceptions.AttributeError: 'module' object has no attribute 'DATABASE_DRIVER'

I must have some module installed wrong. Did you get that?

Thank you so much for the suggestion on which branch to use. I was spinning my wheels trying to get a few others to work.

[1714199834]

1714199834

[1714199834]

1714199834

[1714199834]

1714199834

[1714199834]

1714199834

[fredeq]

Not sure what we are mining right now, but its the coin that is giving me 1,7M instead of 2M.

WU in cgminer: 1680 instead of 1860. Diff 214k

Edit: We just switched to diff 93.6k, speed is back to normal, also I have found a block for pool, YAY! - i think it is my first block ever found

Edit2: Seems that those low diff coins are reducing my WU.

[flound1129]

So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying.

Yeah. I don't believe it affects profits. But lots of people are saying it is. So I'm still thinking about it to see if I'm wrong.


With https://github.com/CryptoManiac/stratum-mining, I'm getting:

 File "/home/pushpool/stratum-mining-novacoin-testnet-cryptomaniac2/mining/DBInterface.py", line 33, in connectDB
    if settings.DATABASE_DRIVER == "sqlite":
exceptions.AttributeError: 'module' object has no attribute 'DATABASE_DRIVER'

I must have some module installed wrong. Did you get that?

Thank you so much for the suggestion on which branch to use. I was spinning my wheels trying to get a few others to work.

I don't actually use that, but you can pull template_registry.py out of it for the changes you need.

Edit: and bitcoin_rpc.py

[Numien]

One thing which can increase stale rate is a high intensity setting in cgminer. The intensity affects the batch size (which helps speed) but a larger batch takes longer to process, so increases the odd of being stale by the time it finishes. People with high stale rates, despite low pings, might want to try to see how low they can turn the intensity without significantly affecting the speed.

[Fallout]

So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying.

Yeah. I don't believe it affects profits. But lots of people are saying it is. So I'm still thinking about it to see if I'm wrong.

In theory, you should be correct. However, the statement is only true if looking at infinite time (law of large numbers), and probably no one will mine infinitely
The high difficulty increases variance, especially for "small" miners, and most people dislike variance.

I would like to see a smaller diff (like 128), especially for the fast coins, the smaller miners will (most probably) not find a share ever if unlucky (again, high variance)

btw: my 650kH/s miner found 3 shares in 4 seconds, two of them in the same second ...

[RandomQ]

anyone else having problems with cgminer stalling on stratum? Ive only encountered this problem on this pool and the other guy pools
3.1.1 and 3.3.1 both do it
It reconnected fine everytime i restart cgminer
I have 50-70 ms ping times

[ranlo]

Code:

block boundary (||)
(A) [64][64][64][64][64||][64][64][64][64][64][64][64][64][64]||[ ...
(B) [---------------512||[---------------512-------------][ ...

In this scenario, miner A would have 4 difficulty-64 shares submitted before the first block boundary, and one aborted.  The miner using 512 difficulty shares has not finished one share yet and so he loses the equivalent of ~4.5 difficulty 64 shares when he restarts work.

Miner A is expected to have 4 shares, but may get less or more, in some kind of distribution around that. Miner B is expected to get 0.5 shares on average. They work out to the same thing. The work isn't in discrete blocks like that. It's a probability.

So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying.

I think something else to take into consideration... I am not 100% sure if this is how it works so someone please set me straight, but let's say you have 4 cards at 500KH/s.

GPU0, GPU1, GPU2, GPU3 would each be carrying their own workloads, therefore while you could have 50000 million hash rate due to tons of GPU's, each GPU is still a separate animal working on things independently.

This could be wrong, but it's what I infer from CGMiner's reports, especially being that it separates the work load of each GPU in its outputs.

[ocmoho]

with over 368mh/s there seems to be a minimal amount of people even posting lol.
but yeah, even with high hash rigs, every gpu has its own work. lowering the difficulty to 256 would be good, even maybe to 128.

[GSnak]

So what happens when the pool becomes popular and there's miles worth of slippage dumping coins on Cryptsy? Distribute average price to the pool or those out early make more than those out late? The depth of the order book is going to become a factor when dumping a large volume on a low volume exchange.

[h2odysee]

So what happens when the pool becomes popular and there's miles worth of slippage dumping coins on Cryptsy? Distribute average price to the pool or those out early make more than those out late? The depth of the order book is going to become a factor when dumping a large volume on a low volume exchange.

The volume is taken into account, when choosing coins. So there won't be too much slippage. Certainly some though.

Those early make out more than late. When a trade goes through, it distributes the bitcoins to the earliest shares first. When those bits of "unexchanged balance" are fulfilled, it distributed to the next earliest shares, etc.

[mueslo]

Doing some kind of maintenance?

Or isn't the pool down for anyone else?

[Nolo]

Doing some kind of maintenance?

Or isn't the pool down for anyone else?

Not working for me either tonight.  All I keep getting is: 

[2013-07-25 20:53:16] Probing for an alive pool
[2013-07-25 20:54:47] Stratum connection to pool 0 interrupted
[2013-07-25 20:56:17] Stratum connection to pool 0 interrupted
[2013-07-25 20:57:47] Stratum connection to pool 0 interrupted

[h2odysee]

Oops. try now.

[mueslo]

Doing some kind of maintenance?

Or isn't the pool down for anyone else?

Not working for me either tonight.  All I keep getting is: 

[2013-07-25 20:53:16] Probing for an alive pool
[2013-07-25 20:54:47] Stratum connection to pool 0 interrupted
[2013-07-25 20:56:17] Stratum connection to pool 0 interrupted
[2013-07-25 20:57:47] Stratum connection to pool 0 interrupted

It's back up now.

[Kuroth]

Its coming up..

H20 are we all good now???  Are you working on any other issues?   Did you get NVM going?

[h2odysee]

Its coming up..

H2) are we all good now???  Are you working on any other issues?   Did you get NVM going?

Yeah. It's back up.

I did not get NVC working. It hates me. I'll post in here when I have it up.

I've had higher priority things than NVC today, since it's no longer on top.

[STT]

Just keeps telling me there is a new block before I can submit anything.  Would that be the problem people are talking about

My ping is 182ms and my hash rate is between 500-700 kh   

If the pool gets too big I would think the answer is to mine two or three best coins at once.  Maybe that helps the slower people get a look in ?

[h2odysee]

If the pool gets too big I would think the answer is to mine two or three best coins at once.  Maybe that helps the slower people get a look in ?

That's a good idea. We'd get less rejects on low hashrate coins. I'll keep it in mind as a possibility.

[flound1129]

Code:

block boundary (||)
(A) [64][64][64][64][64||][64][64][64][64][64][64][64][64][64]||[ ...
(B) [---------------512||[---------------512-------------][ ...

In this scenario, miner A would have 4 difficulty-64 shares submitted before the first block boundary, and one aborted.  The miner using 512 difficulty shares has not finished one share yet and so he loses the equivalent of ~4.5 difficulty 64 shares when he restarts work.

Miner A is expected to have 4 shares, but may get less or more, in some kind of distribution around that. Miner B is expected to get 0.5 shares on average. They work out to the same thing. The work isn't in discrete blocks like that. It's a probability.

So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying.

I think something else to take into consideration... I am not 100% sure if this is how it works so someone please set me straight, but let's say you have 4 cards at 500KH/s.

GPU0, GPU1, GPU2, GPU3 would each be carrying their own workloads, therefore while you could have 50000 million hash rate due to tons of GPU's, each GPU is still a separate animal working on things independently.

This could be wrong, but it's what I infer from CGMiner's reports, especially being that it separates the work load of each GPU in its outputs.

I think that's right, if you have 4 gpu's you have 4x the chance to solve a share in time X.

[CoinBuzz]

why dont you include LTC, FTC, or NVC? despite of their profitability, there are many tools to start their pool easily