anyone notice that all the following resolve to the same IP (192.99.44.159) ?
sf.clevermining.com
ny.clevermining.com
us.clevermining.com
ca.clevermining.com
So I'm guessing you're not going to have any better luck trying these supposed location based subdomains....
Rob
Terk has posted about this recently. If I recall correctly, everything is being hosted in at the ca node because accept rates were universally higher there, even for users on the san fran node. This will likely change in the future, so these subdomains may point to different stratum endpoints again soon. |
|
|
|
Clevermining reject ratio is ridiculous at this moment  <snip> Looks like a perfectly acceptable ~3% reject average. |
|
|
|
|
Giving this pool a shot today. Looks interesting and the reported profitability seems excellent.
|
|
|
|
The qualifications are:
1) We only save full data for the last 1hr of stats, so if we don't find 2 blocks within the same hour, we don't have an easy way of seeing how many shares on that particular coin were mined. That really only happens on either litecoin, or dogecoin if we skip mining it for a decent bit of time, almost all the rest of the blocks have luck tracked.
Basically, I am interested in a snapshot periodically of the shares we have mined at every difficulty on every coin. And if we found blocks at that difficulty/coin (many rows would be 0 for a KGW coin, presumably). 2) The luck is based on the found block difficulty, which is not necessarily the difficulty the shares were at. For example, if we mine dogecoin as difficulty is on the rise (say some shares at 1k, and then some shares at 1.1k), then stop mining because diff is too high, wait a bit until it drops to 800, and immediately find a block. The luck is based on all of the shares being submitted against a 800 difficulty blocks (which is incorrect for luck calculations, but good enough for my purposes).
I totally understand. And I know the data I am won't look like much on its own. I am interested in calculating basically, "expected profitability" based on shares mined at each difficulty. I just worry with showing these stats that people will freak out. Better option is for me to properly track luck values (just another thing on the list), but that has some (smaller) subtleties as well, since we buffer inserts into our database for share submissions, so data will be off based on when the block comes in compared to when shares get inserted (although very slightly). Maybe I'll work on this in the coming days, luck would be nice to have publicly available.
I think people generally like more stats =). IMO, that's a big part of the reason why WafflePool tends to attract hashpower like it does. Luck would definitely be nice to have public. What I am asking for would require a new row every difficulty change that recorded how many shares were accepted at that difficulty and how many blocks were found (if any). If you felt like throwing that in JSON or something, I could probably build some calculations and a front-end. |
|
|
|
Not to derail this thread (rather, to hopefully prevent it much further): And really, how about cutting out the pointless insults already?
I suggest you re-read your posts directed towards me and count the number of insults that you lobbed in my direction. I said nothing that attacked you personally in my last few posts. Since you seem intent on sticking around this thread, I am trying to ask politely if we can keep civil and productive? -- @PoolWaffle: Any chance you could you make available a table with: EndTimestamp | Coin | Difficulty | Shares | Blocks Found ? Populated every 10 minutes (or even every hour), with: EndTimestamp - population time, Coin - coinid (mined since the last interval), Difficulty - difficulty the coin was mined at, Shares - total shares accepted at this difficulty for this coin (since the last interval), Blocks found - number of blocks found within these shares, if any. I would be interested in using this data to run some statistics on "luck" variance. You guys have such a huge hashrate that you drop the value of mining/day/mh substantially on any coin you mine as soon as you start mining it and then further reduce the value by trading them right away for BTC. Am I wrong>? 31 GH is more than the entire global hashrate of a lot of coins and often almost half of many other more established coins
It's a rough world for altcoins, this is really just a reality. scrypt ASICs are becoming a reality, and are looking to be more significant more quickly then most originally predicted. You can definitely expect 1TH scrypt farms being "common place" on the network this year. This happened with bitcoin too - very few sha256 altcoins survived. You can expect many altcoins to experience private chain drops and complete buy book clearouts. Only the strongest chains will survive for any given proof of work algorithm. How about a pt= selectable payout parameter in the "userpass" config of miners then you could still have peace of mind, still have minimum and maximum limits. Let the user have the responsibility to decide what is a reasonable risk of loss, after all pool mining and trading is risky anywhere.
So if I mine to your address with pt=500 for a little bit right around payout time what happens then?  This is definitely an issue with any sort of password config option. (Unless it is something that can be easily handled per-connection like difficulty). |
|
|
|
poolwaffle deserves to be fairly compensated for his work, but you are delusional if you think it is going to enable him to find some magical formula for higher profitability. We will all be earning 1% less here from now on [...]
Well, I know there are several profit increasing features that PoolWaffle has not had the time or resources to work on. With increased revenue, maybe we'll see some of these functions come to life. That's what I was suggesting (and would take a bet on). I have talked to PoolWaffle previously about some fairly significant upgrades that could increase profits measurably - and I understand they have been on a TODO list. comeonalready: Can you please avoid double posting? It makes threads much more irritating to read. Edit and multi-quote are great features just waiting to be used. And really, how about cutting out the pointless insults already? |
|
|
|
2% seems reasonable to me. It matches almost all of our competitors (who were smart enough to do it in the beginning), and isn't a huge change to the end user (1% to 2% isn't a major change in profitability). And allows me to sink more work into the pool without feeling screwed at the end of the day.
I believe I have said this before, but I will say it again - 2% is very reasonable. Frankly, I think you would be better off increasing it even more (to say 2.5% or 3%), and giving the site a bit more leeway to spend money on improving services. Actually, it will result in 1% less profit for miners, but regardless, it is still within a reasonable range for poolwaffle's services rendered. I disagree. I would bet that overall, this will result in increased profits. Ultimately, the profits here are driven by PoolWaffle's persistence and hard work. -- One thing that I would not mind, would be delaying payouts by a day. This does increase risk by nature of the pool holding coins (something PoolWaffle has previous said he wants to avoid), but would give much more leeway in low-fee spends. |
|
|
|
A few of my R9 290 arrays have been doing a bit of mining for Vertcoin and other nscrypt coins recently. Edit: found a better TC value for the MSI cards. Brings yield up to 442KH/s from previous 426KH/s. Updated details below (but didn't bother taking a new screenshot). These are my stable hashrates:  All Rigs- 4GB of RAM - Barebones gentoo-based mining OS - sgminer compiled from source whenever interesting commits appears on github - General Config: "gpu-threads" : "1",
"xintensity" : "160",
"thread-concurrency" : "28672",
"algorithm" : "nscrypt",
"nfactor" : "11",
"kernel" : "zuikkis",
- Running 5x MSI R9 290 Twin Frozr IV. - Stable just above 441KH/s with very moderate tuning. - These cards are running the OEM supplied BIOS. - Config: "thread-concurrency" : "20481",
"gpu-powertune" : "0",
"gpu-engine" : "1000,1000,1000,1000,1000",
"gpu-memclock" : "1250,1250,1250,1250,1250",
- Running 4x Sapphire R9 290 Tri-X OC. - Stable at 470KH/s, 2x 456KH/s, and 452KH/s (~460KH/s average). - These cards are running The STILT's BIOS. - Config: "gpu-powertune" : "12",
"gpu-memclock" : "1375",
"gpu-engine" : "1040,1020,1020,1000",
- Running 5x Sapphire R9 290 BF4 Reference Cards. - Stable at 3x 455KH/s and 2x 435KH/s (~448KH/s average). - These cards are running The Stilt's BIOS. - Config: "gpu-powertune" : "16",
"gpu-memclock" : "1375,1375,1375,1375,1375",
"gpu-engine" : "1020,980,1020,1020,980",
|
|
|
|
|
Sad to see ProjectXPPS down. Was doing quite well with this pool - although I hope we'll have less disconnects with after it's back. Over to solo mining EXECoin right now.
|
|
|
|
Why the random, sporadic, no set time payments?  To me its smoke and mirrors to do this and makes it more difficult to determine your actual daily payout if one day your payout is for 12 hrs and then next day your payout is for 28hrs? First post, Payouts (Feb 26th) explains the payout scheduling. There was a discussion about it in this thread, if you search back. Now we need Avg BTC per Hour per MH's..
That is a rather useless statistic... we already have BTC/MH/day stats on the main page, and anything shorter then a day is subject to too much variance to be relevant IMO. If you do want more detailed stats, feel free to use one of the other services that access the WafflePool API, e.g: http://waffles.wilschrader.com/ or http://stratehm.net/wilschrader's site has Last Hour, Last 6hr, last Day, etc granularity, and can show BTC/Hour. |
|
|
|
In my opinion the gridseed will kick gpu's from Scrypt, same as before the Asics kicked the Gpu from sha coins. I've said that before and some users said that will never happen, well, I'm not an expert but I think this is already happening, slowly yes, but just wait a bit the next gridseed generation.
Gpu's will need to move, I did it already, I just mine Scrypt-N coins, waiting to maybe wafflepool or another one makes a multipool of Scrypt-N coins.
I doubt it will be gridseeds that cause the end of profitable GPU scrypt mining. They aren't better enough to do that. However, when we see 100MH/s ASIC equipment drop from Alpha-T, KnC, Fibb (if they are legit), and whoever else popups up, GPUs will need to be on another algorithm. My bet is on Alpha-T shipping first, and scrypt GPUs will be unprofitable vs power within the following month or two. I have already moved a chunk of my GPU farm to vertcoin (nscrypt), in anticipation. -- Would love to see a 'vertcoin-like' coin switching pool. EXECoin, Vertcoin, SpainCoin... already enough to be switching on. |
|
|
|
That looks like exactly what the profitability would be for your hashrate. 2.24MH/s is not very much on SCRYPT anymore. Look at the stats page - WafflePool has been hovering around 0.0045BTC/MH/day lately. For you, that would be 2.24MH*0.0045BTC/MH/day = ~0.0135BTC/day (So, .01BTC is something like 20-24 hours). Still more profitable then electricity for me. For many, GPU mining might not be worth it right now. For example, I have very cheap power, and 1/3 of mining income goes to power right now. Many areas pay 3 times as much for power. I will leave that math to you, heh. |
|
|
|
To interpret this for cgminer, you'll need to change a few things - probably something like this... cgminer --scrypt --worksize 128 -g 1 --lookup-gap 2 -I 12 --thread-concurrency 58624 <pool parameters> <nfactor settings> A TC as high as 58624 won't work on any of my cards. Right now, I primarily use either 20479 or 28672 , although different values seem to be optimal for different algorithms/clockrates/BIOS versions. My experience suggests that lower thread concurrency actually yields better results a good portion of the time, and I find the lowest (shaders*n)+1 or -1 value that doesn't produces HW errors often yields the most completed work. I will pull and build YACMiner on one of my rigs setup later and see what happens when I try your posted settings. <snip>
comeonalready just needs to: 1> Backup his personal attacks with quotes 2> STFU I am not looking for a troll war. |
|
|
|
Normally I would not resort to such a tone, but there are certain types of people who only respond from their ego when their stated beliefs are questioned, and I thought it was important to let others here know that some of the advice that phzi has been giving is not entirely accurate, but being presented as absolute.
You mean people like you... who only respond from their ego? I say to you again, please show me what 'advice' I have offered that was not accurate. Stop posting non-contextual bullshit without quotes - aka, stop trolling like a fool. @Thirtybird: please do send me the config inc TC you are talking about. Would be interested to investigate this further. I have yet to run into a situation where RAM beyond 4GB was needed with cgminer varients - and I have done lots of testing. |
|
|
|
The "more RAM is needed" thing is pure unfounded bullshit. If someone is only interested in mining scrypt or vertcoin (At its current N factor), I will say you are correct. Vertoin's N factor will eventually change (at the same pace as glaciers move - across land) On other coins, that increment their N factor regularly, some are up to N=14. If you get more than 2 cards that run 4GB each, you'll want to have 8 GB system ram. The miner software has to allocate the scrypt buffer in system memory to start, and allocating a 3.5 GB buffer for 3, 4, or 6 cards just doesn't fit into 4 GB of RAM. I just fired up 5x R9 290 cards at N=12,13, and 14, with 4GB of system memory for several minutes at each N. Seemed to compile/load the kernel and hash fine. This might not be the case on windows, mind you - I run a custom gentoo install on all my rigs. |
|
|
|
I might be wrong, but I think it's about RAM on the graphics card, and that's part of the reason why Scrypt-N11 performs at half the hashrate of Scrypt-N10 on the same hardware. I'm running my rigs with the same 4GB as always, it doesn't seem to require any more system RAM.
But no, all people talk about having 8 gigs of ram. You absolutely do not need more RAM to hash... I never run more then 4GB of ram on a rig, and I average over 900KH/s/card at scrypt(1024,1,1) and 450KH/s at scrypt(2048,1,1) on my R9 290s. The "more RAM is needed" thing is pure unfounded bullshit. Others here have already pointed out flaws in some of your arguments, but you were yelling too loudly to hear them.
More unfounded bullshit without quotes to back it up - no surprise. The only one I have seen yelling is you... And it appears you are yelling because you don't have anything to back up what you're saying. Does the bold make you feel more correct, lol? Again, you want to debate something specific, go right ahead. You continue with unfounded personal attacks with no basis or background, and I will continue to show you for the utter fool you are. I'm not one to get angry, but I have no problem picking apart an internet persona like yours. It's pretty obvious this isn't your first account anyway. I would take a bet that your previous account(s) got trolled so badly because of the dumb things you say, that you had to abandon them and create a new account, lol. |
|
|
|
Let's analyze how ridiculous this guy is, before I put his dribble on ignore and forget about it: You are missing the point completely and if you cannot imagine another attack scenario, then your imagination is limited. I never said anything regarding other attack scenarios... I have talked about the recent hijackings. Obviously there are a ton of ways to hijack purposed mining rigs, the same as there are a ton of typical computers with CPUs and GPUs that could be hijacked for mining. If you happen to look back through this thread, you will find that I was the first to suggest that client.reconnect was being used as part of the attack. Good for him, is he looking for a pat on the back? Because frankly, I am unsure why this matters to this current conversation. And also that mostly all of the ideas you presented as your own were only summaries of ideas that others had posted here before you -- with the notable exceptions of your misconceptions, that is. I definitely haven't claimed anything I've said was my original invention. Usually, you'll see when I post, I am responding to something - expanding conversation. You know... the point of a forum? I am definitely NOT here to argue with someone like comeonalready that cannot even present an argument, and instead falls back on ad hominem and un-evolving attacks. If you want to actually debate something with me of relevance in this thread, then that might be interesting. Instead, comeonalready seems intent on having a bigger e-penis then actually trying to learn something, or explain why exactly he thinks something like: It is all in the thread history. I am not going to correct your errors, as you can continue to believe whatever it is you wish to believe, but I am only posting this response as an advisory to others not to place too much value in your "facts", as some of them are only your opinions, misconceived as a result of misinterpreting relevant details. Simply stated, you are drawing false conclusions from an incomplete set of actual facts. Notice he didn't point out a single thing that I have said that is wrong. If it's in the thread history, why isn't he quoting it? This guy must be flat out threatened by me, and annoyed that his thread e-penis is in danger. lol You're funny -- as in you amuse me like a clown Heh, awesome. I was going to say the same thing about you. Trolls that think they can actually win an argument without providing a contradiction with evidence to any quotation and are unbelievably priceless. Peace out! |
|
|
|
Just thinking about it, who has experience with vertcoin here? I was thinking whats the MH/BTC/ Profit ratio with this? say you want to chuck 10-14 x R9 290x at it
I am averaging about 0.012BTC/MH/day with vertcoin right now (running 10x R9 290). But that MH value is ~50% of my scrypt(1024,1,1) hashrate. So compared to wafflepool, it would be about .006BTC/MH/day. Mind you, I'm speculating on vertcoin, so I'm not exchanging immediately. projectxpps.com is pretty awesome if anyone wants a good vertcoin pool, btw. PPS and 0% fee right now. Where do you think that client.reconnect command originated anyway? It was not sent by your legitimate stratum servers, that's for sure. And not just anyone can send it, it must arrive on your open stratum connection, or forged to look like it, in order to be processed. Or the attacker must have been able to break your active stratum connection, or wait for it to break naturally, and then redirect you to a rogue server in order to send you that client.reconnect command.
I watched the attack occur and did some analysis (apparently unlike yourself?), and I don't believe there was any prior 'redirect' to a rogue server. My prior comments are more then just speculation... The client.reconnect command appeared to come from the legitimate stratum server. Aka, was "forged to look like it" as you suggest above. I explained above in reasonable detail exactly how such an attack could be potentially replicated. Go try it yourself if you have enough knowledge. The only other attack method I can imagine based on what I observed, would be TCP injection at (a) key router(s) (by modifying packets and re-calculating header checksums). But, I highly doubt this is the case (else it probably would have been more wide-spread). I can also assure you that it is still possible at this moment to capture the TCP headers of traffic destined for other servers on OVH right now - more complicated then it was a few months ago since they have been patching their switches, but still possible. The TCP header of course contains the miner IP, port, and current TCP sequence number - which, given the right setup, would be sufficient to counterfeit a packet from the stratum server. You might want to read about TCP injection attacks relating to TCP sequence prediction, if you were not aware this is possible: http://en.wikipedia.org/wiki/TCP_sequence_prediction_attackFYI: I don't talk about things I am not knowledgeable about. I have nothing to prove (obviously unlike yourself), but I can assure you my knowledge of networking is higher then you might like to believe. What/where is this patch?
It is not a complete solution, but it does help to a degree, if the next attack mirrors the previous one. Client.reconnect commands were included in the stratum mining protocol for a reason. The 'patch' to which you are referring is built into the latest versions of kalroth cgminer and veox sgminer. Just check their docs for use of no-client-reconnect option. But be forewarned, some pools might legitimately utilize the command, either now or in the future, so to enable it could break certain functionality. But poolwaffle has stated that he does not ever use it, so safe to use here. It is a complete solution tho... If a pool wants to re-direct my miners somewhere else before the pool goes offline or something, I don't care - that's what fail-overs are for. There is no overly useful case for Client.reconnect that I can imagine. The stratum commands client.reconnect and client.get_version were added to cgminer in v2.8.2, as an aside. In the copy of sgminer I am running, I simply disabled the client.reconnect ability entirely. Was a 5 second patch. The reason Slush added client.reconnect to the protocol, btw: * Implemented method client.reconnect(host, port), so pool can now easily balance clients between backends or gracefully shutdown a backend without a miner outage.
After it was requested by eleuthria: Please just adopt the two commands I posted about previously: A redirect command for a poolserver to send miners elsewhere, and a server restart notification [with timer] so a pool can attempt a graceful restart rather than suddenly dropping connections.
|
|
|
|
what makes you think that reconnect issue has been solved?
It is solved for anyone that patched or updated their mining software. |
|
|
|
Also all miner developers need to be made aware of "no-client-redirect". I have been unable to find a contact address for Veox/Sgminer.
You did not look very hard then - the obvious place being sgminer's source repo on github. Sgminer has supported no-client-redirect for 3 days now. https://github.com/veox/sgminer/commit/01b3f70b63d530e222d647de1a87ae4716e6ab0eIt is also a trivial patch to apply yourself to almost any cgminer derivative. |
|
|
|
|
Show Posts
