Mining on same worker from several ips stimulantiously. (Help)

[console.log]

I have a few server clusters from my hosting company which are not under use (I'm a reseller) and i thought about making a few bucks until someone decides to rent them


How can i go around into for example mining on same worker account in all those different servers, notice that they have different ips as well each.
is it possible to mine with 100 servers in one worker account without using a proxy?
Thanks for any assistance.

Notice it's in a pool for pooled mining the worker account that is.

[1714751331]

1714751331

[1714751331]

1714751331

[1714751331]

1714751331

[Kluge]

There's no problem doing that. "Workers" only exist so you can see which miners are on and mining - it's not pools trying to enforce some type of "one computer per worker" deal. You can point as many computers there and on the same worker credentials as you want, all over the world, and the pool server will still send them all work as normal and output the correct stats for work solved by all the computers.

[ocminer]

Thats not correct, as most pools use variable difficulty, when you use the same worker account for all your workers (even small/slow) ones, the smaller ones will get "overloaded" with too high difficulty shares as the Pool is trying to throttle the max shares per second from you.

Best thing is to use a stratum proxy for this and THEN connect to the pool.

[console.log]

Thats not correct, as most pools use variable difficulty, when you use the same worker account for all your workers (even small/slow) ones, the smaller ones will get "overloaded" with too high difficulty shares as the Pool is trying to throttle the max shares per second from you.

Best thing is to use a stratum proxy for this and THEN connect to the pool.

I have a stratum proxy up but it seems to be giving an insane amount of rejects.
Any idea on how i can go into fixing this? also cudaminer seems to not work with it properly.

[Kluge]

Thats not correct, as most pools use variable difficulty, when you use the same worker account for all your workers (even small/slow) ones, the smaller ones will get "overloaded" with too high difficulty shares as the Pool is trying to throttle the max shares per second from you.

Best thing is to use a stratum proxy for this and THEN connect to the pool.

It'd more or less still be the same payout. Less powerful rigs will just submit more-valuable shares less often. Doesn't really matter if they miss a few rounds so long as they eventually make it up.

[ocminer]

Thats not correct, as most pools use variable difficulty, when you use the same worker account for all your workers (even small/slow) ones, the smaller ones will get "overloaded" with too high difficulty shares as the Pool is trying to throttle the max shares per second from you.

Best thing is to use a stratum proxy for this and THEN connect to the pool.

I have a stratum proxy up but it seems to be giving an insane amount of rejects.
Any idea on how i can go into fixing this? also cudaminer seems to not work with it properly.

Yes Cudaminer does not work correctly with that, thats true.

What kind of Rejects ? Invalids ?

It'd more or less still be the same payout. Less powerful rigs will just submit more-valuable shares less often. Doesn't really matter if they miss a few rounds so long as they eventually make it up.

There will be lots of stales as the slower machines will be much too late. It works, thats correct, but it is not the optimal way.. It is not the way I would take

[Kluge]

There will be lots of stales as the slower machines will be much too late. It works, thats correct, but it is not the optimal way.. It is not the way I would take

Maybe I'm misunderstanding how stratum works (not trying to be an asshole doing a "gotcha" or something, just curious). Won't all miners, slow or fast, switch to new non-stale work at the same time? I thought stales only occurred due to network or server lag, where old work is completed before the server pushes new work. Statistically, then, shouldn't they have the same % of stales?

[ocminer]

There will be lots of stales as the slower machines will be much too late. It works, thats correct, but it is not the optimal way.. It is not the way I would take

Maybe I'm misunderstanding how stratum works (not trying to be an asshole doing a "gotcha" or something, just curious). Won't all miners, slow or fast, switch to new non-stale work at the same time? I thought stales only occurred due to network or server lag, where old work is completed before the server pushes new work. Statistically, then, shouldn't they have the same % of stales?

To make it easy:

No :-)

Very short description:

