I'm loving the new difficulty stats. It's cool getting to see what each share is.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 472. (Read 5805546 times)
October 12, 2012, 11:07:36 PM
Dynamic intensity is still messed up in 2.8.3. Now it's going up to 15.
I'm loving the new difficulty stats. It's cool getting to see what each share is.
I'm loving the new difficulty stats. It's cool getting to see what each share is.
October 12, 2012, 09:42:58 PM
I played a little around an found out, that the nonce does'nt have to change the endian on arm.
Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
Code:
static void set_work_target(struct work *work, int diff)
{
unsigned char rtarget[36], target[36];
[2012-10-13 01:39:50] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
But still the same problem that i get rejected on stratum
[2012-10-13 01:40:01] RECVD: {"error": [-2, "lowdifficulty", null], "id": 68, "result": false}
[2012-10-13 01:40:01] PROOF OF WORK RESULT: false (booooo)
[2012-10-13 01:40:01] Rejected 4e8ec61a Diff 3/1 MM 6 pool 0 (lowdifficulty)
October 12, 2012, 07:44:34 PM
I played a little around an found out, that the nonce does'nt have to change the endian on arm.
Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
Code:
static void set_work_target(struct work *work, int diff)
{
unsigned char rtarget[36], target[36];
[2012-10-13 01:39:50] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
But still the same problem that i get rejected on stratum
[2012-10-13 01:40:01] RECVD: {"error": [-2, "lowdifficulty", null], "id": 68, "result": false}
[2012-10-13 01:40:01] PROOF OF WORK RESULT: false (booooo)
[2012-10-13 01:40:01] Rejected 4e8ec61a Diff 3/1 MM 6 pool 0 (lowdifficulty)
October 12, 2012, 07:19:17 PM
I played a little around an found out, that the nonce does'nt have to change the endian on arm.
Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
October 12, 2012, 07:09:01 PM
I played a little around an found out, that the nonce does'nt have to change the endian on arm.
Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
October 12, 2012, 06:51:04 PM
Like a charm - 2BTC sent!
Thanks! Much appreciated 
October 12, 2012, 06:50:06 PM
I played a little around an found out, that the nonce does'nt have to change the endian on arm.
Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like. Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
October 12, 2012, 06:35:42 PM
I played a little around an found out, that the nonce does'nt have to change the endian on arm.
Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
Is it normal that a Generated target looks like this:
Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d
on a working stratum machine, it look like this:
[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
October 12, 2012, 06:27:21 PM
I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....
Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
It looks like you didn't have curses-development files installed when building cgminer on that rig.Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
That would be a quick fix - Will rebuild this evening - Thanks!
(Great piece of code BTW - expect a donation)
Like a charm - 2BTC sent!
October 12, 2012, 06:13:38 PM
@ckolivas: Will cgminer support BFL ASICs? Are you already working on this?
It will, along with ASICs from other manufacturers. I am not directly working on the driver for it yet because they have not released any specifications yet.On the other hand, there have been numerous changes made to cgminer in preparation for those ASICs. This is precisely why cgminer now supports the stratum protocol, has massive rolltime support and can display devices up to exahash speed.
October 12, 2012, 04:43:57 PM
@ckolivas: Will cgminer support BFL ASICs? Are you already working on this?
October 12, 2012, 02:47:37 PM
New version: 2.8.3, 12th October 2012
Fixed a critical windows bug and added some goodies. Hopefully this version brings us close to making a stratum capable release the current stable version.
...
Fixed a critical windows bug and added some goodies. Hopefully this version brings us close to making a stratum capable release the current stable version.
...
Thanx for the fast updates.
I replaced libpdcurses.dll that AVG virus warns about to other that AVG likes, and cgminer is still running fine =)
http://www.youtube.com/watch?v=BNsrK6P9QvI&noredirect=1
Or you could have just read the README which shows you that it is a false positive and setup AVG to ignore it. Or you could have read this forum thread and also come to the same conclusion.
I have read the README and the forums... just that now I don't get that false positive at all =)
October 12, 2012, 12:20:45 PM
New version: 2.8.3, 12th October 2012
Fixed a critical windows bug and added some goodies. Hopefully this version brings us close to making a stratum capable release the current stable version.
...
Fixed a critical windows bug and added some goodies. Hopefully this version brings us close to making a stratum capable release the current stable version.
...
Thanx for the fast updates.
I replaced libpdcurses.dll that AVG virus warns about to other that AVG likes, and cgminer is still running fine =)
http://www.youtube.com/watch?v=BNsrK6P9QvI&noredirect=1
Or you could have just read the README which shows you that it is a false positive and setup AVG to ignore it. Or you could have read this forum thread and also come to the same conclusion.
October 12, 2012, 11:55:10 AM
im running this while not gaming "cgminer -o us2.eclipsemc.com:8337 -u xxxxxx -p xxxxx --shaders 1792 --intensity 12 --worksize 256 -v 1"
but how can i cut out gpu 0 when running bf3?
but how can i cut out gpu 0 when running bf3?
An alternate method that Kano didn't suggest is in the command line, use --device 1[,2,3,4,n] to turn "OFF" device 0, which is GPU 0. If you are using batch files to start cgminer, use two files, one for gaming with "--device 1" and one for when not gaming.
October 12, 2012, 09:40:09 AM
I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....
Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
It looks like you didn't have curses-development files installed when building cgminer on that rig.Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
That would be a quick fix - Will rebuild this evening - Thanks!
(Great piece of code BTW - expect a donation)
October 12, 2012, 09:36:13 AM
I have 2 rigs with 2 gpus each (2 5830 and one with a 5830 and a 5850).
ONe has debian and the other ubuntu... both 32bits
is there any place to get precompiled binaries ? i compiled up to 2.3.something, and stoped
It was ... complicated xD
Might as well format the hell out of them and install ubuntu 12.04 x64, but that would take some time (and me getting to my parents home).
Yes ... reinstall to x64 ONe has debian and the other ubuntu... both 32bits
is there any place to get precompiled binaries ? i compiled up to 2.3.something, and stoped
It was ... complicated xD
Might as well format the hell out of them and install ubuntu 12.04 x64, but that would take some time
(and me getting to my parents home). October 12, 2012, 09:27:12 AM
I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....
Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
It looks like you didn't have curses-development files installed when building cgminer on that rig. Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
October 12, 2012, 09:11:31 AM
I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....
Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
October 12, 2012, 08:46:10 AM
I have 2 rigs with 2 gpus each (2 5830 and one with a 5830 and a 5850).
ONe has debian and the other ubuntu... both 32bits
is there any place to get precompiled binaries ? i compiled up to 2.3.something, and stoped
It was ... complicated xD
Might as well format the hell out of them and install ubuntu 12.04 x64, but that would take some time (and me getting to my parents home).
ONe has debian and the other ubuntu... both 32bits
is there any place to get precompiled binaries ? i compiled up to 2.3.something, and stoped
It was ... complicated xD
Might as well format the hell out of them and install ubuntu 12.04 x64, but that would take some time
(and me getting to my parents home). 
October 12, 2012, 08:07:58 AM
Trying to compile on windows, it not see OpenCL...
Drivers installed, SDK etc installed, files copied...
Any ideas?
CFLAGS="-O2 -msse2" ./configure --enable-scrypt --enable-cpumining
Drivers installed, SDK etc installed, files copied...
Any ideas?
CFLAGS="-O2 -msse2" ./configure --enable-scrypt --enable-cpumining
Code:
------------------------------------------------------------------------
cgminer 2.8.3
------------------------------------------------------------------------
Configuration Options Summary:
curses.TUI...........: FOUND: pdcurses
OpenCL...............: NOT FOUND. GPU mining support DISABLED
scrypt...............: Disabled (needs OpenCL)
ADL..................: SDK NOT found, GPU monitoring support DISABLED
BitForce.FPGAs.......: Disabled
Icarus.FPGAs.........: Disabled
ModMiner.FPGAs.......: Disabled
Ztex.FPGAs...........: Disabled
CPU Mining...........: Enabled
ASM.(for CPU mining).: false
Compilation............: make (or gmake)
CPPFLAGS.............:
CFLAGS...............: -O2 -msse2
LDFLAGS..............:
LDADD................: -LC:/MinGW/lib -lcurl -lcurldll compat/jansson/libja
nsson.a -lpthread -lws2_32 -lm
Installation...........: make install (as root if needed, with 'su' or 'sudo')
prefix...............: /usr/local
Jump to: