Artefact2 has requested new indexes on the webserver SQL for his new graphs v3.0, so web-side SQL is down while it makes the indexes. This mainly means hashrates are showing 0.
I have also just deployed step 2 of my anti-stale improvements. Please report if you get any "invalid-time" rejected shares, or if your miner shows "idle" (especially around longpolls). Older versions of DiabloMiner have a bug, and are currently being exempted from the new behaviour (which makes it less effective for everyone), so if you use DM please upgrade to the latest version.
Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 188. (Read 458255 times)
July 31, 2011, 02:04:27 PM
July 29, 2011, 04:04:52 PM
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
You can still use all miners with Eligius. This change should only affect those that have broken implementations of the rollntime extension. Phoenix doesn't support this at all. Since it is a helpful feature, I would recommend switching to poclbm if you can get the same hashrate out of it (it's usually better once you find the right settings).Except poclbm is generally slower than DiabloMiner.
Right now I'm seeing over 380 shares sent in the last hour on the ~410MH poclbm miner on my desktop machine. I haven't seen anything near that efficiency with any other client/pool combination.
Shares generated is an essentially random value. According to statistics, you should get about 344 shares in an hour at 410 mhash.
July 29, 2011, 01:21:12 PM
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
You can still use all miners with Eligius. This change should only affect those that have broken implementations of the rollntime extension. Phoenix doesn't support this at all. Since it is a helpful feature, I would recommend switching to poclbm if you can get the same hashrate out of it (it's usually better once you find the right settings).Except poclbm is generally slower than DiabloMiner.
Right now I'm seeing over 380 shares sent in the last hour on the ~410MH poclbm miner on my desktop machine. I haven't seen anything near that efficiency with any other client/pool combination.
July 29, 2011, 12:57:09 PM
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
You can still use all miners with Eligius. This change should only affect those that have broken implementations of the rollntime extension. Phoenix doesn't support this at all. Since it is a helpful feature, I would recommend switching to poclbm if you can get the same hashrate out of it (it's usually better once you find the right settings).So if we use phoenix, we are missing out on a useful feature, but there won't be any hit to mining efficiency, is that correct? I'll try to figure this out on my own, but if anyone can summarize the utility of this useful feature, that would be most appreciated. I checked the wiki, but there was just enough technical jargon to make me fall shy of understanding.
Correct. Things won't be an worse for you than they have been in the past.
Besides increasing efficiency (which really only matters directly to pool operators or to those with super tight bandwidth or high bandwidth costs), ntime rolling helps protect miners from communication delays on the pool they are using.
Miners incrementing the timestamp (aka ntime rolling) are not as dependent on the pool being able to respond promptly to requests for new work units every 10-20 seconds. If a pool is stressed due to load or if there are network problems, a non-ntime-rolling miner will become idle occasionally (you may have seen warning messages about this from time to time). In contrast, with the same load or network problems, an ntime-rolling miner will just happily increment the timestamp and keep looking for additional shares.
So if you mine at a pool that routinely is overloaded or has network problems, you'll find more shares per hour with an ntime rolling miner which will translate into you getting paid more.
That i do understand
Thanks for explaining.well, as i always got the best results from Phoenix yet, i stick with it. i tried almost every other mining software around. at least the one that does not need compiling software on linux. Is there a list with best parameters/ options related to the GPU Model for Diablo or poclbm?
July 29, 2011, 12:44:45 PM
Thanks Luke-Jr. I'll probably stick with phoenix for now since I don't tend to get many idle miner warnings.
July 29, 2011, 12:35:52 PM
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
You can still use all miners with Eligius. This change should only affect those that have broken implementations of the rollntime extension. Phoenix doesn't support this at all. Since it is a helpful feature, I would recommend switching to poclbm if you can get the same hashrate out of it (it's usually better once you find the right settings).So if we use phoenix, we are missing out on a useful feature, but there won't be any hit to mining efficiency, is that correct? I'll try to figure this out on my own, but if anyone can summarize the utility of this useful feature, that would be most appreciated. I checked the wiki, but there was just enough technical jargon to make me fall shy of understanding.
Correct. Things won't be an worse for you than they have been in the past.
Besides increasing efficiency (which really only matters directly to pool operators or to those with super tight bandwidth or high bandwidth costs), ntime rolling helps protect miners from communication delays on the pool they are using.
Miners incrementing the timestamp (aka ntime rolling) are not as dependent on the pool being able to respond promptly to requests for new work units every 10-20 seconds. If a pool is stressed due to load or if there are network problems, a non-ntime-rolling miner will become idle occasionally (you may have seen warning messages about this from time to time). In contrast, with the same load or network problems, an ntime-rolling miner will just happily increment the timestamp and keep looking for additional shares.
So if you mine at a pool that routinely is overloaded or has network problems, you'll find more shares per hour (on average) with an ntime rolling miner which will translate into you getting paid more.
July 29, 2011, 12:30:10 PM
So if we use phoenix, we are missing out on a useful feature, but there won't be any hit to mining efficiency, is that correct?
rollntime improves efficiency drastically (ie, like 0.8 accept/getwork to over 5 accept/getwork for me). Phoenix doesn't support it, no matter what a pool does. July 29, 2011, 12:10:00 PM
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
You can still use all miners with Eligius. This change should only affect those that have broken implementations of the rollntime extension. Phoenix doesn't support this at all. Since it is a helpful feature, I would recommend switching to poclbm if you can get the same hashrate out of it (it's usually better once you find the right settings).So if we use phoenix, we are missing out on a useful feature, but there won't be any hit to mining efficiency, is that correct? I'll try to figure this out on my own, but if anyone can summarize the utility of this useful feature, that would be most appreciated. I checked the wiki, but there was just enough technical jargon to make me fall shy of understanding.
July 29, 2011, 10:59:23 AM
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
You can still use all miners with Eligius. This change should only affect those that have broken implementations of the rollntime extension. Phoenix doesn't support this at all. Since it is a helpful feature, I would recommend switching to poclbm if you can get the same hashrate out of it (it's usually better once you find the right settings).Except poclbm is generally slower than DiabloMiner.
July 29, 2011, 10:53:13 AM
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
You can still use all miners with Eligius. This change should only affect those that have broken implementations of the rollntime extension. Phoenix doesn't support this at all. Since it is a helpful feature, I would recommend switching to poclbm if you can get the same hashrate out of it (it's usually better once you find the right settings). July 29, 2011, 09:55:23 AM
I don't understand what you 're saying Luke-Jr? I just don't know what your Roll?? Time or how you call it means. I am just using a mining software and dont know every single code line of it or which exact header it sends.
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
I am officially confused.
Can i still use Phoenix with Eligius now? is there a list of accepted mining software?
I am officially confused.
July 29, 2011, 12:46:48 AM
I would appreciate it if the miner using software that rolls ntime when it's not told to, and doesn't send any User-Agent at all, would get in contact with me
Example: 19BLtj3bSsJjfHp8b47eDwfGBRLognDDu2
Example: 19BLtj3bSsJjfHp8b47eDwfGBRLognDDu2
July 28, 2011, 11:32:44 PM
Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
In other words, you're giving me a reason to remove rollntime completely in DiabloMiner. Good jorb.
Until Tycho adds support for X-Mining-Extensions to his Roll NTime spec, I see no reason to support this.
July 28, 2011, 11:07:32 PM
Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
In other words, you're giving me a reason to remove rollntime completely in DiabloMiner. Good jorb.
Until Tycho adds support for X-Mining-Extensions to his Roll NTime spec, I see no reason to support this.
July 28, 2011, 11:00:08 PM
Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
In other words, you're giving me a reason to remove rollntime completely in DiabloMiner. Good jorb.
July 28, 2011, 10:41:21 PM
Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
In other words, you're giving me a reason to remove rollntime completely in DiabloMiner. Good jorb.
July 28, 2011, 09:49:37 PM
Announcement: Eligius will soon stop sending the X-Roll-Ntime header (and will reject ntime-changed shares from) miners which do not send at least "X-Mining-Extensions: rollntime" in their getwork headers. An exception to the rule will be made for User-Agents matching miners known to roll ntime correctly (currently, this is poclbm and newer cgminer versions), but authors of such miners are encouraged to advertise rollntime support anyway.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
What this means for you: If you're using a miner that isn't either known by me to have working rollntime support and has a unique User-Agent header, or advertises having rollntime support explicitly, your miner's efficiency (accepted shares per getwork) will drop. If network latency is bad, you may get more "miner is idle" messages. It is recommended that miners use clients which support rollntime, such as poclbm.
This is one step toward improving our longpoll times and making the pool more efficient in general.
P.S. If you hack your client to advertise rollntime support, but don't really support it, expect to have the miner blacklisted from rollntime. There is no reason to do this.
July 27, 2011, 10:30:24 PM
New feature for beta-testing only (NO WARRANTY ETC): you can now append your address with "_workername" in your username to classify the shares. This has no effect on the JSON data, but does create a distinct identity in the database so you can monitor individual workers' uptime and hashrate. Currently it is not supported by Artefact2's graphs.
July 27, 2011, 03:26:00 PM
That doesn't actually follow. Most other pools don't support the same functionality that Eligius does, so don't encounter the same issues. I would suggest trying with the latest poclbm (ideally my branch) and seeing how that works.
Stales seem to follow some sort of pattern dependant on the server's behavior.
During the writing of this post, literally everyone in the top 25 has 0% stale shares over the last 15 minutes, and under 2% overall. That applies to my miners as well over the last 15min
A few hours later it ranges based on each address, from 1 to 4%.
Just wondering where it's coming from / if it can be solved. Can't be random because the 0% streaks happen to everyone at the same time & end at the same time.
Edit (10 minutes later): Now everyone on top25 is having about 3% stales again.
July 26, 2011, 06:07:48 AM
hope stats are fixed soon! 
Jump to: