Topic: CGWatcher 1.4.0, a GUI/monitor for CGMiner & BFGMiner to help minimize downtime - page 27. (Read 402304 times)

I first checked the code to make sure there was not a bug causing CGWatcher to affect the gpu-memclock setting, so we can rule that out.

Next, I tested this by trying different values and stopping/starting the miner about 20 times (I have two 7950s). The --auto-gpu option does not need to be enabled for cgminer to change clock speeds, so you're ok there. What values have you tried changing the memclock to?

Here is what I noticed with the tests I've just ran:

I believe the default memory clock on my cards is 1250. If I set --gpu-memclock to 1000 or below, nothing would happen... my memory clocks would stay at 1250. This also included if I tried changing the memory clock while cgminer was running using CGWatcher. If I set --gpu-memclock to above 1000 (well I tested in 50 increments so 1050 and up), cgminer correctly set the memory clock.

I'm not sure what clock speeds you were attempting to set it to, and I'm not sure why I'm unable to go under 1000 when I know others go well under that when SHA256 mining (although I can't say for certain they use cgminer to do it). But my suggestion would be to try different numbers and see what happens. If you're using CGWatcher, you can usually tell in the first ~10 seconds what it sets the memory clock to... so if it doesn't work just stop the miner, change the setting, and try again.

If this doesn't work for you I can try helping again in the morning... but this is not a CGWatcher issue so I can't guarantee it is something I can fix.

so an example - sapphire 7950 (reference):

