[quote author=jgarzik link=topic=2647.msg46868#msg46868 date=1297379631]
[code]
TCP connect to host:8331
send curtime, protocol version, client version string, username, [possibly empty] list of options, sha256(all previous args + password)
wait for server response ("auth ok, here are my capabilities", or "rejected, goodbye")
[/quote] We already discussed this on IRC and I think we didn't listen each other. Maybe because I'm not native speaker and my capabilities to explain anything are extremely limited  . I don't have any major problem with your proposal. Skipping HTTP overhead is good idea mainly for high traffic deployment and including some kind of notifications for external applications would be nice. But if I'll have a choice, I'll prefer stateless protocol. I don't see first auth request as necessary, there is not any problem with sending username/password with every request, but it make code on both sides more transparent. [/code] |
|
|
|
The workers table columns are messed up.
Typo, fixed. (This is exactly the reason why I don't want to make big changes from Internet cafe) |
|
|
|
|
Many users ask me why I don't want their better hosting, why I don't set up fee for only CPU miners (which are traffic-ineffective), why I don't finish new protocol and so.
Please understand, that I'm on holiday and I'm writing from Internet cafe. I cannot deploy any big change, I cannot move system to another location. This is temporary hot fix for current system and I don't want to set up fees for forever.
|
|
|
|
I have three workers that have been working ever since #967 on the statistics page of mining.bitcoin.cz were found. However, only one of my miners is getting any credit for the work and I have only received reward for 2 of the hashes found since then.
Stats and unconfirmed reward on site are delayed, so this may explain your problem. Shouldn't I have received rewards for all the blocks solved since I had three workers that were active during their time?
You should. Otherwise something is broken here. Please check that you're using correct credentials and every of your miner is using different worker account. |
|
|
|
|
Probably due to "slashdot effect", the pool today practically doubled his network traffic and cross far over 1TB/month. Unfortunately, this sudden huge jump in server load is above my current financial abilities. Final solution - better protocol, which will significantly reduce needed traffic is currently in development stage and is not ready for production. I'm also on holiday these days, so I cannot speed up development right now.
As a temporary solution, I need to set up minimal donations to reduce server traffic and/or gain more funds to server costs. Please set up at least 2% donations on your profile to keep your worker credentials working. Tomorrow, on Saturday 12:00 UTC, I set up required donations and restart application. After this modification, worker logins from accounts without donations will be disabled and attempt to use them in miners will lead to info message with link to this post.
I'm very sorry for this solution, but it is currently the only way how to keep service up with this huge load. The fee is only temporary.
EDIT: It may take few minutes until changes on your profile page take effect. If you already setup donations and miners still show info message, please wait a moment and try start miner again.
|
|
|
|
Is there any way to make this darn thing not chew up system resources, or cpu cycles, or whatever? You know, a little background trickle of work that doesn't freaking shut down everything else?
If you are using GPU for mining, there are some options to make it less agressive. But depends on miner which you use. I have to issues on my box with m0mchil or Diablo miners and higher -f (say 300-1000). |
|
|
|
Then clicked on register worker. This is the part that really screwed me up! I did not understand what it wanted from me.
What exactly you're missing? All instructions are step by step on pool homepage. |
|
|
|
So instead, perhaps we make the DNS cache not expire, except in cases where the connection fails. When a failure occurs, we assume that the IP address of the server might have changed, so we will clear the cache and do the DNS look-up again. I'll look into how to do this with CURL.
Yes, this is better. But, it is necessary? DNS typically expires once every 8 hours, so if your DNS cache works properly, you're saving rountrip of 3 requests daily. Worthless. |
|
|
|
suggest that people use the IP address of the server
No please! No for my pool! Hardcoded IP makes system migration almost impossible or with significant drop in hashrate until all of 400 workers is fixed. I already migrated server to stronger machine and I'll do it again soon. |
|
|
|
However, something strange is occurring. When I set the queue up such that each mining thread has a small work queue of length 1, there is no problem and the system works as intended. However, when the queue length goes above one for each queue, all the results get a response to the effect that they are invalid.
How old are these calls? Miners need to have jobs as fresh as possible. Crunching too old jobs leads to rejecting by pool server. Usualy the ask rate is 5 seconds, this leads only to decent overhead. |
|
|
|
|
I did small pool update today. Now you can see 'total score in round' and scores for every worker. For now this does not affect calculating rewards and I'll introduce meaning of those numbers tomorrow.
I'm also pretty sure that today's server fix will also have positive impact to daily rewards, because it improved server performance for some percent. So stay tuned :-).
|
|
|
|
Hypothetically speaking, if I made available 25, modern dual processor, quad core, servers for 2 hours per day, roughly how many, on average, bitcoins could be expected from joining this pool?
Almost same as on standalone mining, only with steady payouts. Check http://www.alloscomp.com/bitcoin/calculator.php and divide 50BTC / (days from calculator) to get your expected daily reward from pool mining. |
|
|
|
|
Well done! Looks like he studied Bitcoin for a while...
|
|
|
|
Does Slush' pool pay out less to you if you have a lower donation threshhold set?
no |
|
|
|
In case you need it, check midphase.com server plans.
Thanks gusti for the tip. I have few boxes on Linode and I love the service and their support, so I'd like to stay here. I also think we've fixed the network issue, so no need to migration right now. Keep in mind that those 160 requests/s (10.000.000.000 requests per month!) are pretty high traffic and everything must be perfect to run smoothly on VPS. |
|
|
|
I'm having some connection problems, quite regularly a connection is lost every 7-10 minutes, is it just me?
After discussing it with server support and little fiddling with server, I think it should be better now. Can you confirm that? |
|
|
|
I'm having some connection problems, quite regularly a connection is lost every 7-10 minutes, is it just me?
If you see connection timeouts, I'm solving this. looks like network is shaped. I'll try to upgrade my server today. If it does not help, I'll contact server support for some help. |
|
|
|
Only 3 shares is below 0.5s of the pool capacity.
It is below _average_ pool capacity. When new block arrive, there are many seconds with significant lower (effective) hashrate. There is also significant variance in share submitting rate. Sometimes there are almost 20 shares per second, sometimes there is almost nothing. And I don't see any trouble with stale block algorithm itself. |
|
|
|
But the round took 7 seconds to complete and the pool should have made 52 shares at this time frame. Poor those who earned a stale share at that time. How many stale shares did you log during this round (and on average during all rounds)?
Stale shares are around 1-2%. Of course there were many stale shares in this round, but it is how it works. Calculating stale shares is not fair, because people get reward for something which cannot give valid block to pool. It also improved overall pool performance, because some people had strange miner settings (ask rate over 180 seconds etc). So 7 seconds for three shares at the beginning of round seems to be fine. |
|
|
|
I like it, it may start some network effect. I doubt there are many well "connected" people on this forum.
I'm two connections far to Obama :-). |
|
|
|
|
Show Posts
