Do we already have any confirmation on what the PoM reward will be?
Not yet amigo. Hope to inform you soon about that! I'm sure MAGI team will ensure fair prize to the participants of PoM Well, I'll move on to greener pastures until that time then. |
|
|
|
|
Do we already have any confirmation on what the PoM reward will be?
|
|
|
|
Ah good man, how much you sitting on? if you don't mind me asking  I don't mind you asking  Change of perspective, what would be in your opinion a good amount to sit on? (The bigger the better is not a valid answer) 10.000? 100.000? I'd not mind to be on the 10.000 level, alas I'm actually 10 times less. PS: I was taking a look at the PoM pool, I guess someone still have problems with the 250 kH/s thing... Edited the name cause I don't like witch-hunts  Yes, that was me  But as stated already, that is fluctuation. Look at the left column with the number of submitted shares. I barely submitted more shares than the no.2 in the list and he is rated at 210 Khash. |
|
|
|
That does look strange, though large variation of hash over time is a fact. @all others, trying to look into average hash; if you got the average over 250 kh/s, you will be warned. Please observe your hash and pull down little bit to make sure it stays in a safe level. I haven't touched my rigs for days and just keep them running. On average I should have 230 but you will see it drop to 150 on the pool sometimes too so you just cought my rigs on a lucky streak |
|
|
|
I don't think so, it's known that pool doesn't show exact hashrate as your miner - pool can show +/- 30 kh/s
If you don't want to go above 250 on pool, just stay lower than 220 on your miners
I have seen my hashrate go as high as 300 and as low as 150 without touching my rig, so +/- 30 is a bit conservative I think. Yes, i saw you pass the limit sometimes, lol. I think it happen when our workers have high difficultly, sometimes it hashrate raise alot  Yes, a higher diff will definitely make the hashrate fluctuate more. But sometimes your rig can be just lucky to find a lot of shares. Since the pool is set up mainly for the POM, I think it's a good idea to increase the period of time over which the average is measured to even out the results some more. |
|
|
|
I don't think so, it's known that pool doesn't show exact hashrate as your miner - pool can show +/- 30 kh/s
If you don't want to go above 250 on pool, just stay lower than 220 on your miners
I have seen my hashrate go as high as 300 and as low as 150 without touching my rig, so +/- 30 is a bit conservative I think. |
|
|
|
Yes it does  |
|
|
|
You too? Even with the very latest version? I have a headache. I expect it did not produce figures.txt. It's weird. It ought to work. The cut-down version of the same code will work on the collected data and give you the result. https://www.dropbox.com/s/4w5rsyosk5kx66f/benchmark-redo.exe but only for the standard benchmark results - not the multiplex. That executable in the link only unpacks 1 file to my drive, which is benchmark-redo.bat which does not work by itself. What other files should I put in the directory? |
|
|
|
So where are your results then? I have tried every version so far but no luck  It looks as if the CPU doesn't even kick into turbo mode.  |
|
|
|
I could knock-up a noddy program for Windows to simply flag up when XMG block rewards are below a certain threshold (and/or equal to and above a certain threshold) and execute a command line (or a batch file or whatever) under either circumstance. I would only have to cut and paste from what I already have and alter a couple of lines to make that happen. Not rocket science. Perhaps if you wait for my next software release and pick through the batch code (which is fully documented inline so you can see how it works) you may be able to produce something for yourself. You will get a dilemma at the point where the block value data is unavailable (for whatever reason e.g. the data server goes down) and you have to decide what to do about that. I am not getting into the issue of "profitability" as a deciding factor - I cannot calculate that.
I would have guessed that it would not be too difficult to run a batch file or command line when block rewards are below a certain level. The biggest chalange will be to kill the process of the alternate miner when XMG rises above a pre-set block award I would guess. Do you have any ideas about that? |
|
|
|
I really like the sweetspot tool but I was wondering if NeedIfFindIt (or Spexx or someone else) can add a feature to start mining a different coin than XMG when rewards are too low. Now the miner slows down to 10% but I don't want my CPU to go idle, I would rather have it do some different work on another coin. Anyone feel like adding this feature? Hmm don't know what to say about this. Ask our teammembers in the Magi thread to build things for other coins. Best thing to say that i'am proud of the Magi community and our teammembers. Its great to see that their work is also appreciated by other coins! Hope they pay the rewards in XMG! They don't really have to build stuff for other coins but just include the option of running a command line string to start another miner when XMG profitability is too low to mine XMG. (and of course stop it when the XMG miner will be started again). My CPU is running 24/7 anyway and I don't want any time to be wasted on idle time. |
|
|
|
I really like the sweetspot tool but I was wondering if NeedIfFindIt (or Spexx or someone else) can add a feature to start mining a different coin than XMG when rewards are too low. Now the miner slows down to 10% but I don't want my CPU to go idle, I would rather have it do some different work on another coin. Anyone feel like adding this feature? |
|
|
|
Really a shame this thread has died. At some point this started to become one of the better trolling threads to read for my daily laughs |
|
|
|
Read about the c option, but dont know how to use it. I am using ccminer.
It's easy, just set 'c=GEO' as your password, that's all. If you are already using your password to set other variables then just add ',c=GEO' to the end of your already set password. Remember, no spaces. |
|
|
|
do you guys suggest a longer time between switched? right now, i understand it's now switching a bit too often.
Optimal would be if the time to switch would be dynamic and calculated based on the difference in profitability. So if you are mining X11 and X13 is more profitable by 2% then there is no need to switch fast. If X13 would become more profitable by 100% then it makes sense to switch quickly to X13. |
|
|
|
I would like to know when finally will function normally switch between algorithms according to prescribed miner complexity in the "pass". Just at the moment of every 2 minutes miner switches to a different algorithm., And idle time of switching from 3 to 15 seconds. Waiting for an answer.
Algo switching works fine as far as I can see on my rigs. |
|
|
|
....point couple of zeus thunder for 24 hours and see what will happen.
Can your Zeus Thunder do X11? If not, I can tell you now what will happen No I can't know. Because I'm not master please explain to me. Possible fast speed? Actually that remark was toward trinitywealth since he wants to use his Zeus Thunder for this X11 coin. But now the coin dev is asking me the difference between X11 and scrypt? WTF !?! |
|
|
|
....point couple of zeus thunder for 24 hours and see what will happen.
Can your Zeus Thunder do X11? If not, I can tell you now what will happen |
|
|
|
|
I also switched to this pool now TMB is stopping.
First impressions are good, let's see how this works out over the next days.
Any chance of implementing a multi-multi-port like TMB had? So the pool doesn't only switch between the best coin on one algo but also closes ports to switch algo on sgminer5 if a coin on another algo becomes more profitable?
|
|
|
|
Does the latest sgminer have the "leaked" Wolf0 kernels for x11 and x13? I had been away for awhile and it seems things have gone down hill in a hurry around here. If not, someone want to be a champ and provide link?
I am getting about 2.0 Mh/s on x13 with 270x (14.7 rc3 I believe).
138 kh/s on Neo.
They seem ok?
I see the nicehash Dev branch has badmans74 x kernels, which I am getting x13 2.0
As far as I know the only kernels that leaked were X11 and X15, with X15 not being really much faster. Nicehash can't put the X11 in their branch because it was only a .bin that leaked, not the .CL files. Here's the post https://bitcointalk.org/index.php?topic=854257.msg9717735#msg9717735 |
|
|
|
|
Show Posts