auto-gpu is off
gpu-engine: 1100
gpu-memclock: 650  < OR > gpu-memdiff: -450 (i've tried both)
gpu-powertune: 10

but device monitor reports core clock 1100mhz, memory clock 1250mhz. Doesn't matter what values I put in the config, memory clock never seems to change. On my 7870s (tahiti LE), the memory clock defaults to 1500. Really need it lower...

If I use afterburner, I can manually set both clocks - but I've found some conflicts when both afterburner and cgminer are trying to modify clock.

Can you provide more info? What does your config file and/or arguments say? What kind of card is it? CGWatcher isn't actually changing the clock speeds, it just helps you configure the miner, and the miner is what changes the clock speeds.

I've tried setting the memclock manually (either with positive or negative integers) on the past four release versions, including this latest 1.1.5.1c, and when inspecting the devices, they never respect my memclock settings. Am I missing something? Would really like to underclock my memory for bitcoin, but it never works...

Looks great, going to give it a shot right now

1.1.5.1 is now available. Hopefully it will fix the GPU mapping issue for multiple OpenCL platforms. Here is the changelog, not including some minor fixes and things I forgot to write down in the changelog as I was working on them:

• Fixed issue with GPU mapping when more than one OpenCL platform exists and GPUs are not on platform (index) 0.
• Added support for FPGA and ASIC devices, but not currently displayed because I am hoping to get more device test results. If you use these devices, please run the test on the FPGA or ASIC tab and email me the results. You can check if these devices are detected correctly by clicking the 'Show FPGA' or 'Show ASIC' buttons on the Tests tab.
• Fixed open miner path directory in Profile Manager
• Cancel button will give option of canceling wait for miner start (at bottom next to status). However if the process does start successfully and CGWatcher can communicate with the miner, it will still start monitoring. This was added more for the scenario of not having a pool set in a config file or arguments which causes the miner to prompt you for this info, meaning CGWatcher just keeps waiting for the miner to start and initialize its API.
• Arguments will now take priority over config file (if same option is specified in both.) Pools set in arguments will be appended to pools set in a config file.
• Fixed .cmd/.bat files causing miner to be killed on restart. Instead a quit is performed if full API access, or kill if not. This ensures any other commands in the .bat/.cmd file are reloaded during restart.
• Added check processes for cgminer-nogpu.exe.
• If miner disables GPU for exceeding temp-cutoff, cgwatcher will restart it once it returns below temp-target because the miner is usually unable to re-enable it successfully.
• Profiles without a pool specified can not be saved. At least one pool must be specified in a config file or arguments. Otherwise this would cause the miner to prompt for this info on each restart.
• Fixed bug with saving arguments to bat/cmd file that may have removed other lines in certain conditions.
• Miner processes that are detected but fail to communicate with CGWatcher are now saved so it doesn't keep trying to communicate with them (if it has not found a process to monitor.) Hopefully this will not cause issues with detection, but miners started from within CGWatcher should not be affected.
• Hardware information will refresh at same interval as monitor (instead of 5 seconds as in 1.1.5.0), but will continue to refresh even if miner is not running (when possible).

As usual, if I've introduced any new problems please let me know and I will try to get them fixed quickly before there are too many downloads.


Sweetrevenge: You can use any pool with CGWatcher.

+1 I'll check out cgwatcher, personally I prefer guiminer since its easy and you can mine with any pool.

Ok, the INI explains it. Although I couldn't find any reason it would have written that to the INI file incorrectly, I added some additional handling of unexpected values in the INI file.

The update will be available shortly. I have some FPGA/ASIC code I need to finish up. I don't think these devices will be displayed in this update as I'd like to get some more device test results if I can... but CGWatcher should know they're there now and have info for them, including adding their hashrates to the current total hashrate. (The average total hashrate should already be based on all devices.) I'm more concerned about getting the update out to fix the GPU mapping issues and a few other small fixes. I'll post again when it's ready.

looking forward to giving this a try...nice work.

It seems there was EnsureAPI=Tru in the .ini, corrected it, hmh. o_O The .conf files were okay.

With this same version at least, keeping cgwatcher open, starting the miner, stopping it, starting it again doesn't fix the mapping.

Current contents of my .ini:

[CGWatcher]
UseBackupHardwareMode=False
CurrentProfile=1
[Settings]
MaxAvailableLogEntries=100
Autorun=False
Autolaunch=False
MinimizeToTray=False
StartMinimized=False
NoPromptOnExit=False
PosScreen=0
PosX=13
PosY=435
[Miner]
ProcessStartCushionSeconds=15
ProcessID=0
ProfileID=1
MyProcessID=0
WindowMode=0
Address=127.0.0.1
OverrideAPIPort=False
Port=4028
GPUCount=3
[Monitor]
MonitorOn=True
Interval=5
EnableOverheatProtection=True
NotRespondingRestartChecks=3
AllowDisableWERUI=True
ForceCloseProgramsOnRestart=False
HashRateType=1
HashRateCounter=3
RestartGracePeriod=180
HoursRestartValue=24
CheckShareCountMinutes=10
HashRateRestart=False
HashRateCutoff=800
CheckShareCount=False
AutoRestart=False
SickDeadGPURestartType=0
PrivilegeLoss=False
EnsureStaysRunning=False
[System]
GPUCount=2
CPUCount=1
[Config]
EnsureAPI=True
[GPU-Map]
0=1
1=2

Dunno how that Tru value got there, I don't edit the .ini file directly, nor have ever I typed a True or False value manually in any field, as far as I can recall at least. But it's fixed for now and will not where to look if it happens again.

So, go ahead and update the file, and I'll see how the mapping goes.

Looks great, I'll try it...
Cheers

It looks like I won't have the update ready until tomorrow. I think I have the issues resolved but I am too tired to think clearly enough to thoroughly test it, so I'll wait until the morning/afternoon to make sure I got it all.

Testing it right now for the first time.I usually get errors every 10-12h while running cgminer,hopefully this will help.
Big thanks OP.

Thanks for the quick reply, unfortunately I can only check things tomorrow afternoon (3AM now here) as the system became unreachable about half an hour after I posted, and I couldn't call the person housing it that late to give it a hard reboot. So, feel free to proceed with the update of course... and I'll keep you posted with how it goes.

sydameton: Thanks for the detailed information. As you may have noticed, I have no problem with leaving long replies so when reporting a problem, the more information the better as far as I'm concerned.

I believe I have found the first issue and corrected it, but I want to do a little more testing before I say for certain. It looks to be another unforeseen result of having multiple OpenCL platforms. It was something I should have expected now that I see it, but I obviously missed it. It will correct the issue of your GPUs being incorrectly numbered 1 and 2 instead of 0 and 1, which is causing the mapping problems.

As to the second issue, before I spend too much time banging my head against the wall... can you verify that the config file you were attempting to open in the Config File Editor did not have a typo where it said Tru instead of True? And then try opening it again. I checked to see if I had a typo somewhere that would cause the Config File Editor to write Tru instead of True when saving a config file, but could not find Tru anywhere in the code. I'm a little confused as to why the exception was not caught by error-handling code, as I could not find anywhere in the Config File Editor code that would allow this. I use a library for reading and writing Json (the format the config file uses) so it is difficult to tell where exactly the issue would occur, and maybe that is why the exception went unhandled. I ultimately plan on writing my own code to read and write the config file Json... but have other things of higher priority right now.

I think the issues with GPU mapping not working/saving correctly will be related to the first issue that I believe is now corrected. A temporary workaround may be to open CGWatcher and start the miner, then stop the miner and start it again (all while CGWatcher remains open). If you could try that and report what happens with GPU mapping, I'd appreciate it. I'll be updating the download files tonight, hopefully after I can resolve the second issue with the Config File Editor and fix the bug that Pointeh reported related to multiple instances. Thanks for the help and patience as I work these things out.

Also, when reporting GPU Map problems, if you can also include the contents of the INI file... or at least the [GPU Map] section of the INI file, that will be helpful since that is where the mappings are saved. But again, in your issue I think the problem has been resolved and I will be updating the files as soon as I hear back from you regarding the second issue and finish up the multiple instances handling. If you cannot get back to me tonight I'll just update the files and just let me know when you get a chance to update and test it again.


Pointeh: I believe using the miner without specifying pool info in a config file or arguments will be handled in the next update, but I have some additional work to do to handle .bat or .cmd files because they may have arguments. With how finicky hardware can be, I believe you that GUIMiner may help your GPU get started (stranger things have happened)... but I'm not sure how this relates to CGWatcher and how you set the pool info for cgminer. Maybe I am not understanding correctly what you mean.



Also, I haven't started on the new project I will be spending the next 6-8 weeks on, so I have some time to iron out these issues. While I may be starting it in the next few days when the agreement is finalized, I am hoping that along with fixing any reported bugs that I can add basic FPGA and ASIC support. I've only gotten a few of the FPGA device test results sent to me and I would like to have some ASIC test results as well, so if anyone uses these devices for mining, I'd really appreciate it if you could run the test on the FPGA or ASIC tab (depending on which devices you use) and email me the results. The test itself should only take 10 seconds or so, and I added a link at the end that should open your default email client and fill in all of the information (email, subject, and message) to make it as easy as possible to submit... but please make sure the message part includes all of the test results because one of the results I got was cut short and I'm not sure if that was the way it fills in the email message or if the user accidentally cut it off.

Looks interesting, might have to check it out

And having problems again.

So,

Been getting this in my logs today, repeatedly: [6/9/2013 11:11:48 PM]   [d] Miner reported GPU0 that did not have corresponding OpenCL GPU! Adding to OpenCL.GPUs.

This is what cgwatcher detects after a reboot I did just in case, with no mining session started yet, as per your instructions for Tests tab: http://pastebin.com/cw6hQZrL and GPU Map screenshot https://imageshack.us/photo/my-images/24/screenshotbcj.png/?sa=0 On the screenshot, I just rolled that option down, didn't change anything. GPU1 is correct but there is no GPU2 in the system and GPU0 is missing from the map (which would be the other device that appears in the dropdown list, unassigned).

I thought of re-enabling --gpu-platform to see if it helps detection. Clicking config editor yields, for the first time, this exception repeatedly but works if `Continue`: http://pastebin.com/zcHt3mZX screenshot: https://imageshack.us/photo/my-images/14/unhandledexception.jpg/?sa=0 Didn't help, disabled it again. Manually adding the GPU at this point can not be done as GPU0 is not in the list (and as I'd find out moments later, manual mapping doesn't save anyway).

So I enabled my OC and started the miner to see if things change: On the Devices tab, device "-" (which is "0" I recon), reads inactive. GPU Map added GPU0, reports hash rate, but does not allocate a device to it. Also names GPU2 as Tahiti while GPU0 not. While it reports hash rate on the GPU Map and it doesn't on the Devices' (therefore on the Status either), I can't use 'restart miner if hash rate falls under x'. Manually mapping a device at this point doesn't work -- saves okay, but reopening the GPU Map shows the same thing, while the Device tab still reads inactive for -/0. Screenshot: https://imageshack.us/photo/my-images/24/wtfscreenshot.jpg/?sa=0

Otherwise mining's working fine for BTC at least, scrypt is causing me a f**kton of issues lately out of the blue but that's not cgwatcher-related. My scientific guess would be that my GPUs are cursed, even if they worked perfectly with the same coin-specific settings for months, BTC and LTC alike.

To say I'm confused is an understatement. Thoughts?

Sorry for the long and frequent posts.

I know its a little weird but (sometimes) have to I use GUIMiner to start mining as i find it more stable. Though I really cant explain why,  guiminer will get my pitcairn hashing even if i was to the the exact same launch parameters in a .bat file.
Being able to monitor or change settings on the fly is really handy.

Thanks for the reply.

Edit I also just launch cgminer with the right -o and -O settings, -I 16,19 and such

very cool! ty!

Pointeh: I just got home and it's late here so I won't get to this until tomorrow, but I did find the problem: I didn't expect anyone would be running cgminer without a config file or arguments to set their pool url/username/password/etc. This delay from when the miner process starts to when actual mining starting is the issue. This will take a little more work than I am prepared to do tonight, so until tomorrow you can try using a config file or arguments to set this information and see if it works better for you. But I did find and fix a couple other small issues as well so I'll recommend waiting for tomorrow.

I'll post tomorrow when it is fixed... I just wanted to let you know I'm aware of (and have found) the problem.


Edit: Although I will make sure this works even if you don't use a config file or arguments... that is essentially defeating the purpose of CGWatcher because whenever it detects a problem with the miner and restarts it, it will be stuck at the pool/username/password prompt until you enter these manually. I strongly recommend using a config file or arguments to configure the miner.

That said, there will still be an update tomorrow with the bug fixes I mentioned, some related to multiple instances and some that may occur regardless of number of instances.