We should not use 24 hour actuals in our profit switching script, that makes sense.
But current estimate has a high fluctuation.
Does anyone see a reason why we should not just use the average of both values? (as long as current estimate is not zero)
Or we could just check if current estimate is not zero and still use 24 hour actuals?
I use a customized version of Nemos which does some of this. I'ts less switching than CurrentEstimate / more than Actual24hr. Works great for me since about 2 weeks. Moreover with the current down trend. Following Actual 24hr is not great. Made it available here: https://github.com/MrPlusGH/NemosMinerPlus-v2.4.2/releases. Have a go if you like. Holy Cannolis, I was trying to teach myself enough about powershell scripting so I could modify NemosMiner to do something almost like this! My idea was to frequently query the pool for the highest profit algo, but do a moving average of the results to reduce chasing some shit-coin just because it shot up in profitability for all of 5 minutes. Also, some auto-switching pools inexplicably use PPLNS (though, granted, I don't know what "N" is) so frequent coin - much less algo - switching could be even more painful. |
|
|
|
@vimaxus Thank you for trying blazepool out.
@robl450 Sure it's risky to try a new pool. You're surely welcome to wait a couple of days to see what people's comments are and maybe you'll think about trying for a few days for your rig. Happy and good luck mining!
Blazepool
I got a small rig. .005 take me a month or more. No reason you can't do smaller payments once a week or something like other pools. Totally agree. After the zergpool debacle* I am loathe to try out new pools at all, much less pools that I'd need to mine there for 1-2 weeks to hit the minimum payout with my test rig (2x GTX 1080). * - I lost 40% of 6 days worth of earnings because of a hard fork, then a week later the pool wallet is hacked and 1 BTC was stolen, then the pool goes offline completely from a DDoS attack, which there should have been some protection against in the first place. |
|
|
|
Reported hashrate means nothing. Run both miners in parallel using the same cards and different wallets and then compare the results.
That's precisely what I did a few pages back and reported in this post: https://bitcointalk.org/index.php?topic=2565979.msg29675722#msg29675722I've been advised that I should have used pool-reported average hashrate for 24 hours instead of payout, and I finally understand why, but in the above test I did run both miners concurrently on the same pool but pointed to different wallet addresses so only a difference in average luck per share would cause a difference in payout, besides average hashrate, of course. |
|
|
|
Got my 1050 and 1050 ti "experiment" cards in today.
I'm NOT impressed.
EVGA 1050 single-fan 2GB, EVGA 1050 SC single-fan 2GB, EVGA 1050 ti single fan 4GB.
ALL of the cards have a hard-coded TDP limit at 52.5 watts, they will not LET you go lower at all - so 70% is the minimum, which doesn't leave a lot of room for tuning.
Performance on the SC vs the non-SC 1050 models was identical to within measurement limits, EXCEPT the SC model would not allow as high of an overclock.
On ZEC, the best efficiency was about 2.7 watts on the 1050 ti, 2.5 on the 1050 cards.
Efficiency was pretty much FLAT between 70% and 80%, then dropped off some a little above that.
Max hashrate was about 153 on the 1050 cards, 175ish on the 1050 ti, dropping about 25 hash on all 3 at 70% TDP.
...
I always love reading your analysis on GPU's, helped me out a lot with my first 1070ti rig, but always good solid info across the board. sorry those 50ti's weren't too impressive. I've been tempted to test some lower end cards but have been pretty good and sticking to those with 8GB memory for "future proofing". The exception being a couple of MSI 570 4GB , but I am trying to complete that rig with the 8GB versions (have 2 already) when they become available then eventually replace the 4GB ones... so really don't want more than maybe 2-3 max on that 7-8 card rig. Will get that up and running and well as my 2nd 1070ti rig after the electrician comes out next week and drops my 4 new 20-amp outlets. My Zotac GTX 1050 Ti performed better overall than QuintLeo's. I just sold it, so no more testing is possible, but below are the results from each of the algos I tried, and in each case actual clocks reported by MSI AB are given. The core clock was never stable, so it's an "eyeball average," but mem clock usually was, and I didn't mess with power limit at all because power usage reporting is broken in the 1050 Ti, from what I understand. Neoscrypt - 460 kH/s ~1770 core; 3700 mem; ccminer-klaust 8.19 Equihash - 190 Sols/s ~1835 core; 3800 mem; dstm 0.5.7 Ethash - 13.4 Mh/s ~1885 core*; 3800 mem; claymore dual 10.5 (* - at that time I had not yet learned that core clock doesn't matter with Ethash) Lyra2RE2 - 14.8 Mh/s ~1860 core; 3800 mem; vertminer 1.0 So, by no means an outstanding performer, but I felt it was decent enough at Equihash and Lyra2RE2 that it would be compelling at the original MSRP of $140 or so; at the current retail price of $230US or a used price on eBay of $180+, however, it makes absolutely no sense to own, much less buy new, so I sold it. But continuing on the, "let's play with cheap cards because buying anything else is madness right now," theme, I've picked up a couple of 2GB RX 560's and have so far just been tinkering with Cryptonight. I've got them up to a very stable 460 H/s each which is pretty respectable if the price is $150 or less. That's about the same hashrate as a Ryzen 5 1600 with a "tweaked-to-within-a-gnat's-hair" xmr-stak. |
|
|
|
I got a 2nd XFX RX 560 (2GB) running on my Onda D1800 and here's the relevant portion from the .conf file for SGMiner-GM 5.5.5 that gives me the best performance (so far, anyway): "profiles":
[
{
"name": "xmr",
"algorithm": "cryptonight",
"rawintensity": "416,416",
"worksize": "8,8",
"gpu-threads": "2,2"
}
],
Again, this is for two GPUs; if you have just one then there should only be one each of 416, 8 and 2 in the above profile. Conversely, if you have more than two then extend the comma-delimited list as necessary. Getting a very consistent 460 H/s per GPU with 1200 core / 1900 mem and 100% power in MSI AB. Also used the one-click timing patch in PBE and patched driver with pixel clock patcher - the usual shenanigans required with AMD cards, in other words. |
|
|
|
We don't know what the real goal of devs is (exept to earn a lot of money)   BUT! You have to know that new coins in the crypto-world like dark horses - they can shoot up you fckn brain out or make you are the happiest and the richest man on the Earth Not releasing all the view keys seems shady at best to me I like to jump into a lot of projects early with a bit of hashing power but this one doesn't seem like one I want to hold lately. I am excited for an exchange tho!  Yeah, this is definitely the least-promising/most-sketchy of my speculative shit- alt-coin bets, which is why the only resource I've devoted to its mining is a single AMD FX-8300 CPU (340 H/s  ). |
|
|
|
Different thoughts, rarely have developers who have such thoughts, maybe with your input this can draw again the process that will be done next.
Please tell me I'm not the only one to think of "Jack Handey" and his "Deep Thoughts" sketches from SNL after reading this...  |
|
|
|
|
I agree with the earlier comments about displaying the actual coins available for each algo.
Also, it looks like you have the same selection of algos as other popular auto-switching pools; one of the things I really like about MiningPoolHub, for example, is it offers Equihash and Ethash coins. That alone almost makes up for its byzantine and convoluted layout.
|
|
|
|
...another exchange doesn't matter if it's a downgrade from Stocks.Ex lol
I didn't think a downgrade from stocks.exchange was possible; now I know it is. |
|
|
|
The math is a fairly accurate estimate, but each system varies a bit because of motherboards, drivers, voodoo/kami, etc.
On my 560s (4gig) I use 508, w4, g2. - 450h/s (on another board, 480 was the magic number)
On my 570s (4gig) I use 896 w8, g2. - 840h/s
All are bios modded, and moderately overlcocked at 1860-1880.
Heh, those are exactly the numbers I have programmed for my RX 570... Too bad the miner crashes so soon after startup, and doesn't even leave a debug log despite setting... Wait, I got it running after I removed the switch "--shaders 2048" from the command line (forgot I had that) and changed the debug switch from "-D" to "--debug-log", which really shouldn't have affected anything. Unfortunately, the bad news is that the hashrate is terrible - about 90 h/s so far. But, I can work with a bad hashrate; I can't work with an instant-crashing program. EDIT - Oh, I forgot I also changed "gpu-platform" in the config file from 1 to 0; I suspect that is what solved the problem - as I think I read somewhere else, 1 is for systems with an integrated GPU on the CPU. |
|
|
|
OK, I see the point about completing the technical roadmap before a more general widespread promotion/listing of the coin.
Is this proceeding smoothly/to plan, do you think?
Better than I expected, can't speak for others though. The project is barely 2 months old, and the devs have already showcased / beta tested a fully functional daemon in Golang. That's more than some other projects I'm involved with have accomplished in 6 months. Yep, I agree. The steady progress and calm demeanor of our fearless CaptDero is why I switched some GPU hashpower back over to this coin even though the difficulty is horrendous and the present-day income/day is terrible. |
|
|
|
I'm really ready to bet 1USD for 65000 EDL. 2 days only!
Good luck with that. If I am only going to miss out on $1 (hell, $100) by holding on to 65k of a coin, I'd rather just hold on to it. |
|
|
|
My mining rigs are at another location. They have nothing critical on them. How much more speed are you getting as compared to EWBF? Which VB runtime do I need to install for this program to work?
Both this and dstm 0.5.8 are faster than ewbf on my machines by enough margin to make it compelling to switch, but given the stability issues I've had with bminer as well as the general shadiness of the developer (sock puppet accounts? really?), I am using dstm. I installed VB runtime and am trying this miner. So far it seems to be getting a higher hash rate than EWBF. There is nothing to steal on my mining rigs except hashes. Rigs have not crashed yet but only been running about an hour or so. One stability issue I had was that bminer appeared to be running normally, but hashrate at the pool dropped to zero like it was disconnected; this went on for about an hour before I noticed it. |
|
|
|
My mining rigs are at another location. They have nothing critical on them. How much more speed are you getting as compared to EWBF? Which VB runtime do I need to install for this program to work?
Both this and dstm 0.5.8 are faster than ewbf on my machines by enough margin to make it compelling to switch, but given the stability issues I've had with bminer as well as the general shadiness of the developer (sock puppet accounts? really?), I am using dstm. |
|
|
|
This miner appears to have been abandoned, which is a real shame because despite being last updated over a year ago it still performs the best by far on Cryptonight with an XFX RX 560 I recently bought (and which I'll be getting 5 more to make a cheap Cryptonight miner). Despite the apparent abandonment, I read every single post of this thread looking for an explanation of rawintensity, worksize and gpu-threads and, incredibly, these critical parameters are never really explained. There are bits and pieces here and in the (3+ year old) .md files on the github repo, but it is not clear if those partial explanations apply to all algorithms or just Ethash (the fragments I found here) or Scrypt (in the mining.md file on github). So here is what I picked up from a couple of posts by OhGodAGirl (one of the original devs of SGMiner), which I've paraphrased/combined below: The formula for rawintensity is #(CUs) x worksize x 4 - so, for a 280x, you'd have 32 x 4 x 4. That gives us 512.
Worksize of 8 can be used, but make sure to change gpu-threads to 1 then (instead of 2).
Start with above calculated rawintensity then decrease by 8 to find best hashrate.
Don't ever use xIntensity. Rawintensity only. Now here's the kicker... below are the settings that are working the best for my single RX 560 with just 2GB, 16 CU and 1024 shaders: rawintensity = 416 worksize = 8 gpu-threads = 2 And this contradicts the advice to set gpu-threads to 1 if worksize is 8... I'm not going to sweat that, though, as this combination really does quite well, all things considered - about 460 H/s, which is 40-60 H/s better than the next best performer, xmr-stak. Even worse, though, is that I have a single RX 570 4GB (which is what I was going to use for a dedicated cryptonight/ethash miner, until prices went full retard) and sgminer crashes immediately after displaying the two line screen about Jannson 2.7 (can't catch it, it goes by too fast), even if I don't set anything for the above parameters.It's a bit of a longshot, I realize, but any sort of clue as to where to go next in troubleshooting would be helpful. Drivers are Adrenalin 18.1 (Jan 18) and not in compute mode (since that doesn't really help Cryptonight, at least from what I've noticed). |
|
|
|
Apology accepted. But you're still not taking into account PPLNS, a reason why I suggested you do some reading (not all shares you submit are paid, not all blocks are equal in either length or difficulty, not all last N shares span a single block, etc). Yes, I've actually just started learning about PPLNS, mostly the hard way... I was mining VTC on give-me-coins for awhile but the time to find a block was really long and quite random - ranging from 20 to 100 hours... Needless to say, if the PPLNS window was set for 30 hours, as this was the average ttf reported by the pool at the time, then if it takes 100 hours a whole bunch of your shares will get tossed out. it seems bminer was faster ... but as was pointed out earlier, @realbminer could have just watched this thread and tweaked with the fee to make it 2% faster by removing the fee for the duration of that test for all we know. It is the most untrustworthy and suspicious miner out there, hands down. Add that @realbminer didn't address the questions and you have an explanation why people are not trusting this miner and are sticking with dstm's. Remove the private connection if you want to be taken (more) seriously.
I think we'll file this under, "Just because you're paranoid doesn't mean your miners aren't out to get you." |
|
|
|
|
To all who've been following the last couple of pages as the discussion between me and @cryptoyes turned nasty, I apologize both to you and @cryptoyes. In what will no doubt come as no surprise to @cryptoyes it was I who was in error and I actually took the proverb - and advice given - to heart by going back through the thread to try to find what I missed.
Turns out, the crux of the argument for using average hashrate reported by the pool rather than payout or even share count is that the average hashrate may not be trustworthy on an absolute basis - ie, the pool could be under-reporting it to skim a little extra for itself - but it should be trustworthy on an absolute relative* basis; that is, any doctoring of this value can be expected to apply equally to any given miner at any given time.
One only needs to know the time frame for the averaging function - ie, 24 hours - and make sure the length of the test is equal to or greater than that time.
Payout is /not/ a good metric because it is the sum of all shares found and that number can vary depending on luck as well as hashrate (assuming a fixed share difficulty is used; with vardiff share count is totally useless).
So, again, my apologies for cluttering up the thread and potentially misleading anyone with my flawed testing scheme. If there is any value in my repeating the test with my lowly dual 1080's I will in a few days.
* - oops, a really bad mistake here; fixed.
|
|
|
|
|
I've been trying to compare miners and pools using two GTX 1080 cards in separate computers that I've adjusted clock rates/power limits in MSI AB so that any given miner will hash at the same rate on either machine. I assumed that I would get reasonably valid results by having the two competing miners run at a fixed share difficulty for 24 hours to separate addresses on the same pool then reporting the total payout for that time period, but 3 separate people have said that payout is not a reliable metric and that I should be counting the number of shares or even the average hashrate reported by the pool instead, but I honestly can't see how either of those metrics would be any better than payout. I should note that I am not looking to validate my position here, rather, I really want to know why it is wrong (if it is)!
So how do you veteran miners evaluate which miner delivers better performance?
EDIT - well, no thanks to you slackers I think I figured it out (I hope!); hashrate reported by the pool may, indeed, be suspect, but it should be equally suspect regardless of the miner. Conversely, there will always be variability in the time to find a share even at a fixed difficulty and since payout is a direct function of share count * difficulty it will also have some variation based on luck, as well as the hashrate.
So, carry on!
|
|
|
|
@MagicSmoker ... whatever you say.
Lol, just like the assholes in the hsrminer thread that kept saying I was wrong to use payout but never once explained why. You did give a partial explanation, but it seemed to be based on the /belief/ that only share count in a given period of time matters. But then you also said that I need to set difficulty lower for my hashrate because there will be too much variation in the time between shares. Please square that circle, because you can't have both be true. |
|
|
|
|
Show Posts
