A workid with what? With the block submit? There is an id sent, and it matches that which the request for a template went out with. Yes, it's always zero... is that the problem? The data is all completely reconstructed for a block submit so the actual id of where the template came from doesn't seem to be relevant to any other pool. Is this the issue for you? I'm just trying to understand...
Not the JSONRPC request id but the GBT "workid" value that is sent out with every template. The spec requires that you send it back to the pool with every block submit. Apparently Eligius and Eclipse MC don't use the workid so they don't care if it's missing. But my implementation is dependent on it as of now. I am thinking about having it search through the coinbase to figure out the workid if it is missing, though. Hmm under " Submitting shares" on https://en.bitcoin.it/wiki/Getblocktemplate#For_developers I see no mention of a workid value. What is this workid value? EDIT: We discussed this on IRC and came to a resolution. cgminer 2.9.4 should be good to go with GBT on bitminter. |
|
|
|
GBT (getblocktemplate) testing is up on port 9000.
Testing so far:
cgminer isn't sending a workid and so every proof-of-work is rejected with the message "unknown-work". Have to look into this.
Not much point testing cgminer (2.9.3) further before the workid issue is resolved. But please do test bfgminer and any GBT proxy you may have. Let me know how it runs.
A workid with what? With the block submit? There is an id sent, and it matches that which the request for a template went out with. Yes, it's always zero... is that the problem? The data is all completely reconstructed for a block submit so the actual id of where the template came from doesn't seem to be relevant to any other pool. Is this the issue for you? I'm just trying to understand... |
|
|
|
This version doesn't crash. At least not within two minutes after disconnect.
Thanks  |
|
|
|
Alrighty, I found some time to look at the code and think I've found something hopefully. I'll try to spin something up soon for you try.
Try one of these builds again: http://ck.kolivas.org/apps/cgminer/temp/Interestingly if this is the actual bug, it should be possible to hit it on linux as well, but it seems to be much harder to hit because linux can easily tell when the socket has dropped out. |
|
|
|
Here's something interesting! Using 2.9.3 with --verbose, it doesn't crash!!! I still observe the same oddity as in 2.8.7 where it says pool 0 is no responding, then it says it's alive again. Since the NIC isn't plugged in, it can't do anything, but it does not crash. When I plug the NIC back in, it successfully recovers.
Using -T doesn't change anything, it still crashes.
Hopefully this helps!!
--verbose works! I unplugged my wireless adapter, and it disconnected. Waited about 60 seconds, plugged it back in, and it reconnected. No crashes. At least we have a temporary fix! That is most interesting guys, and at least gives me a lead! I appreciate your testing and input. This is what free software and open development is about. It's a long shot but try the latest builds here (without verbose): http://ck.kolivas.org/apps/cgminer/temp/ |
|
|
|
Here's something interesting! Using 2.9.3 with --verbose, it doesn't crash!!! I still observe the same oddity as in 2.8.7 where it says pool 0 is no responding, then it says it's alive again. Since the NIC isn't plugged in, it can't do anything, but it does not crash. When I plug the NIC back in, it successfully recovers.
Using -T doesn't change anything, it still crashes.
Hopefully this helps!!
--verbose works! I unplugged my wireless adapter, and it disconnected. Waited about 60 seconds, plugged it back in, and it reconnected. No crashes. At least we have a temporary fix! That is most interesting guys, and at least gives me a lead! I appreciate your testing and input. This is what free software and open development is about. |
|
|
|
|
Well, anyone got any bright ideas about windows and stratum? Disabling threading didn't help, debug versions spit out no debug info, and it's not like I can just tell people to fuck windows off and start mining only on linux. Even after ASICs arrive, someone somewhere will still want to mine with windows.
Windows people, any ideas? Was there a version with stratum that was stable for you across multiple disconnections?
|
|
|
|
$ make
make all-recursive
make[1]: Entering directory `/home/User/cgminer'
Making all in lib
make[2]: Entering directory `/home/User/cgminer/lib'
GEN signal.h
GEN string.h
make all-recursive
make[3]: Entering directory `/home/User/cgminer/lib'
make[4]: Entering directory `/home/User/cgminer/lib'
CC memmem.o
CC sigaction.o
CC sigprocmask.o
AR libgnu.a
make[4]: Leaving directory `/home/User/cgminer/lib'
make[3]: Leaving directory `/home/User/cgminer/lib'
make[2]: Leaving directory `/home/User/cgminer/lib'
Making all in compat
make[2]: Entering directory `/home/User/cgminer/compat'
Making all in jansson
make[3]: Entering directory `/home/User/cgminer/compat/jansson'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/User/cgminer/compat/jansson'
make[3]: Entering directory `/home/User/cgminer/compat'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/User/cgminer/compat'
make[2]: Leaving directory `/home/User/cgminer/compat'
Making all in ccan
make[2]: Entering directory `/home/User/cgminer/ccan'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/User/cgminer/ccan'
make[2]: Entering directory `/home/User/cgminer'
CC cgminer-cgminer.o
gcc.exe: error: @CPPFLAG_CURL_STATICLIB@: No such file or directory
make[2]: *** [cgminer-cgminer.o] Error 1
make[2]: Leaving directory `/home/User/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/User/cgminer'
make: *** [all] Error 2
Got Yasm copied in and finally configure line didn't error. Windows build.txt is missing this step entirely. Did the Libcurl actually change between 2.7.5 and 2.9.3? I only ask because it looks the same as the older windows build instructions but it is erroring on a line with curl listed. I am more interested in how to fix it then why it happened though. Actually yasm is a red herring. It does nothing on windows builds since it is only for 64 bit linux cpu mining support. The libcurl requirement DID change at around 2.8, due to new requirements for stratum support, but they're not the problem you're running in to. The real issue is that support for compilation on *BSD was added recently to cgminer, and unfortunately that broke compilation directly on windows mingw32 compilation. I didn't notice because I now compile the mingw binary via a cross-compiler on linux. So it's not a problem at your end. When I can get back to code soon I will try and address this issue... but then there are other problems with cgminer on windows in 2.9.x, to which I do NOT have a good explanation for yet... God I hate windows. |
|
|
|
|
Your stratum and dynamic difficulty appear to be working very nicely. Well done. The nice thing about your vardiff is that once it has found the right difficulty it does not fluctuate. This is important with stratum because of the potential for lost work +/- rejects across difficulty changes, which I see alot of with EMC for example. You also seem to have made good inroads into the speed of block change detection closing the gap on slush markedly.
|
|
|
|
Creating a PID type controller for every fan/gpu combination out there with different heat generation qualities, different cooling capacities, different fan speed change effects, different fan speed acceleration capabilities, etc. etc. etc.... is basically impossible. What creating a different type of controller for every combination out there? I'm not even asking for that. When the temp is below temp-target, don't slam the clock up to max, raise it one step at a time instead, and don't drop the fan fast, lower it one step at a time. A couple if-statements, and that's it... why complicate it with pretending you'd have to make new algorithms for every card out there? I know you think I'm stupid, but I'm not THAT stupid. Believe it or not, this _is_ an issue that the auto-fan and auto-gpu aren't behaving as well as they should be, and all it is, is how fast it adjusts the fan and clock speed. There is NO reason why, just because the temp drops below temp-target minus hysteresis, that the clock speed has to be pushed back up to max, instead of being raised step by step the same as it does as if the temp is within the hysteresis. The clock raising to the max was put in there to workaround a problem with the driver where it drops to low power during any relatively idle period and even if you try to set it to high speed it ignores you, and the return values from the driver reporting back its current speed get stuck at low speed confusing the feedback mechanism. I'll think about a possible workaround, when time permits me to code once more. |
|
|
|
It's not a mistake. Previously cgminer did not check the backup pools were working. Now it does check them even if not mining on them.
I know that, but Mt. Red couldn't possibly be going down as often as cgminer is saying. Also, I'm pretty sure us1.ozco.in is currently running just fine. It is advantageous if a pool goes down for cgminer to not try to switch to another one that hasn't been working. 1 failed getwork is enough to do it. It's the same mechanism it uses on startup to see if a pool is alive. Overkill? Dunno, I wasn't expecting pools to fail sending getworks so often. What if cgminer just cued up the next pool in line, rather than all of them? Doesn't really cut if for spilling of work to all the backup pools and other failover strategies. If the shit going on at the moment ever calms down I'll look to just do it silently and not call the backup pools dead visibly. |
|
|
|
Yo guys... Just encountered this issue on 2.9.3 running on Ubuntu 12.04 x86_64:
[2012-11-15 21:09:43] List of devices:
[2012-11-15 21:09:43] 0 Cypress
[2012-11-15 21:09:43] Selected 0: Cypress
[2012-11-15 21:09:43] Error -6: Creating Command Queue. (clCreateCommandQueue) <--- is the debug shits (cgminer -D -T --verbose)
Worked fine until today. Now it refuses to start. Should i try to re-install FGLRX?
No idea why in your case, but that's what the error means. |
|
|
|
Thanks. That is quite different actually. I've uploaded another set of executables into that temporary directory which may get us even further. Can you try them please? There is no way on earth it will compile on VS.
This is more like what I was expecting. The debug version is much much larger than the production one. But the output looks about the same... cgminerdebug.exe caused an Access Violation at location 0040cb33 in module cgminerdebug.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=624836d0 ecx=74712e09 edx=07c51858 esi=00000000 edi=00770ea0
eip=0040cb33 esp=03fff3d0 ebp=00801480 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
0040CB33 cgminerdebug.exe:0040CB33
7713FAF6 ntdll.dll:7713FAF6 RtlAnsiCharToUnicodeChar
77140093 ntdll.dll:77140093 LdrGetDllHandleEx
7713FD2F ntdll.dll:7713FD2F LdrGetDllHandle
76641A35 KERNELBASE.dll:76641A35 GetModuleFileNameW
7666734E KERNELBASE.dll:7666734E IsNLSDefinedString
76641CFB KERNELBASE.dll:76641CFB GetModuleFileNameW
7666734E KERNELBASE.dll:7666734E IsNLSDefinedString
76641CFB KERNELBASE.dll:76641CFB GetModuleFileNameW
74AF3362 kernel32.dll:74AF3362 RegKrnInitialize
How about Watcom? I can dust it off and see if I can get it to run there. Whatever you can try or think of is most welcome. These latest builds totally disable creating threads for either getting or submitting work, serialising all work of that kind so the idea that it might be due to generating too many threads is basically not the issue here. RtlAnsiCharToUnicodeChar suggests perhaps it's some string function overflow, but that's not very definitive about which one or where... |
|
|
|
Ok, one of my cards has a fan on it that is dying, but it has given me a chance to observe a behavior in cgminer that, I believe, needs tweaking, when it comes to auto-fan and auto-gpu.
I notice repeatedly, that the temps of my card are fluctuating a lot, and this is why...
SNIP
Creating a PID type controller for every fan/gpu combination out there with different heat generation qualities, different cooling capacities, different fan speed change effects, different fan speed acceleration capabilities, etc. etc. etc.... is basically impossible. As per the the readme, the algorithm is an algorithm designed to work in most places well most of the time with most hardware, and will not get it right occasionally. Since GPUs mining are dead long term, I have zero interest in rewriting the algorithm or developing it further. It won't be long before GPU miners will be the poor relatives that give me nothing for further development when ASICs hit. Sad, since I really liked GPU mining, but that's the reality. Probably best to find some static fan speed workaround in your case. |
|
|
|
Cgminer 287 with two cards on my everyday PC. It mined 10001 of the 10000 requested, and it quits normally, but windows thinks it quit unexpectedly. Win pops up a dialog box asking if I want to quit cgminer. Of course I want to quit... because I have it on a loop.
I had it mine 10K shares and loop. Has looped a few times, and then this happens. Wish there was a way to tell windows "it's okay, let it quit/crash and don't worry about it" and my loop would restart it w/o babysitting it.
Probably because cgminer returns a "failure" type return code if the number of shares it mined isn't exact. |
|
|
|
2.9.3 works fine for me in Win7 but when I get into the settings area, there's a 2 second lag. Weird. Older versions did not have this weird lag.
Intentional due to other changes, it's clearing the screen and it doesn't update that frequently. |
|
|
|
Updated with support for fractional diffs and diffs just below 1. |
|
|
|
Not much different. Visual Studio gives me nothing to work with. Dr. MingW gives me this: cgminer.exe caused an Access Violation at location 0040cb33 in module cgminer.exe Reading from location 00000000.
Registers:
eax=00000000 ebx=624836d0 ecx=74712e09 edx=07dfa910 esi=00000000 edi=004b0e80
eip=0040cb33 esp=0408f3d0 ebp=00579198 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
Call stack:
0040CB33 cgminer.exe:0040CB33
7713FAF6 ntdll.dll:7713FAF6 RtlAnsiCharToUnicodeChar
77140093 ntdll.dll:77140093 LdrGetDllHandleEx
7713FD2F ntdll.dll:7713FD2F LdrGetDllHandle
76641A35 KERNELBASE.dll:76641A35 GetModuleFileNameW
7666734E KERNELBASE.dll:7666734E IsNLSDefinedString
76641CFB KERNELBASE.dll:76641CFB GetModuleFileNameW
7666734E KERNELBASE.dll:7666734E IsNLSDefinedString
76641CFB KERNELBASE.dll:76641CFB GetModuleFileNameW
74AF3362 kernel32.dll:74AF3362 RegKrnInitialize
Maybe if I can get it to compile in Visual Studio, I'll run in it dev and see what happens when I unplug the NIC. M Thanks. That is quite different actually. I've uploaded another set of executables into that temporary directory which may get us even further. Can you try them please? There is no way on earth it will compile on VS. |
|
|
|
|
Show Posts
