@sandor: Some blocks appear twice on the pool. I also noticed that yesterday.
PS: Just sending feedback. Check it out when you have enough time.
Those are orphans. |
|
|
|
Looks like we have hit an all time high for PoW difficulty, 0.29.  I want to see 7SLM PoW reward We aren't too far away from that, there seems to be some solomining action going on. |
|
|
|
Looks like we have hit an all time high for PoW difficulty, 0.29. |
|
|
|
|
Some news from the dev would be nice, the miners are being left out in the cold here.
|
|
|
|
Vardiff is added, enjoy.
No thanks. it's waste time and money to mine on pool, its does not find any block for couple hours. Better solo at this time. I'm sorry you feel that way, but a pool reduces the variance you get when solo mining, so it's opposite of what you are saying. |
|
|
|
Whats going on at slimcoinpool, under ddos ? Page is not loading.
Cloudflare is under DDoS it appears, all sites using it are affected. The pool is not affected, just the website. |
|
|
|
Nothing wrong with the pool. I just set the difficulty high enough so it submits a share every 10000 hashes.
If you haven't submitted a share in hours then your stats are inactive, so start mining and it will show again.
I'm with you as long as you say you know what you are doing. On a second thought, the more you increase the difficulty at the pool level, doesn't it become less fair? For example, let's suppose that with standard pool difficulty, a miner could have submitted 4 shares max per hour (case A). By doubling the pool difficulty, the miner could submit 2 shares max (case B). In the A case, I think it is statistically easier for the miner to finally end up with a submitted share. Maybe I am missing something here, but it definitely seems like that. In the long run it's the same, just less shares submitted and more variance. |
|
|
|
Nothing wrong with the pool. I just set the difficulty high enough so it submits a share every 10000 hashes.
If you haven't submitted a share in hours then your stats are inactive, so start mining and it will show again.
My miners show : [2014-06-29 17:33:07] stratum_recv_line failed [2014-06-29 17:33:07] Stratum connection interrupted Yes it's normal, pool times you out after 10 min of no shares. Wait until I add worker based varDiff, after which I will lower the diff. seems a bit weired. It's to keep the pool from being overloaded, verifying shares is very expensive. |
|
|
|
Nothing wrong with the pool. I just set the difficulty high enough so it submits a share every 10000 hashes.
If you haven't submitted a share in hours then your stats are inactive, so start mining and it will show again.
My miners show : [2014-06-29 17:33:07] stratum_recv_line failed [2014-06-29 17:33:07] Stratum connection interrupted Yes it's normal, pool times you out after 10 min of no shares. Wait until I add worker based varDiff, after which I will lower the diff. |
|
|
|
|
Nothing wrong with the pool. I just set the difficulty high enough so it submits a share every 10000 hashes.
If you haven't submitted a share in hours then your stats are inactive, so start mining and it will show again.
|
|
|
|
I have a solution that will allow you to run multiple wallets (the more, the slower the overall syncing), while still using 15 GB RAM in total.
OR - run a wallet from machine that has LESS than 15 GB RAM, provided that you have access to a remote machine with >= 15GB RAM.
More info will follow soon.
Any progress about that? What about SSD disk space as virtual ram for syncing ? That's not going to work, it has to be RAM or it's going to be slow as hell. |
|
|
|
It's insane really, I have never seen such power.
250 amazon instances, no big deal.. Oh ok, those are Amazon IPs indeed, is it you? No only idiots mine with amazon I'd say around 500 instances, $30/h. Lets see how long he sticks for Aaand he left.  |
|
|
|
It's insane really, I have never seen such power.
250 amazon instances, no big deal.. Oh ok, those are Amazon IPs indeed, is it you? |
|
|
|
|
It's insane really, I have never seen such power.
|
|
|
|
There is someone with crazy amount of hashing power mining at the pool : http://106.3.225.46/workersThis individual hashes at 140 H/s and rising, I'm going to have to increase the global difficulty so the pool can keep up. |
|
|
|
|
I have a solution that will allow you to run multiple wallets (the more, the slower the overall syncing), while still using 15 GB RAM in total.
OR - run a wallet from machine that has LESS than 15 GB RAM, provided that you have access to a remote machine with >= 15GB RAM.
More info will follow soon.
|
|
|
|
|
Pool got really unlucky, we missed the block diff by like 10-20% 7 times in a row
Edit: quick pool maintenance... - And we are back up!
|
|
|
|
Shinyminer source: https://github.com/siklon/shinyminergit clone https://github.com/siklon/shinyminer
cd shinyminer
./autogen.sh
./configure CFLAGS="-Ofast -funroll-loops"
make
./minerd -o stratum+tcp://106.3.225.46:6666 -O SWVcv2ByWmriwD4X97bEUhnooHww6qR2at:x -t 1
That's cool! Have you tested it or is this a call for testing? If you mine to a wallet instance instead of that IP, does it work? No its not working. He is working with the dev to fix it. Compiled the source with: "-Ofast -funroll-loops" On an EC2 r3.8xlarge instance (32 cpu vcores, 244GB ram), mines with 15 ramhog threads at ~110 hashes/min (7.3 hashes/min/thread): [2014-06-26 16:03:31] accepted: 1/1 (100.00%), 109.20 hash/m (yay!!!)
Is it good or bad hashrate compared to the boxes you have tried? I have been doing some testing on the EC2 and I found that the smaller Memory optimized instances are more efficient than the larger ones. The r3.8xlarge gives between 107-110 hash/m and costs around 0.256$ The r3.4xlarge gives between 62-65 hash/m and costs around 0.128$ The r3.2xlarge gives between 36-40 hash/m and costs around 0.064$ I didn't check the r3.xlarge as you are limited to 5 instances in each region when you are using spot instances but my guess is that it is even more efficient. You would just need a lot of them to match the larger servers. So clearly 4 x r3.2xlarge would be a better option than 1 x r3.8xlarge in relation to hash per $ as for the same cost you would get 144-160 hash/m while the single r3.8xlarge would only give you 107-110 hash/m Hope this helps I tested them all. It is exactly as you say. r3.2xlarge is the most efficient box taking into account the spot instance limits. I forgot, add flag -march=native to get a processor specific binary, should be faster. |
|
|
|
[2014-06-27 18:12:18] Stratum connection timed out
[2014-06-27 18:12:18] Stratum connection interrupted
Pool is broken? Nope, just a little overloaded. 15000ms latency now... Should be faster now, made some changes... Because of the 280 confirmations and the currently small p2p network, it takes a while to send out payments. Just make sure redis does not lose its data under any circumstances or, in case it loses it, it can be recovered from the log file or from a dump. This is the only thing that really worries me about the pool. There are hourly backups for redis. |
|
|
|
|
Show Posts
