MarcusDe
Goldmin.es worked effortlessly with all other pools (in a joint effort) to make a pool possible.
He gave the community the first working test pool by his numerous attempts of coding the algo into the pool - Even ocminer himself was testing on his pool, and many others with stratum proxy. As far as I know, you come here and put him down, and you didn't even show up to help.
Goldmin.es is alright in my book, and he has been beyond helpful in his attempt, and we appreciate him here.
I am not a fan of negative influence, and I don't think you like negativity either. It is not necessary to conduct arguments unrelated to the Magi.
Take it in a private message or somewhere else. Not here.
I am with you, Goldmin.es sent me few messages about pool, he did a lot help on this coin, and even he is at 1st day of our launch making the pool to work. |
|
|
|
I think "block rewards" working very well, and no problem if 1-st phase will take more time than 1-2 month. Only 1 problem, privat gpu miner(Someone can make it) and this can help us... but if you think this option has any chance, with a closed source, no one will know coding gpu then, mining a period with major coins minted, then open source and PoS-II stage; it is sure then all miners have to trust the dev. + swap must be delay minimum until end of 1-st phase PoW stage. And sure we can postpone the swap till then (edit, we may option to ask opinions of prior holders for the fariness), but we will need community to donate us in order to perform project tasks. |
|
|
|
well someone has something working, the massive hash rate jumps can only be explained by 2 reasons. if its gpu what exactly will the dev do?
I am kinda thinking because of pool mining, some big miners jump in, though it would be costly to them, that can be possible; surprised this happens today, such a coincidence! If there are really gpu miners, my quick thinking: Keep the block reward low enough, no point for gpu miners stick to here, well all cpu miners have the same situation too Planing a new algo fork steps in at a future block, with a more "complicated" handling of functions etc; if gpu is on the current algo, same thing could happen too unless mining goes fast Or this may sound very weird, but if you think this option has any chance, with a closed source, no one will know coding gpu then, mining a period with major coins minted, then open source and PoS-II stage; it is sure then all miners have to trust the dev. Any suggestions? Another option, we can cut off rewards when network hash goes above 100MH; no one wants to mine without any rewards; only people in this coin will consistently mine and get paid. i'm sure this is not a good idea The prior proposed approaches are to discourage GPU miners, as we suspect they exist in the network (not 100% sure though). |
|
|
|
well someone has something working, the massive hash rate jumps can only be explained by 2 reasons. if its gpu what exactly will the dev do?
I am kinda thinking because of pool mining, some big miners jump in, though it would be costly to them, that can be possible; surprised this happens today, such a coincidence! If there are really gpu miners, my quick thinking: Keep the block reward low enough, no point for gpu miners stick to here, well all cpu miners have the same situation too Planing a new algo fork steps in at a future block, with a more "complicated" handling of functions etc; if gpu is on the current algo, same thing could happen too unless mining goes fast Or this may sound very weird, but if you think this option has any chance, with a closed source, no one will know coding gpu then, mining a period with major coins minted, then open source and PoS-II stage; it is sure then all miners have to trust the dev. Any suggestions? Another option, we can cut off rewards when network hash goes above 100MH; no one wants to mine without any rewards; only people in this coin will consistently mine and get paid. |
|
|
|
maybe it's not a good idea of changing the reward in production stage
Issue will be many coins to be mined in the future, which may be mostly mined by GPU by that time, unless GPU is proven to be impossible/inefficient. Another concern is the coin swap, although we can manage to carrier out coin swap much slower than mining. |
|
|
|
Is there going to be a hardfork to adjust block rewards?
No, not yet. What is wrong with block rewards? They seem to be working well so far. My initial thinking is that if we get enough people mining this coin, we should reward highest probable number of coins to miners, that is 500 XMG/block, as designed. So the question is, do we have enough people now? My guess, most likely yes, that's why we need to adjust the rewards. Well if you guys are comfortable with the current rewards per block, I have no objection.  |
|
|
|
Is there going to be a hardfork to adjust block rewards?
No, not yet. |
|
|
|
also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....
That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes. the amount that comes and goes jumps the hash rate from about 55,600Khs to 78,000khs, thats a massive jump.... so botnet or gpu miner is really the only option I'll need you all keep me posted your suspections in the next 1-2 days. i will when i get the chance to monitor it, down to 36,000khs now........ sudden drops then back to 49,000..... now at 57,000 again..... Which pool? Where you guys noticing this? getmininginfo, was "netmhashps" : 93.59520242 @ block 1037 well someone has something working, the massive hash rate jumps can only be explained by 2 reasons. if its gpu what exactly will the dev do? I am kinda thinking because of pool mining, some big miners jump in, though it would be costly to them, that can be possible; surprised this happens today, such a coincidence! If there are really gpu miners, my quick thinking: Keep the block reward low enough, no point for gpu miners stick to here, well all cpu miners have the same situation too Planing a new algo fork steps in at a future block, with a more "complicated" handling of functions etc; if gpu is on the current algo, same thing could happen too unless mining goes fast Or this may sound very weird, but if you think this option has any chance, with a closed source, no one will know coding gpu then, mining a period with major coins minted, then open source and PoS-II stage; it is sure then all miners have to trust the dev. Any suggestions? |
|
|
|
also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....
That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes. the amount that comes and goes jumps the hash rate from about 55,600Khs to 78,000khs, thats a massive jump.... so botnet or gpu miner is really the only option I'll need you all keep me posted your suspections in the next 1-2 days. i will when i get the chance to monitor it, down to 36,000khs now........ sudden drops then back to 49,000..... now at 57,000 again..... Which pool? Where you guys noticing this? getmininginfo, was "netmhashps" : 93.59520242 @ block 1037 |
|
|
|
also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....
That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes. the amount that comes and goes jumps the hash rate from about 55,600Khs to 78,000khs, thats a massive jump.... so botnet or gpu miner is really the only option I'll need you all keep me posted your suspections in the next 1-2 days. i will when i get the chance to monitor it, down to 36,000khs now........ sudden drops then back to 49,000..... Say 0.05 Mhps per cpu, 100Mhs/0.05 = 2,000 cpu might be realistic. The two pools we have account for 45 Mhps seems matching. Considering 78Mhps, there might be a miner with 30M hps doing sole mining, but as we know sole mining is unprofitable. When did the Mhps miners show up in xmg.suprnova.cc? We may record the highest network hash rate; if it goes too high, then we have to worry about GPU. We are still in the low block-reward zone though, still safe to us. |
|
|
|
also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....
That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes. the amount that comes and goes jumps the hash rate from about 55,600Khs to 78,000khs, thats a massive jump.... so botnet or gpu miner is really the only option I'll need you all keep me posted your suspections in the next 1-2 days. |
|
|
|
also noticed that it seems to come in at full power then dissapear for a few min allowing the difficulty to drop. could be a gpu miner in the testing stages....
That's within diff/hash fluctuations, as we've seen before. Let's attention how the network hash rate changes. |
|
|
|
from where comes 100MH/s!
I can see suprnova pool has many MHps miners, any sign of GPU miners? Edit, I have around 100 khps, 10MHps means about 100 cpus; that's still possible for one owns a cpu farm. That's a concern of pool mining, though everyone gets a share, pool mining just encourage big miners. |
|
|
|
|
@Spexx, thanks for the info that is very useful to other people. I donated 20 XMG to 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX, that's all I have; will send more once I can. I totally solo mined 80 XMG so far, with 60 XMG already donated somewhere to support XMG.
|
|
|
|
This is very interesting. I noted similar results when I was testing using a central wallet server like a solo pool. It turned out that this was because each thread was starved of getwork data due to network latency. Whilst you are not experiencing that, your test proves that there is something wrong with the algo that works out your hash rate because when my CPU was < 100% it was resulting in a HIGHER hashrate, which simply wasn't true. Conclusion: don't believe the hashrate results unless you are running at 100%.
I'll see if I can look into why the hashrate reports incorrectly and also why multiple threads are not being handled correctly (which again might be a red herring due to the hashrate not reporting the true value)
Paul, the hash rate reported here by Spexx is the hps (not network hash rate) in a run, that is calculated in a loop by counting hashes within a time. I would say that's basically correct. Understand that Joe - when I was testing using a remote VPS connecting to my local wallet at home, each thread was running at much higher hashrate than it should have been but the CPU was low - remember we had that conversation on IRC and said it was weird? It turned out that each thread was starved of getwork due to latency. Once I changed minerd to use a scantime of 3-5s the hashrate went back down to normal and CPU usage up to 100%. So something isn't right with the per-thread hashrate calculation Paul can you possibly confirm that again using the new nonce-pool's minerd: https://github.com/noncepool/m7m-cpuminer? With two minerds giving the same thing, this issue will be affirmed, and something we should look into. |
|
|
|
Guys....apologies for the question but I have not been able to keep up with this thread the past few days and am low on time.
Is the mining software available now to allow pool mining? If so, is it easy to setup and can you share the link to the software?
Thanks!
We have the pool mining now; many posts just coming up today, will summarize and include details into the OP. |
|
|
|
Tip of the dayObservations using Windows 7 64 bit, AMD 3100 quad-core processor as a testing rig. magi.conf addnode=66.55.90.58 addnode=107.107.52.31 addnode=162.243.219.192 daemon=1 server=1 rpcport=8232 rpcallowip=127.0.0.1 rpcuser=spexx rpcpassword=stratocaster Wallet mining solo with 4 threads generates approx 21 Kh/s or 5.25 Kh/s per thread. Using any one of the 32 bit minerd.exe compilations for Windows that are currently available. Solo mining using a batch file mineit.bat to start miner thus:- start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4 This configuration generates approx 22 Kh/s or 5.5 Kh/s per thread. Only 4.8 percent improvement on wallet mining. Now, using the 64 bit minerd.exe from https://drive.google.com/file/d/0B9cvOfoOekSdQktZN1I2SVhnNUk/edit?usp=sharing Using a batch file mineit.bat to start miner thus:- start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 4 This configuration generates approx 28 Kh/s or 7 Kh/s per thread. Not bad with a 33 percent improvement on wallet mining. OK so here is the clever bitUsing either the wallet mining or the 32 bit minerd.exe ensured that CPU time used was 100% but the 64 bit minerd.exe only used 87 percent CPU time despite generating 33 percent more hashes. Funny that. The CPU also seemed to be spending a lot of time in Kernel mode. So after a lot of mucking about I found that starting minerd.exe with only 1 thread four times made a big difference. start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 This configuration generates approx 38 Kh/s or 9.25 Kh/s per thread. An impressive 81 percent improvement on wallet mining. CPU time now up to around 98 percent with very little time spent in Kernel mode. Result. How can we tweak the last 2 percent out now? OK so here is the second clever bitNow assign each minerd process to a fixed subset of three processors. On a four-core machine thus:- start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 This configuration generates approx 41 Kh/s or 10.25 Kh/s per thread. An impressive 95 percent improvement on wallet mining. CPU time now up to around 100 percent. There is something here in the way a single minerd process handles multiple threads using this M7M algo. Having multiple minerd processes running a single thread each uses processor time more efficiently. On a 8-core machine you would need this batch file:- start /min /low /affinity 0x7 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xb minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xd minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xe minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0x70 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xb0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xd0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 start /min /low /affinity 0xe0 minerd --url http://127.0.0.1:8232 --user spexx --pass stratocaster --threads 1 Hope this helps. Any kind donations for the tip here to XMG 9EQ342ssXSxmpDURs6XNxAajB14DQzJDNX please. This is very interesting. I noted similar results when I was testing using a central wallet server like a solo pool. It turned out that this was because each thread was starved of getwork data due to network latency. Whilst you are not experiencing that, your test proves that there is something wrong with the algo that works out your hash rate because when my CPU was < 100% it was resulting in a HIGHER hashrate, which simply wasn't true. Conclusion: don't believe the hashrate results unless you are running at 100%. I'll see if I can look into why the hashrate reports incorrectly and also why multiple threads are not being handled correctly (which again might be a red herring due to the hashrate not reporting the true value) Paul, the hash rate reported here by Spexx is the hps (not network hash rate) in a run, that is calculated in a loop by counting hashes within a time. I would say that's basically correct. |
|
|
|
AMD FX-8350 4.00GHz = 96kh/s (ubuntu 14) at 100% CPU usage which I'm not actually doing. I'm just doing 6 cores. I wouldn't want to kill my sexy processor.
Your one is nice. Same here: AMD FX-8350 Black Edition Vishera 8-Core 4.0GHz, but with 6 core, I only got 70kh/s, ~90kh/s 8 cores (Xubuntu). This cpu came with my AMD GPU rig, never used for mining. (I promise my AMD GPU is not mining XMG right now). |
|
|
|
Thanks to ex33s; guess not everyone has seen this dice game. |
|
|
|
Just started hashing. Using a i7 4770k and getting about 4.9 khash/s per core. So around 39 khash/s total. Does that sound right to you guys?
That is low. you should be getting double that. Any idea where I am doing something wrong? bat: minerd.exe -a m7mhash -o stratum+tcp://xmg.suprnova.cc:7127 -u worker -p password -t 8 Also, I dropped the thread down to 7 and got 39 khash/s with an average of 5.5 khash/s per core. Interesting... What if you set a lower number of cores, try to compare with -t 6, -t 4 I got an impression, AMD has a higher hash than intel? |
|
|
|
|
Show Posts
