 Show Posts
|
|
Pages: [1] 2 »
|
how to use plots with 2 hdds???
gui only shows 1 hdd
i can link them and use them but still shows 1 hdd on dashbord
Currently you will need to use 2 miners... just start them on different ports |
|
|
|
My BMS dashboard shows a negative number for the address on my plot. Is that normal? Edit: I guess it's not normal since it got me banned on http://burst-pool.cryptoport.io/ which worked just fine for me with the v2 miner. Interesting... could you PM me a screen shot of the BMS dashboard an possible a screen shot of a directory listing with the plot... I am wondering if there is something wrong with the way I am loading the address from the filename as an unsigned long. Or you can add and issue to the GitHub page with screenshots etc. Also what OS are you using? |
|
|
|
what arguments do i use to start this up?
Take a look at the readme on github, https://github.com/mrpsion/burst-mining-system. but basically its just java -jar mining-system-1.20.jar --pool.url=http://{pool.hostname}:{pool.port} --plot.generation.threads=2 or something similar |
|
|
|
Is there a way to set something on the remote miners running this to report back to the master miner that oversees them all?
Finding exactly what IP each one actually finds to can be troublesome, but I'm being picky/lazy.
I could, and I was thinking about something like this, but I too was lazy when trying to roll out the miner  . The question I have for the group is what style of auto discovery would we want? i.e. do most people run their miners on networks that have multicast enabled across all the switches and hubs etc? or would we just want to instead of listing all the nodes on the masters start-up command, just list the master node on every other nodes start-up command? |
|
|
|
BTW how is the uray deadline limiting handled cause from my brief look over at the github it looks like you cant submit things that are lower than your lowest deadline submitted, which while fair from a pool manager perspective the vast majority of other miners are submitting lots of low deadlines that aren't necessarily all lower than their current lowest but regardless of this it positively affects their score. Point being that you should either just slowly scale the threshold or simply use the algo provided by the site to calculate if the share should be uploaded deadline value from miner is converted into share value using this equation
share = 1000 / ( NetDiff * Deadline + 1 ) 0.75
where NetDiff (network difficulty) is calculated by Block0-BaseTarget / Block#N-BaseTarget
note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round. IE if your value isn't greater than 0.001 it definetly shouldnt be uploaded but something more reasonable would be to simply assume the -0.001 is in effect and not allow shares that would be worth less than 0.01 safely preventing scores from being lowered and slowly increasing the necessary deadline as needed  on urays pool according to Uray, who i pm'd on something similar, only your best share is actually used. the penalty is to stop people trying exactly what you suggest, just to try and preserve system resources on the pool. So if you first submit a deadline of 1000000, that's what you will get credit for initially, however if you then submit 10000 you will instead get credit for that one and so on... its not cumulative. If then after the 10000 you submitted 10001 you would get a penalty for this. So if you have multiple miners you will get some penalties as the miners don't know about the other shares the other miners have submitted, but it would be minimal, and you would just get credit for the best share submitted across all of your miners that use the same address. |
|
|
|
i`ll love to have this working for solo mining
Ill work on this tomorrow... well today... its past midnight. |
|
|
|
Also for some reason my larger plot (which is about 3 times larger) produces 1/2 the shares of the smaller plot which makes no sense at least conventionally
Is this a bug or can you explain this?
Which pool? For Urays pool, the number of shares submitted for a plot is irrelevant. It progressively scans for better shares across all the plots only submitting one if it finds one better than the previous one. Ideally the miner would only submit one share for the entire miner per block, but as a new block could be detected before we have finished scanning all the plots we want to submit the best shares as we find them so we get credit. For the official pool, yes you would expect to find more shares for a large plot than a small one, but a large plot has more of a chance to get interrupted than a small one, especially if the large plot is towards the end of the list of scanned plots. For instance on one of my miners 1 have 11 90gb plots... The last 2 plots get interrupted all the time, which means they are not completely scanned all the time, and so would produce less shares than the ones that are always scanned. I don think there is a bug here, but I'll keep an eye out on my miners and see if I see any pattern. Do you have a screen shot of the "system" view showing the plots and stats? I would be interested to see it. You could pm the image if you don't want to have it out in public. What does the plot getting "interrupted" mean? and how would one prevent it? A plot is interrupted if a new block is announced on the network before the plot has finished being scanned. There is no point in continuing as any shares we would have created from then on would have been for an old block and so would be invalid. Some times you can't prevent it... For instance when a block is found 10 seconds after the last one.... You are pretty much certain to get interrupted... But you can minimize your chances mainly through drive speed. |
|
|
|
If you try to view the logs in the web gui it then causes some kind of error and stops mining for a bit in the command line and the gui
It then restarts and the number of shares and times mined resets...
I know there is an exception throw when you navigate away from the log, which doesn't harm anything as far as I can see, but I need to handle the websocket session termination better. I haven't seen any errors when actually viewing the log.. Or any disruption in stats, but I'll play around and see if I can replicate. Could you provide the error message and stack trace that you are seeing. |
|
|
|
Also for some reason my larger plot (which is about 3 times larger) produces 1/2 the shares of the smaller plot which makes no sense at least conventionally
Is this a bug or can you explain this?
Which pool? For Urays pool, the number of shares submitted for a plot is irrelevant. It progressively scans for better shares across all the plots only submitting one if it finds one better than the previous one. Ideally the miner would only submit one share for the entire miner per block, but as a new block could be detected before we have finished scanning all the plots we want to submit the best shares as we find them so we get credit. For the official pool, yes you would expect to find more shares for a large plot than a small one, but a large plot has more of a chance to get interrupted than a small one, especially if the large plot is towards the end of the list of scanned plots. For instance on one of my miners 1 have 11 90gb plots... The last 2 plots get interrupted all the time, which means they are not completely scanned all the time, and so would produce less shares than the ones that are always scanned. I don think there is a bug here, but I'll keep an eye out on my miners and see if I see any pattern. Do you have a screen shot of the "system" view showing the plots and stats? I would be interested to see it. You could pm the image if you don't want to have it out in public. |
|
|
|
note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round. ^from http://burst-pool.cryptoport.io/howitwork.htmlUm just to let you know when using http://burst-pool.cryptoport.io/ you will be penalized for using this client as it spams lots of high deadline submits which I have noticed from looking at my score decrease on the site pretty quickly Miner looks great and stats and feedback is really cool but this needs to be fixed, also if you could make a window in the gui that contains the logs that runs through the command line that would be stellar Also if you put a donation address in your sig and make mentioned fixes and changes I am sure plenty of happy miners would be willing to contribute Release 1.20 has log tailing built in now. You can tail the logs for any of the miners from the master node, and each miner can tail its own. |
|
|
|
I don't know what is wrong or where. I had it left mining this morning and 4-5 hpurs later checked the pool. There were no shares submitted. The miner said it submitted shares, But I had nothing. Lost 3-4k coins with this already
Which pool are you using uray/official? and which release of the miner? I have only really tested on Urays pool. And versions prior to 1.11 would probably have had this issue. I was using 1.11 on official v2 pool What was your startup command? FYI: I have just pointed all my plots at the official pool with my client, so as I can see what's up. I just had my first share submitted. And it showed up in the shares list on the pool. I am guessing you have registered your account and it appears in the allowed users list? Try with the latest release, I'll also be adding a new release tonight with some other enhancements, which will be the same code I just validated here. So you could wait for that if you want. I have just put up release 1.20 on github https://github.com/mrpsion/burst-mining-system/releases This is the code base I used to test, and validate that shares (well 1 share so far) were accepted on the official v2 pool. |
|
|
|
I don't know what is wrong or where. I had it left mining this morning and 4-5 hpurs later checked the pool. There were no shares submitted. The miner said it submitted shares, But I had nothing. Lost 3-4k coins with this already
Which pool are you using uray/official? and which release of the miner? I have only really tested on Urays pool. And versions prior to 1.11 would probably have had this issue. I was using 1.11 on official v2 pool What was your startup command? FYI: I have just pointed all my plots at the official pool with my client, so as I can see what's up. I just had my first share submitted. And it showed up in the shares list on the pool. I am guessing you have registered your account and it appears in the allowed users list? Try with the latest release, I'll also be adding a new release tonight with some other enhancements, which will be the same code I just validated here. So you could wait for that if you want. |
|
|
|
I don't know what is wrong or where. I had it left mining this morning and 4-5 hpurs later checked the pool. There were no shares submitted. The miner said it submitted shares, But I had nothing. Lost 3-4k coins with this already
Which pool are you using uray/official? and which release of the miner? I have only really tested on Urays pool. And versions prior to 1.11 would probably have had this issue. I was using 1.11 on official v2 pool What was your startup command? FYI: I have just pointed all my plots at the official pool with my client, so as I can see what's up. |
|
|
|
I don't know what is wrong or where. I had it left mining this morning and 4-5 hpurs later checked the pool. There were no shares submitted. The miner said it submitted shares, But I had nothing. Lost 3-4k coins with this already
Which pool are you using uray/official? and which release of the miner? I have only really tested on Urays pool. And versions prior to 1.11 would probably have had this issue. |
|
|
|
can use this ?
--plot.folder=D:\plots --plot.folder=E:\plots
No not yet. I am thinking about how to do multiple folders. Its a little more complicated in this miner, as I have to deal with the generation UI, and diskspace tracking... Currently if you have multiple folders you will need multiple miners. For each miner on a single host, make sure you give each miner a unique port using the argument --server.port=someport |
|
|
|
Ok. I recompiled with the revised version and now it works. The compiled version you pointed to does not want to work.
Did you try with the 1.11 release jar. It should be the same code as the master branch now. Let me know if you see any issues with the official pool, I haven't had much time to test with that one yet. Was the first thing to do but it does not work. I put the flag for the official pool but it was asking for mining info using the URL structure from Urays pool. Then I compiled from master, and it works without problems. Was the first jar you linked to 1.1 or 1.11? I think it was 1.1 i first linked to. My release management wasn't very good at the beginning.. sorry Make sure you are at least using 1.12 now to make sure you get the credit for your shares, and minimize the penalties. |
|
|
|
Sorry everyone... new release to use if you want a working System Dashboard. In my rush to get the shares fix out, I forgot about some in-progress code that broke the System Dashboard. 1.12 will still mine just fine, but you probably wont have a working system dashboard. Release 1.13 fixes this https://github.com/mrpsion/burst-mining-system/releases/tag/1.13 |
|
|
|
note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round. ^from http://burst-pool.cryptoport.io/howitwork.htmlUm just to let you know when using http://burst-pool.cryptoport.io/ you will be penalized for using this client as it spams lots of high deadline submits which I have noticed from looking at my score decrease on the site pretty quickly Miner looks great and stats and feedback is really cool but this needs to be fixed, also if you could make a window in the gui that contains the logs that runs through the command line that would be stellar Also if you put a donation address in your sig and make mentioned fixes and changes I am sure plenty of happy miners would be willing to contribute Okay all fixed. I added a new release 1.12 that fixes this issue. Everyone should use this version. |
|
|
|
note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round. ^from http://burst-pool.cryptoport.io/howitwork.htmlUm just to let you know when using http://burst-pool.cryptoport.io/ you will be penalized for using this client as it spams lots of high deadline submits which I have noticed from looking at my score decrease on the site pretty quickly Miner looks great and stats and feedback is really cool but this needs to be fixed, also if you could make a window in the gui that contains the logs that runs through the command line that would be stellar Also if you put a donation address in your sig and make mentioned fixes and changes I am sure plenty of happy miners would be willing to contribute I just PM'd Uray about this, as I think his client will do this as well, unless i am reading it all wrong. Ill put some time into this tonight, but I am thinking that I should just submit 1 share per miner per block to minimize the penalty. The donation addresses are at the bottom of the web UI and the readme i think... i didn't want to make it too obvious |
|
|
|
|
