| #1 | *
New free opensource x16r miner without a fee https://github.com/sp-hash/suprminer/releases/tag/spmod-git1 will add some more speed later. Thank you! New free opensource x16r miner without a fee https://github.com/sp-hash/suprminer/releases/tag/spmod-git1 will add some more speed later. Amazing!! when will you release a faster version? I tested this one and it's still slower than the Enemy miner
New free opensource x16r miner without a fee
https://github.com/sp-hash/suprminer/releases/tag/spmod-git1 will add some more speed later.
thank you so much JackIT for your tests! I split test a lot of pools and suprnova always, always comes out on top by a landslide.
I decided to do pool testing using my three balanced instances. The pools I'm testing are: Suprnova, Ravenminer and CryptoPool.party
I'm sure everyone has heard, "earnings from various pools should more or less even out over the long term" and while that's mostly true, there are several things that can impact earnings on one pool versus the next. Here are some things that can comparatively impact pool earnings.
Final Cumulative results after 5 days of testing:  Day 1 results:  Day 2 results:  Day 3 results:  Day 4 results: 
Have you done any testing using nevermore 0.2.2?
After my most recent test run, the results were very lopsided. I started to question whether my instances were still well balanced.
So I immediately fired up a test of the instances, using the same settings (no static diff), all three using Enemy 1.08. The results below. are validation of how balanced they really are, (kinda surprised myself) just 1.5% separates all three instances Results: 692 Minutes - No restarts
I also found that the pool reported hash rates and avg hasrate line, for the three instances are all over the place, yet produce the same results... I really don't have much faith in Yiimp pool reported hash rates    Inspired by JackIT and his 1080TI tests, I ran my own little experiment with 21X1070Ti. Best ROI on 1070TI with Enemy 1.08, at Virtopia I have 21 GPUs, all 1070TI, sitting on 4 different rigs, all slightly different builds, one rig is 6x MSI Tritium, another is 5x MSI Gaming, the last two are 5x a mix of EVGA, Gigabyte, and MSI. 4 rigs; 3x5 GPUs and 1x6 GPUs. All were mining on Virtopia – each rig tracked separately but under one wallet address. I ran 12hours at each setting and recorded the average hash rate at the end of each 12 hour period. Perfect test? No. But it does confirm much of what JackIT found in his tests with the 1080TI. After 12 hours at each setting, the average of all 21, Enemy 1.08, Auto Diff, auto i, Virtopia pool: 85%,+150,+200 – 11.90 MH/s per GPU - Baseline 80%, +150,+200 – 11.95Mh/s per GPU – increase of 0.4% 70%, +150, +200 – 11.58 95 Mh/s per GPU – decrease of 2.7% over baseline 70%,+0,+0 (no OC) – 11.29 Mh/s per GPU – decrease of 5.1% over baseline The change between 80 and 85% showed that there was no significant difference. Clearly as the TDP was reduced, hashing fell off. As for OCing, there is a benefit to overclocking too. This, at least in my thoughts, confirm what JackIT is seeing in his tests and confirms the settings suggested in Enemy’s Readme file: 80% TDP and slight over clocking. I know my testing isn't as thorough in methodology as Jack's - but: I took off the Core over-clocking for 24 hours : 80%,0,+200 The hash rates under-preformed the benchmarks by 1-2%, just enough to be statistically relevant/noticeable. Now I'm trying to "push" the 1070TI to it's limit. I'm bumping up the core and mem without crashing. I'll post the outcome once finished. Enemy 1.08 Vs. a1min3r 1.4.2 Vs. Silent Miner 1.1.0 Test Results are can be found: https://bitcointalksearch.org/topic/m.35754113 Nice - and that is all she wrote folks. Excellently done.
Enemy 1.08 Vs. a1min3r 1.4.2 Vs. Silent Miner 1.1.0
Test Results are can be found: https://bitcointalksearch.org/topic/m.35754113 Even WITH variability is average. It just takes time and a lot of patience. This is why even if there is a huge variation in Algo pairing, over a finite period of time, mined many times over, a pattern and 'average' hashrate surfaces. The amount of time is determined by the fluctuations of hashfunctions involved, and as such, can still be determined. As mentioned above though, time is the key factor here, regardless of what cards are being used. If there is a static source of testing, and a static method of testing, then comparisons can still be made over a static period of time. #crysx Agreed, but you need to determine the amount of time needed to establish an average with an acceptable level of confidence. is 12hrs enough? that will get you through about 720 permutations of x16r, out of 1.84e+19 possible combinations. We must understand that the Algo does NOT go through ALL the permutations ALL the time, only some. Once that is established, a reasonable amount of time needs to be set. We at CWI have ALWAYS tested in the long term, even with 'stable' hashrate Algos, of 24hours to 72hours. This allows for any anomalies to enter and then the test is redone over and over again. This is the only way to be sure of the results, and have a more accurate estimation of hashrate. If you think this is difficult, try Timetravel10 which has more permutations than you can poke a stick at, yet there was NEVER this sort of fuss about it, until RVN came olong. Seems weird how the community can pick and choose which Algo is an Algo to be looked at and picked at, and others to be left alone. The base conditions for ALL algos is time and non-variable testing equipment. That is pretty much it. We will not mess with this sort of situation because as with TimeTravel10, a LOT of time and effort is wasted over the smallest things- especially when we were building our miner - CWIgm. So to test this 'properly' make sure you have three weeks available to do so. We will not commit that time to this, we will commit that time to the real work involved in designing, development, and physical work we have been doing. Have fun doing this though, as it is quite a learning curve if you have never done thins before. #crysx Jump to:
|
