Topic: CKPOOL - Open source pool/proxy/passthrough/redirector/library in c for Linux (Read 124142 times)

yes i did it from logs, but are you aware killing ckpool is dropped most of time ?


ckpool -k

doesn't kill the process, i tried various other combinations too

No such thing exists. You'd have to build your own, sorry.

ckproxy -p runs fine !


what could the best option to see the proxy status in nice web UI ?

About ckproxy

Ckproxy uses the same core code as ckpool and acts as a proxy with a simple switch (-p). It acts as a stratum-to-stratum proxy, or stratum-through-stratum proxy in passthrough mode (see below).

It is most useful to regular miners who wish to consolidate their mining hardware into one connection for minimal upstream/downstream bandwidth in standalone mode (with the additional -A switch). Ckproxy uses multiple modes to maintain as many miners as possible communicating with the upstream pool. It works by splitting up nonce2 sizes if the upstream pool's nonce2 is large enough and then it recruits extra upstream connections as needed to allow the number of downstream miners to scale indefinitely.

Ckproxy can be started in "userproxy" mode which monitors login names of miners attaching that don't match the master proxy username and recruits new upstream connections with each unique username, proxying all workers of the same username to the unique upstream proxy connections.

It can be configured to run with a database as per an actual pool entirely, thus acting like a child pool for a parent pool elsewhere, or simply for miners who wish full logging of every detail of their mining operation.

It can also act as a unique stratum-through-stratum passthrough mode which absolutely requires a ckpool as the parent pool with the -P switch. In this mode it does not decrease the bandwidth talking to the upstream pool but minimises the number of open connections instead, but requires extremely low resources to run. This mode is most useful for pools wishing to isolate their main pool instance from the outside world and set up multiple VPSs as a kind of front end proxy/firewall to the outside world. This also removes any realistic limit on the number of open connections since each passthrough instance could easily handle 10k connections, consolidating each into just 1 connection to the upstream pool.

In addition to the passthrough mode, there is a more advanced "node" mode which connects as a passthrough, but needs a local bitcoind connection of its own. It monitors all traffic and shares between the pool and miners, being able to display local hashrates and will submit any blocks found to the local bitcoind in addition to sending the shares to the upstream pool, circumventing the delay of block submission that would otherwise happen with remote nodes.

Finally ckproxy can be started in "redirector" mode which acts as a regular passthrough, but monitors share responses from the upstream pool, and once a valid share is recognised from the upstream pool it will redirect miners that support redirection (all cgminer based clients do) to the URL of your choice. Should the miners not support redirection, such as rental services, ckredirector will continue to act as an ordinary passthrough.

Client 7 rejecting for 120s

did you got an valid btc address in, or did you leave the ADDRESS ?
It will only work with a proper btc address.

I'm relatively new to Linux.  Is there a way I can direct it to compile as 64 bit?  I just assumed it would do that somehow on its own.



By the way, I've been using your cgminer on another machine and it's been rock solid for a couple years.  Nice work.

Might be an intel 64 bit machine but it looks like you're trying to compile it for a 32 bit userspace. Ckpool is 64 bit only.

/usr/bin/ld: i386:x86-64 architecture of input file `libckpool.a(sha256_sse4.A)' is incompatible with i386 output

Yes.

Does ckpool also adjusts diff down, or in general, is that something that pools do ?
For example miner hashrate drops by 50% in a current session because a hasboard died.

One workername can have 10 thousand separate workers all with the same workername, but each with separate diffs.

ok got it, thats for handover.
But why not serving previous difficulty after reconnect ?
Example:
1) Miner A with wokerName: MinerA  connected and mined for a while on stable diff.
2) pool stores this diff information per worker
3) Miner A disconnects and reconnects after few minutes
4) pool identifies miner by workerName -> gets old diff value from log and serves the stored diff instead of starting new vardiff ramping ?

Very likely that i oversee a detail, like i said -> Learning phase ..  so thanks for your answers

That's a lot of data to hand over, the handover only hands over sockets, not the state of vardiff etc., and all of them will have to reconnect so all the previous connections will be invalid so you won't know who's on which socket after reconnect anyway. Worker names does not equal which socket they're connected to.

Hey -ck

thanks for your work and sharing of this great piece of pool software.

I played around with your ckpool to learn and better understand mining process.

Now one question (so far) comes up, why does the pool re-adjust the vardiff from scratch for every known client after reconnects / instance takeover (with your -H option) / ...
Doesn't it put alot of stress on a pool server with thousands of clients connected if , for example , you make a instance takeover and all thousand clients start to re-djust vardiff with x shares per second ?
Since you already have per worker information stored, isn't it better to store also last vardiff information and start from there on the next connection of the same worker ?

Thanks