Elitehash naturally supports the algorithm change for Raven, on October 01
Miners still have to change their config files, so the port number should probably change. Everyone just has to edit those configs, there's no way around it. Changing the port number is a good way to filter out those miners who didn't react and stil try to mine x16r. They'd be shown as rejected hashrate otherwise.
Topic: Elitehash Raven PPS Pools - stable rewards, payouts every hour! (Read 880 times)
August 18, 2019, 03:11:46 AM
Raven is now the only pool on Elitehash, as I'm reworking the code for better scalability. Worst bugs have been fixed during the summer, and I'm sorry against any hashrate loss due to them. I sent a covering payout for most, and will do a final check of the history after I've done this final rework. There could still be a hiccup or two, but I think I've learned from a lot of mistakes here 
In the meantine, Raven payout rate is steadily increasing again, and it might even go over 100% soon!
In the meantine, Raven payout rate is steadily increasing again, and it might even go over 100% soon!
The new stratum server is now working great, still a bit of extra latency but it's not really causing noticeable rejects. Should be relatively easy to fix now. Connections to Helsinki & Paris were a bit unstable this past week, but now they are stable. Got the CPU usage down to 1% and fixed this pesky problem with stale connections.
I'm about to make a switch to this stratum server I made from scratch. It's replacing 17k lines of code I didn't write with a neat, 400 line package that isn't hard to understand, at least for me.
The dip in the hashrate graph is from my 1st test with actual miners (in the Helsinki server), which to not much surprise uncovered a bug or two Everyone was sent the *full* amount of what they should have earned during that 4 hours of bugged share counting, calculated from the previous 4 hours: https://ravencoin.network/tx/3143984c32d0ec6148fc8f171e795f262b150e676cd188c38fc571f0756cbaba. In addition to the ~50% or so of shares that weren't lost due to these bugs.
The switch should be transparent to miners, but the end result should be definitely noticeable: share difficulties won't be absurdly high anymore. During the last test, I had a constant 32 for 4 hours.
(For anyone interested, the bug was related to duplicated stratum message IDs. Easy to fix by adding an ID translator.)
The dip in the hashrate graph is from my 1st test with actual miners (in the Helsinki server), which to not much surprise uncovered a bug or two
Everyone was sent the *full* amount of what they should have earned during that 4 hours of bugged share counting, calculated from the previous 4 hours: https://ravencoin.network/tx/3143984c32d0ec6148fc8f171e795f262b150e676cd188c38fc571f0756cbaba. In addition to the ~50% or so of shares that weren't lost due to these bugs.The switch should be transparent to miners, but the end result should be definitely noticeable: share difficulties won't be absurdly high anymore. During the last test, I had a constant 32 for 4 hours.
(For anyone interested, the bug was related to duplicated stratum message IDs. Easy to fix by adding an ID translator.)
January 24, 2019, 04:26:49 AM
Worker lists and Paris server were added this month. Not sure where the miners are going, as Raven is still at the top in WhatToMine. I'm a bit hesitant to add every new coin, at least until they've been proven somehow.
Payout rate is going up now, to help gather more miners & also because higher rates really are easier to sustain with a smaller pool. Suggestions for improvements are welcome, as always. A payout list with txids is coming, but I don't have any other big improvements planned now.
Payout rate is going up now, to help gather more miners & also because higher rates really are easier to sustain with a smaller pool. Suggestions for improvements are welcome, as always. A payout list with txids is coming, but I don't have any other big improvements planned now.
December 19, 2018, 05:19:42 PM
Rejects have been over 1% today, my new approach is to increase the payout rate in situations like this. It's working as intended, can't avoid the higher reject rates totally, but the higher payout rates should compensate. For a moment I thought about making the rate go up automatically in such situations, but that would so ripe for exploitation it's better done manually.
December 12, 2018, 08:54:50 PM
I've toned down the automatic restarts, clearly it wasn't a good approach. Now the needless restarts are kept to a minimum, while rejects are being more closely monitored with automatic restarts of specific ports in case of problems. Overall reject rate is again below 1%, which is the target. It can be higher than elsewhere on this pool, but the high payout rate acts as compensation.
December 01, 2018, 07:55:38 PM
As a result of the changes ensuring no extra shares get counted, all the stratum ports now automatically restart multiple times per day in a continuous rotation. Connections are automatically routed to the slowest port, so the chance that such a restart causes even a second of idling is low. But most miner programs today are too dumb to return from a backup pool on their own. These automatic restarts can trigger the switch to a backup pool, so if you have other pools than Elitehash servers defined, it might get annoying to track if rigs gets stuck on backups too often. Please let me know if this has become a bigger issue - the automatic restarts have been there since the beginning, but with much less frequency until now.
November 29, 2018, 09:59:54 AM
The payout rate has been temporarily dropped, as I was investigating a problem with extra shares being credited to people. Just look at those graphs on Helsinki or Virginia, lots of people have huge inexplicable spikes upwards. I'm hoping the drain is finally plugged now, watching it closely.
EDIT: It's indeed looking better, as I guess you can see from the lack of payout delays. Payout rate starts climbing back to 100% now
EDIT: It's indeed looking better, as I guess you can see from the lack of payout delays. Payout rate starts climbing back to 100% now
November 18, 2018, 02:55:09 AM
Payout times changed to once every 20 minutes per server, hopefully that's OK. I want to keep the amount of owed coins smaller.
November 13, 2018, 04:02:00 PM
2.1.2 asset support update? Thanks again for the great pool.
We aren't currently generating our own blocks actually, difficulty got so high it made more sense to spread the hashrate to get lower variance. But I'll still keep them updated, of course, thanks for the reminder!
November 06, 2018, 12:21:15 PM
2.1.2 asset support update? Thanks again for the great pool.
November 04, 2018, 06:25:31 PM
Singapore server online. Still working on improving those loading times, they should be better now but sometimes it's not so fast
November 01, 2018, 08:23:00 PM
Love the pool. Good work. Just making sure our mining is voting for the asset layer hard fork. I don't see anything about this on the website. Thanks!
Updated all the servers earlier today
November 01, 2018, 06:42:11 PM
Love the pool. Good work. Just making sure our mining is voting for the asset layer hard fork. I don't see anything about this on the website. Thanks!
October 25, 2018, 07:11:39 PM
Unfortunately I realized that applying txids to past payouts is harder than it first seemed. Because the pools are spread over many servers, sharing the same wallet, I can't just search for all the transactions in the wallet matching an address found on a server - most likely the same address has mined on another server too, and I don't know which transaction is from which server.
The best approach I think would be go through the balances database and match the payouts with transactions where the amount, address & dates match. I'll consider doing that when I get the system ready for storing txids for future payouts.
But some payout histories are unfortunately too hard to restore. On other servers all the balance changes are intact, but I messed them up when moving the Helsinki server a couple of months ago. It still has all the shares since the beginning, but the balance database doesn't contain entries before the server move. They were lost because of my carelessnes
- for anyone affected by this, and who would like their complete transaction history, I can compile it manually for their address, send me a PM.
The best approach I think would be go through the balances database and match the payouts with transactions where the amount, address & dates match. I'll consider doing that when I get the system ready for storing txids for future payouts.
But some payout histories are unfortunately too hard to restore. On other servers all the balance changes are intact, but I messed them up when moving the Helsinki server a couple of months ago. It still has all the shares since the beginning, but the balance database doesn't contain entries before the server move. They were lost because of my carelessnes
- for anyone affected by this, and who would like their complete transaction history, I can compile it manually for their address, send me a PM. October 03, 2018, 03:22:31 PM
I changed the servers to do payouts at a fixed minute every hour, to avoid a rare double-spend problem that happened today. It wasn't the first time. In total 10k RVN of the 4M+ paid out weren't actually paid out as the servers attempted to use the same inputs and one of the transactions obviously never gets confirmed. After an user mentioned a payout not making it through today, I checked the history (it's easy as the listtransactions RPC command shows them having a negative amount of confirmations) and found 10k RVN worth of failed payouts.
As the payouts now happen in turns, this can't happen anymore. I'll compile the failed transactions to a single big one and send it soon. People have occasionally requested a txid list for payments, but the simplest implementation would probably have just listed the failed txids there with no-one being any wiser. Looks like the list should also check that they have been confirmed, making it a bit more complicated.
EDIT: failed transactions have now been resent
As the payouts now happen in turns, this can't happen anymore. I'll compile the failed transactions to a single big one and send it soon. People have occasionally requested a txid list for payments, but the simplest implementation would probably have just listed the failed txids there with no-one being any wiser. Looks like the list should also check that they have been confirmed, making it a bit more complicated.
EDIT: failed transactions have now been resent
October 03, 2018, 01:59:08 PM
Works for me 
October 01, 2018, 08:38:46 PM
Why has the payout rate dropped to 98.5%?
It's my only way to control the size of the pool. It's true that having the rate change almost daily is different compared to other pools. At first I was a bit wary of adjusting it too often, made sure to give proper notice etc. Loosening up my own rules there has worked well in practice, though. I have realized that doing the changes without notice mostly helps drive the change I want, compared to giving notice. This might annoy some, but those who have stayed long enough realize it works both ways. I don't go drumming around the changes upwards, either. Can keep them up longer that way.
September 27, 2018, 07:30:32 AM
Why has the payout rate dropped to 98.5%?
Jump to: