 Show Posts
|
|
Pages: [1]
|
So, I did the test I mentioned earlier in the thread. I created a QBIC wallet and picked up two different send addresses. I picked QBIC as it would generate a fair number of blocks per hour based on the history for that coin. I have two 1080Ti cards of the same brand/spec (Gigabyte). They are exactly the same. Both are overclocked with the same settings: +100/+400 80% I created two batch files one using hsr_miner and one of the addresses, and one using CC-miner-Klaust and the other address. Both were directed at the same port in BSOD pool. I started both batch jobs at the same time and let it run for 80 minutes roughly then paused for the night and carried on for another 120 minutes this morning. Both miners behaved well although KlausT had two rejections (99.22% efficiency). There was one pool disconnect (that I noticed) but both miners experienced this and it was only during 10 seconds The reported hash rates from each miner were : KlausT : 1480 kH/s hsrminer: 1790 kH/s During these periods 58 QBIC blocks were found, and the results in earned coins were: KlausT: 0.07451398 QBIC hsrminer: 0.07188344 QBIC One interesting fact is that the pool for some reason reported a somewhat higher hashrate from hsrminer during the tests, but the results were more or less at par. I pulled out my google docs skills (quite limited  ) and created the graph below. The red line is KlausT and the blue line is hsrminer.  While luck certainly is a factor in these matters it seems as if the promised edge just isn't there, but perhaps a longer test is needed. Feel free to post any objections to this test and how it can be improved. I'm sorry but there is a VITAL piece of information you are missing. QBIC is completely unreliable source to try to benchmark against because it is always under nicehash attacks. Hashrates can go from 1ghs on a pool to 20/30 even 160 I have seen. But why is that a parameter? If I am running both miners towards the same pool at the same time they should have the same basic preconditions right? Aren't more or less all neoscrypt coins mined by Nicehash? |
|
|
|
@Zorday , great job on the testing but yes, a much larger testing window would be better. If a baseball batter got up to bat 3times and got 2 hits you'd think he was the greatest baseball player in history by looking at his average. As the batter got more at bats the natural average would kick in and you'd see he's only batting .230 and now we're dumping him back into the minor leagues  A slightly higher hashrate with higher shares submitted should produce better results over the long haul but because the increase is so minor, we're talking 5-8% at most, a much longer time period would be best to flesh out this very minor increase. Definitely on the right path though for testing the two and I appreciate the info. Agreed and I will do more tests... I have to restart though as one of the miners got disconnected yesterday and I was not paying attention. Yes I am well aware that the stats are a bit scarce, but still I would expect to see a slightly different angle on the slope. Isn't the difference more like 20%? 1480kH/s compared to 1790kH/s reported? |
|
|
|
So in your diagram the legend is missing what is blue what is red..should we guess out of the blue?
..mh
yes you can guess or you can read the post Anyway I fixed legends now in the original post. or here: |
|
|
|
So, I did the test I mentioned earlier in the thread. I created a QBIC wallet and picked up two different send addresses. I picked QBIC as it would generate a fair number of blocks per hour based on the history for that coin. I have two 1080Ti cards of the same brand/spec (Gigabyte). They are exactly the same. Both are overclocked with the same settings: +100/+400 80% I created two batch files one using hsr_miner and one of the addresses, and one using CC-miner-Klaust and the other address. Both were directed at the same port in BSOD pool. I started both batch jobs at the same time and let it run for 80 minutes roughly then paused for the night and carried on for another 120 minutes this morning. Both miners behaved well although KlausT had two rejections (99.22% efficiency). There was one pool disconnect (that I noticed) but both miners experienced this and it was only during 10 seconds The reported hash rates from each miner were : KlausT : 1480 kH/s hsrminer: 1790 kH/s During these periods 58 QBIC blocks were found, and the results in earned coins were: KlausT: 0.07451398 QBIC hsrminer: 0.07188344 QBIC One interesting fact is that the pool for some reason reported a somewhat higher hashrate from hsrminer during the tests, but the results were more or less at par. I pulled out my google docs skills (quite limited ) and created the graph below. The red line is KlausT and the blue line is hsrminer. While luck certainly is a factor in these matters it seems as if the promised edge just isn't there, but perhaps a longer test is needed. Feel free to post any objections to this test and how it can be improved. |
|
|
|
Isn't there a pretty easy way to settle this that will remove unknown factors?
1- Create two different receiving addresses for a wallet in a neoscrypt coin.
2- In a system with two equivalent cards run one instance of hsrminer and one instance of klaust ccminer towards the same pool but use one wallet address for each process.
3- Let it run for an hour
4- Inspect earnings as reported by pool.
This would make both systems run on the same difficulty levels at the same time and therefore remove as many differences as possible. Of course luck will enter into the picture, but I imagine that one hour should be enough to let this even out. Otherwise it's always possible to run longer to rule out luck as a factor (not completely of course but to a reasonable level).
Yes, that would be the next approach I would use. I was already running a comparison on my two separate GTX 1080 systems which is why I did a consecutive 24 hour test of hsrminer vs. ccminer. Currently those two systems are doing a head-to-head comparison of dstm vs. bminer mining ZEN on luckpool.org and I was next going to do a comparison between zergpool and hashrefinery because preliminary testing of both has proved very promising. Yes I will try to do a test as well during the weekend to be able to get a personal verdict. I have no access to several rigs, but I have several cards of the same type so I should be able to set it up as described fairly quickly. What is promising? |
|
|
|
MagicSmoker, I don't mean to be insulting but you have very little understanding of how to compare miners. Comparing how many coins you get is absolutely useless. Coins mined means nothing, zero, zilch. You can't predict a difficulty level so using coins as a comparison method is worthless. Stop posting about how miners are better or worse by measuring coins, it's silly..
Translation: "I don't mean to be insulting but I'll insult you anyway..." I did not base my evaluation strictly on the # of coins mined, I based it on that vs. the average difficulty for 24h as reported by minethecoin.com, and then I recursively iterated the hashrate required to get to the actual number of coins. If there is a flaw in my methodology please take the time to enlighten me rather than merely call me silly and my post worthless. EDIT - and yes I realize that running the miners concurrently on separate, identical rigs mining to the different wallet addresses on the same pool is the ideal methodology, and maybe I will do that next, but at this point I am not seeing any reason to spend more time on the evaluation given the response so far. Isn't there a pretty easy way to settle this that will remove unknown factors? 1- Create two different receiving addresses for a wallet in a neoscrypt coin. 2- In a system with two equivalent cards run one instance of hsrminer and one instance of klaust ccminer towards the same pool but use one wallet address for each process. 3- Let it run for an hour 4- Inspect earnings as reported by pool. This would make both systems run on the same difficulty levels at the same time and therefore remove as many differences as possible. Of course luck will enter into the picture, but I imagine that one hour should be enough to let this even out. Otherwise it's always possible to run longer to rule out luck as a factor (not completely of course but to a reasonable level). |
|
|
|
I don't get it, got the hsr miner and a bat file but the miner won't launch. Does somebody know what I'm doing wrong?
hsrminer_neoscrypt.exe -o stratum+tcp://eu1.altminer.net:10004 -u xxxx -p c=CRC pause
try adding -a neoscrypt before -o Mind you. hsrminer is probably a scam miner that just reports higher hash rates without actually doing the work. Not certain though. I always had AMD and since a few weeks Nvidia, so I don't know what miners are best. Which miner do you recommend? Assuming that the above is true (that hsrminer is boogus) KlausT is probably the best option: https://github.com/KlausT/ccminer/releasesEDIT: My answer above was probably wrong.. hsrminer has different parameters than ccminer so you probably had another issue. But you can at least try KlausT as an alternative. |
|
|
|
I don't get it, got the hsr miner and a bat file but the miner won't launch. Does somebody know what I'm doing wrong?
hsrminer_neoscrypt.exe -o stratum+tcp://eu1.altminer.net:10004 -u xxxx -p c=CRC pause
try adding -a neoscrypt before -o Mind you. hsrminer is probably a scam miner that just reports higher hash rates without actually doing the work. Not certain though. |
|
|
|
|
How are you guys mining this with 1080Ti? Which miner?
I run into problems after a few minutes mining (Unspecified launch failure and hash won't validate on CPU etc.)
I found a couple of advices on the net indicating that I should lower intensity and specify power limit but it doesn't seem to have any effect.
|
|
|
|
|
So basically what this boils down to is that this is yet another crypto-scam.
Take the open source. Recompile it, add dev fee.. Make up the hash numbers so they look awesome and seem to outperform everything else out there and bam...
Big money rolling in.
In fact, I was wondering if there isn't more to it...
I mean, when you're dealing with people that nag your wallet can you expect them to be half good?
I am thinking about this "false positive" that we see from the threat manager. Can anyone actually confirm that this is not in fact some sort of add-on malware to the whole scheme? We're so used to seeing Anti-viruses flag the miners that we another positive will slip neatly beneath our radar...
Too many question marks I think...
|
|
|
|
Can someone please point me to an api where I can get the current difficulty either as json or a plain number?
Thanks
Here is what you need? -> http://tunecrypto.com/explorerThanks, but I'd prefer not scraping that page. Isn't there an api? Still looking for an api... Does anyone know where it is possible to pick up the current difficulty without scraping a pool web page (or the explorer). Thanks |
|
|
|
Can someone please point me to an api where I can get the current difficulty either as json or a plain number?
Thanks
Here is what you need? -> http://tunecrypto.com/explorerThanks, but I'd prefer not scraping that page. Isn't there an api? |
|
|
|
|
Can someone please point me to an api where I can get the current difficulty either as json or a plain number?
Thanks
|
|
|
|
Anyone got any idea how to restart my miner
I mean after the miner crashed how to restart it automatically
My pc doesn?t turn off only the miner crashes
You could wrap it in a loop in the batch file. e.g. @echo off :start <<Start miner herre>> goto start This other command has the same function too right? :loop hsrminer_neoscrypt -o stratum+tcp://pool.unimining.net:4234 -u wallet -p c=DSR,stats goto loop AND how to setup a failover? To conect to other pool if the main is down. Tried with ccminer too without sucess, really wanted to configure a failsafe pool Yes exactly. That is the same thing. I don't think that you have any functionality like that in ccminer or hsrminer. It may be incorporated in one of the multi-algo wrappers like Nemo miner or Sniffdog but not sure. It's not overly complicated to write something basic that would take care of this but it requires some scripting skills. I have a TPLink HS110 that I monitor every minute with a script. If the current power is below the expected power for more than a minute I restart the entire rig which takes care of a number of problems (freeze, network problems, etc.) not the nicest of solutions but it gets the work done. |
|
|
|
Anyone got any idea how to restart my miner
I mean after the miner crashed how to restart it automatically
My pc doesn?t turn off only the miner crashes
You could wrap it in a loop in the batch file. e.g. @echo off :start <<Start miner herre>> goto start |
|
|
|
Hi everyone,
Been using Nemos miner for a while now and I think it's great, currently I'm using Zpool and would like to try ahashpool but I'm getting connection errors? I'm using the latest 2.3c build....and I'm not sure what's the issue.
Do I have to makes changes to the ahashpool ps1 file to get this to connect?
Everytime i start the ahashpool.bat file on any algo i get similar errors to this:
NVAPI GPU monitoring enabled.
1 miner thread started, using 'x17' algorithm.
...retry after 30 seconds
API bind to port 4068 failed - using port 4069
...retry after 30 seconds
...retry after 30 seconds
...retry after 30 seconds
...retry after 30 seconds
...retry after 30 seconds
this happens continuously and I've never been able to connect.
Can anyone shed any light on this?
Thanks!
Could be a firewall problem. Make sure that you can connect outwards on that port (4068 and 4069 it seems). |
|
|
|
Ah I see,
But good information anyway. I am thinking of extending my rig and it's difficult to find hash rates for x17 on the different cards (might have missed a calculator somewhere). Not sure if I should go for 1060s, 1070s or 1080Ti
So it's fair to say that a 1060 3GB does ~6.8MH/s I reckon?
If it helps for x17 my 1070 TI's right now are doing 13.7 MH/s per card and the 1070's are doing 10.7 MH/s. Cheers! Excellent! thanks. With my 1080Ti I am currently at around 19Mh/s so it seems as if the $/hash is more or less constant (only considering the price of the card) |
|
|
|
Thanks. Went from 35 to 40 MH on X17 with 1060 3GB. I hope it keeps behaving nicely How many 1060 is that? I hope it's not one or I will seriously have to reconfigure my rig Sorry, whole rig. Also, I made mistake by forgetting that that one particular rig has 6 1060s, and not five like the rest of them, so no noticable improvement over the old drivers. At least the gpus are not Melt(ing)down anymore Ah I see, But good information anyway. I am thinking of extending my rig and it's difficult to find hash rates for x17 on the different cards (might have missed a calculator somewhere). Not sure if I should go for 1060s, 1070s or 1080Ti So it's fair to say that a 1060 3GB does ~6.8MH/s I reckon? |
|
|
|
Thanks. Went from 35 to 40 MH on X17 with 1060 3GB. I hope it keeps behaving nicely How many 1060 is that? I hope it's not one or I will seriously have to reconfigure my rig |
|
|
|
|