Stratum pushes a "template" for the current block to the client with a given Difficulty. So a R290X with massive power as for example Diff 500. This client now "crunches numbers" until it finds a (possible) positive number for the template and sends it back to the (stratum) server. Now comes the trick, with vardiff, the server decides on the number of shares per second PER WORKER how high the diff of this template is. So even if there 1000 servers behind one WORKER, every worker gets now diff 500, even if there is only a CPU mining. Now the R290X already found a candidate, and sends it back to the server as the CPU is still crunching.  Lets now say the R290X delivers this Share every 10 seconds but the CPU needs 5 minute for the share (at least) because it is the same high diff. Until the share from the CPU gets submitted, there is already a new block in the network and so a new Block Template, meaning the share submitted from the CPU will be a stale share.


This was a very easy and rough description of things going on, there are million other gings goin on in parallel but this should at least give you an idea why it is NOT good to use multiple/different machines under one worker.

oc

[Kluge]

There will be lots of stales as the slower machines will be much too late. It works, thats correct, but it is not the optimal way.. It is not the way I would take

Maybe I'm misunderstanding how stratum works (not trying to be an asshole doing a "gotcha" or something, just curious). Won't all miners, slow or fast, switch to new non-stale work at the same time? I thought stales only occurred due to network or server lag, where old work is completed before the server pushes new work. Statistically, then, shouldn't they have the same % of stales?

To make it easy:

No :-)

Very short description:

Stratum pushes a "template" for the current block to the client with a given Difficulty. So a R290X with massive power as for example Diff 500. This client now "crunches numbers" until it finds a (possible) positive number for the template and sends it back to the (stratum) server. Now comes the trick, with vardiff, the server decides on the number of shares per second PER WORKER how high the diff of this template is. So even if there 1000 servers behind one WORKER, every worker gets now diff 500, even if there is only a CPU mining. Now the R290X already found a candidate, and sends it back to the server as the CPU is still crunching.  Lets now say the R290X delivers this Share every 10 seconds but the CPU needs 5 minute for the share (at least) because it is the same high diff. Until the share from the CPU gets submitted, there is already a new block in the network and so a new Block Template, meaning the share submitted from the CPU will be a stale share.


This was a very easy and rough description of things going on, there are million other gings goin on in parallel but this should at least give you an idea why it is NOT good to use multiple/different machines under one worker.

oc

Thanks. That seems fairly insane. It didn't used to work this way pre-stratum, did it? It seems like if the server detects a new block, it'd be in everyone's best interest to immediately push out new work.

[ocminer]

There will be lots of stales as the slower machines will be much too late. It works, thats correct, but it is not the optimal way.. It is not the way I would take

Maybe I'm misunderstanding how stratum works (not trying to be an asshole doing a "gotcha" or something, just curious). Won't all miners, slow or fast, switch to new non-stale work at the same time? I thought stales only occurred due to network or server lag, where old work is completed before the server pushes new work. Statistically, then, shouldn't they have the same % of stales?

To make it easy:

No :-)

Very short description:

Stratum pushes a "template" for the current block to the client with a given Difficulty. So a R290X with massive power as for example Diff 500. This client now "crunches numbers" until it finds a (possible) positive number for the template and sends it back to the (stratum) server. Now comes the trick, with vardiff, the server decides on the number of shares per second PER WORKER how high the diff of this template is. So even if there 1000 servers behind one WORKER, every worker gets now diff 500, even if there is only a CPU mining. Now the R290X already found a candidate, and sends it back to the server as the CPU is still crunching.  Lets now say the R290X delivers this Share every 10 seconds but the CPU needs 5 minute for the share (at least) because it is the same high diff. Until the share from the CPU gets submitted, there is already a new block in the network and so a new Block Template, meaning the share submitted from the CPU will be a stale share.


This was a very easy and rough description of things going on, there are million other gings goin on in parallel but this should at least give you an idea why it is NOT good to use multiple/different machines under one worker.

oc

Thanks. That seems fairly insane. It didn't used to work this way pre-stratum, did it? It seems like if the server detects a new block, it'd be in everyone's best interest to immediately push out new work.

There IS also a notification to the clients, but it's still quite unreliable from what I see and the problem is, in our example above, the CPU would never submit a valid share with the high diff because stratum would always notify before a share could be sent.