Topic: SRBMiner Cryptonight AMD GPU Miner V1.9.3 - native algo switching - page 159. (Read 237261 times)

If i put manually (--logfile log.txt) works, but if i let the star file creates it, it doesnt work.

This its my start.bat file

setx GPU_MAX_HEAP_SIZE 100
setx GPU_MAX_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_MAX_SINGLE_ALLOC_PERCENT 100
@echo off
cd %~dp0

cls
set LOGTIME=%date:~10,4%_%date:~4,2%_%date:~7,2%_%time:~0,2%_%time:~3,2%
set LOGTIME=%LOGTIME: =%
set LOGTIME=%LOGTIME:,=.%.txt

SRBMiner-CN.exe --config Config\config.txt --pools pools.txt --logfile %LOGTIME%

Then put how many/24 hours and then do your algo for devfee.
Will not be a problem if you mine at 2  times at  1 hour interval even if i set 2/day , the rest of the day will be uninterrupted.
Just to not have reboots on my rigs, then you will get a lot of devfee , but this is my work to do.

I won't make the user choose how often (4 , 6, 8, 12h), because .. you already know why ('the kill/start thing').
But i will think out something

I am glad you understand me.
For me 6-12 hours will be perfect, but i suggest to put some parameters , like 4 , 6, 8, 12 hours or 2,4,6,8 devfee mining times/24 hours. Of course, if my rig restarts , will be your bigger fee , but if not , I prefer you to devfee mine for 5 minutes 2 times a day then 1 minutes 10 times a day

About devfee mining, now I understand. I did not checked the percentile, as I consider this way of working more like a gentleman's agreement. I will never block your fee, as it permits you to keep working on improving. I thought you are hiding it for other reasons, now I get the idea why. I think you are right.

Cannot wait to have this time parameter feature.Even if you keep the time of mining hidden, basically will be 2-4 times every 24 hours, which looks great for me.

Now i understand, but devfee is never mined for minutes, max time per devfee is less than a minute.
But i like your idea so i will implement it, a simple parameter in the bat will do it.
How often would you like the devfee to be mined?



You can wireshark the connection, and see for yourself if you don't trust me when i say it's ~0.85%. There are a few combinations of devfee periods, randomly chosen on every miner start, but always ~0.85% / 24h . I had to go this route because of the guys who 'know that devfee is mined every 2 hours' so they simply kill/start the process.

Just because it's not shown WHEN EXACTLY is the devfee mined, it doesn't mean it is more than the advertised ~0.85%. That is why i mentioned the pool hashrate, as long as you have the hashrate you should have on the pool side (because this is only what matters on payout), you know the miner is not stealing anything.

"
Totally wrong. Devfee is always same algo as users, so HW doesn't need different settings (voltage etc). So it cant produce restarts."

It is happening at switch from devfee to normal , was looking into issue for many days on 1.6.5. Anyway, related to P3 overclocked too much, as I said. Enough that one is overclocked too much, the miner will close w/o reason at switch.Now at switch (with lower P3) the hashrate is only droping. If you have better idea about that stop w/o any logs or reason , let me know.


"I don't know what are score pools, and how am i 'ruining' your work.
Miner is not disconnecting from user pool when switching to devfee mining, there are 2 open connections then, after devfee mining is done, job is switched back to the already active user pool connection."
On score pools you get shares , but they are growing while you mine, if before reward you drop your mining, it was for nothing all the work (or better say will not worth much). It's sort of like prop, except instead of treating all shares equally, it gives more weight to later shares in the round (the drop-off is such that shares half an hour later are worth twice as much as shares half an hour before) The idea is to keep the miner as stable as possible, to get right reward. Switching for few minutes to another work will drop your shares.
The suggestion was to mine more minutes at bigger times, or maybe to give us this option. As i said , if I choose this, it is better for you, at every restart you will be mining more. If possible.

"I could set that your eyes see devfee mining of 5 seconds but in reality it mines for 30 minutes. So that is display only. You should look at the hashrate you get at your pool, it should be around "hashrate from miner - 2-3-4%" , or even more if you have compute errors."
And i could log your connection and see how much it stays connected to that pool , to not mention what you said to check my pool. The idea was to be open and fair, for this it was better 1.6.5. Don't get me wrong, but as long as I am fair and don't block your devfee, even there are dozens ways, you should be same.


[/quote]

Maybe there are no write permissions for the miner to work in its own folder?

It doesnt save the log file.... any ideas?

Put the parameter "reboot_script" : "scriptname.bat" in the config file, or just use the .bat i provided (reboot-windows.bat)
If you don't put the " it will complain

edit:


Totally wrong. Devfee is always same algo as users, so HW doesn't need different settings (voltage etc). So it cant produce restarts.
I don't know what are score pools, and how am i 'ruining' your work.
Miner is not disconnecting from user pool when switching to devfee mining, there are 2 open connections then, after devfee mining is done, job is switched back to the already active user pool connection.

I could set that your eyes see devfee mining of 5 seconds but in reality it mines for 30 minutes. So that is display only. You should look at the hashrate you get at your pool, it should be around "hashrate from miner - 2-3-4%" , or even more if you have compute errors.

Hello
Wanted to be sure:
"reboot_script" : "reboot-windows.bat" this is the correct syntax or "reboot_script" : reboot-windows.bat or something else (like path to file) ?
Btw , @JuanHungLo those restarts w/o reason happens on starting mining again after devfee mining and happens because of too much memory (P3) on one of the cards. Try to low a little - for me worked. For allowing access to devfee you could establish outbound rule, but if you ask me, you already know this
@doktor83 - could you try to mine more minutes , but at at least 4-6 hours , not 2 like now, some of us are on Score pools and you are ruining our work every 2 hours. Anyway you mine after few minutes from start, so would be the same for you.Also, not the best ideea to hide the devfee mining, was more fair to see it for how long by our eyes.

These are 2 separate things :

1. If miner can't contact srbminer.com for a long time (DFP online load: FAIL)
2. If miner can't mine devfee for a long time (devfee mining is on normal pools like nanopool, etc.)

So something is blocking different connection attempts there, not just srbminer.com but also various devfee pools.

Sorry I forgot to add... yes, I tested both versions at 55 and hash is roughly the same.

Nah im not sure its a "you" thing, i am trying to optimize for every card and sometimes an optim good for one card is not so good for another . Could you please test the same intensities as i wrote before?

I believe you are correct and it is a “me” problem and not a “you” problem... 😁
Auto intensity for 1.6.4 is 57 and 1.6.7 is 55, but a weird thing happened.  I was running .4 and immediately after quitting and starting .7, without a reboot, they have the almost the same hashrate.

Thanks for your support and work you do!

It may be that the auto setting in 1.6.7 gave a lower value for intensity as in 1.6.4. It would be really good if you could test both miners with same intensity, for example 55 (580 can handle higher intensity, but for this test 55 should be ok).
And if still 1.6.4 wins by 50hs/card then i must re-work stuff, but if hash is same in both versions, then i don't have to chase ghosts

Same card settings but not sure in miner as I’ve always used auto intensity 0 and never messed with worksize.

Did you use the same settings in 1.6.7 as in 1.6.4? Same intensity, worksize ?

I’m assuming it was bundled kernel because on first run, all miner said was loading kernel... didn’t get a compiling kernel message.  SRB 1.6.7 was installed in a completely separate folder than 1.6.4.

Neither on 1.6.6. This was just yesterday.

version 1.6.6

https://s15.postimg.cc/5z6pefkjv/err.jpg

on version 1.6.5 there are no problems