Pool Management of 1.5.0 is a no-go as far as I can tell. Goes to black then resumes work.
Yes, known bug. It's there, it's just invisible 
Wait till 1.5.1 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 822. (Read 5806004 times)
July 27, 2011, 05:55:14 AM
Wait till 1.5.1 July 27, 2011, 05:54:44 AM
July 27, 2011, 04:01:27 AM
Pool Management of 1.5.0 is a no-go as far as I can tell. Goes to black then resumes work.
July 27, 2011, 03:26:01 AM
1.5.0 works well. I see you're using an approach similar to what I had suggested for the CPUminer. The numbers are looking far more stable now and it's completing the work far more efficiently as predicted. Kudos on getting the darn thing working.
Hehe, if you are talking about the split nonces, that was me who suggested it.Similarly, since this is now CGminer, you can extend the ability to do this to the graphics core as well so as to give the CPU smaller work loads that it can handle effectively based upon its performance and then give the rest to the GPU to finish off. This does, however, assume that the GPU is capable of handling the loads at a faster rate than the CPU which isn't always the case for older GPUs of the NVidia variety.
July 27, 2011, 03:20:53 AM
That part is an error secondary to the first one which is the sockopt function. What does that part of ./configure show for you?
Quote
checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.15.5
checking for libcurl >= version 7.10.1... yes
checking whether libcurl is usable... yes
checking for curl_free... yes
checking for gawk... (cached) gawk
checking for curl-config... (cached) /usr/bin/curl-config
checking for the version of libcurl... (cached) 7.15.5
checking for libcurl >= version 7.15.6... (cached) yes
checking whether libcurl is usable... (cached) yes
checking for curl_free... (cached) yes
checking for the version of libcurl... 7.15.5
checking for libcurl >= version 7.10.1... yes
checking whether libcurl is usable... yes
checking for curl_free... yes
checking for gawk... (cached) gawk
checking for curl-config... (cached) /usr/bin/curl-config
checking for the version of libcurl... (cached) 7.15.5
checking for libcurl >= version 7.15.6... (cached) yes
checking whether libcurl is usable... (cached) yes
checking for curl_free... (cached) yes
July 27, 2011, 03:00:28 AM
One thing that I've noticed though and I can't seem to fix effectively is that the SSE4.1 change appears to be nullified. While I was seeing higher numbers using non-temporal moves/copies from memory to cache, it appears to be the exact same as the sse2 code now.
I've tried disassembly and modification of the compiled C code for the sse4_64 , but yasm is being a little temperamental about the code that objconv puts together. At each movntd, it says that "error: instruction expected after label". I don't know why GCC didn't automatically use non-temporal moves with -msse4.1 specified in the CFLAGS, but I'm not much good beyond simply modifying asm source code to utilize cpu optimizations. Would you mind taking a look at it and figuring out why it's not allowing the optimizations to be used? However, don't revert back to the asm versions if you're not using them. The C-based ones are working with a higher degree of stability and slightly higher speed. But yes, I can't figure out how to enable the optimizations for GCC to use them.
Thanks!
PS: I've been playing around with the use of uint_fast32_t in the C code since the hashes can be different sizes. I'm not a C coder, but it's something to think about that might add up over time. The problem I've having with it is that I can't seem to find the right place to use it even though it does slightly increase code speed. In short, it's faster, but the results are useless/rejected due to how the data is handled. Not fun.
I've tried disassembly and modification of the compiled C code for the sse4_64 , but yasm is being a little temperamental about the code that objconv puts together. At each movntd, it says that "error: instruction expected after label". I don't know why GCC didn't automatically use non-temporal moves with -msse4.1 specified in the CFLAGS, but I'm not much good beyond simply modifying asm source code to utilize cpu optimizations. Would you mind taking a look at it and figuring out why it's not allowing the optimizations to be used? However, don't revert back to the asm versions if you're not using them. The C-based ones are working with a higher degree of stability and slightly higher speed. But yes, I can't figure out how to enable the optimizations for GCC to use them.
Thanks!
PS: I've been playing around with the use of uint_fast32_t in the C code since the hashes can be different sizes. I'm not a C coder, but it's something to think about that might add up over time. The problem I've having with it is that I can't seem to find the right place to use it even though it does slightly increase code speed. In short, it's faster, but the results are useless/rejected due to how the data is handled. Not fun.
July 27, 2011, 02:22:29 AM
1.5.0 works well. I see you're using an approach similar to what I had suggested for the CPUminer. The numbers are looking far more stable now and it's completing the work far more efficiently as predicted. Kudos on getting the darn thing working.
Hehe, if you are talking about the split nonces, that was me who suggested it. July 27, 2011, 02:22:04 AM
1.5.0 works well. I see you're using an approach similar to what I had suggested for the CPUminer. The numbers are looking far more stable now and it's completing the work far more efficiently as predicted. Kudos on getting the darn thing working.
Thanks. It's not entirely working as planned, but hopefully 1.5.1 will be working even better. July 27, 2011, 02:18:51 AM
1.5.0 works well. I see you're using an approach similar to what I had suggested for the CPUminer. The numbers are looking far more stable now and it's completing the work far more efficiently as predicted. Kudos on getting the darn thing working.
July 26, 2011, 08:11:42 PM
I'm aware of this, thanks. It was a half arsed attempt to fix the crash that old libcurls have when the display is refreshed twice in a row. I've pushed a change which should fix that just now.
Yup, that fixed it, thanks 
(I figured you probably knew about it, but it could have just as easily been local to me, too...)
July 26, 2011, 06:45:52 PM
Current git, I'm having issues with the curses display. Normal running is okay, but attempting to access any of the interactive options fails to have them drawn properly on the screen. It had worked with 1.4.1, but not in 1.5.0.
I can still press the appropriate key to access the appropriate function, but I never see the options. Example: I select [P]ool, the whole screen is redrawn, and the scroll portion goes blank. If I type "i" for info, it then prompts me what pool I want info for. However, then the screen redraws completely, and I'm given no info.
I'm aware of this, thanks. It was a half arsed attempt to fix the crash that old libcurls have when the display is refreshed twice in a row. I've pushed a change which should fix that just now. I can still press the appropriate key to access the appropriate function, but I never see the options. Example: I select [P]ool, the whole screen is redrawn, and the scroll portion goes blank. If I type "i" for info, it then prompts me what pool I want info for. However, then the screen redraws completely, and I'm given no info.
July 26, 2011, 06:10:38 PM
*cough* the deepbit thread is a better place to ask this. Anyway, you can and should set individual passwords for the workers and it's been like that for months.
July 26, 2011, 06:05:53 PM
Hi use this : http://deepbit.net:8332
Deepbit's help page clearly shows the c-name. Is this a bug in cg miner?
https://deepbit.net/help.php
I think you were missing the "http://" earlier, weren't you?
Sorry for the earlier confusion about the freaking workername layout, I stopped using deepbit as you have to use your login password for workers and there were no SSL/TLS in place, is it now?
July 26, 2011, 05:50:10 PM
Current git, I'm having issues with the curses display. Normal running is okay, but attempting to access any of the interactive options fails to have them drawn properly on the screen. It had worked with 1.4.1, but not in 1.5.0.
I can still press the appropriate key to access the appropriate function, but I never see the options. Example: I select [P]ool, the whole screen is redrawn, and the scroll portion goes blank. If I type "i" for info, it then prompts me what pool I want info for. However, then the screen redraws completely, and I'm given no info.
I can still press the appropriate key to access the appropriate function, but I never see the options. Example: I select [P]ool, the whole screen is redrawn, and the scroll portion goes blank. If I type "i" for info, it then prompts me what pool I want info for. However, then the screen redraws completely, and I'm given no info.
July 26, 2011, 05:05:41 PM
That part is an error secondary to the first one which is the sockopt function. What does that part of ./configure show for you?
This part:
checking for libcurl >= version 7.15.6... (cached) yes
This part:
checking for libcurl >= version 7.15.6... (cached) yes
July 26, 2011, 04:47:56 PM
July 26, 2011, 04:36:07 PM
July 26, 2011, 04:19:23 PM
Yes, let's see now...
You do realise that they're the same thing now, and deepbit.net will be pointed to somewhere else sometime in the future?
Code:
> dig {pit.,}deepbit.net
; <<>> DiG 9.7.3 <<>> pit.deepbit.net deepbit.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29083
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;pit.deepbit.net. IN A
;; ANSWER SECTION:
pit.deepbit.net. 120 IN A 46.4.121.119
pit.deepbit.net. 120 IN A 46.4.121.118
pit.deepbit.net. 120 IN A 46.4.121.120
pit.deepbit.net. 120 IN A 91.223.77.253
;; Query time: 45 msec
;; SERVER: 217.0.43.145#53(217.0.43.145)
;; WHEN: Tue Jul 26 23:16:08 2011
;; MSG SIZE rcvd: 97
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31529
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;deepbit.net. IN A
;; ANSWER SECTION:
deepbit.net. 120 IN A 46.4.121.119
deepbit.net. 120 IN A 91.223.77.253
deepbit.net. 120 IN A 46.4.121.118
deepbit.net. 120 IN A 46.4.121.120
;; Query time: 42 msec
;; SERVER: 217.0.43.145#53(217.0.43.145)
;; WHEN: Tue Jul 26 23:16:08 2011
;; MSG SIZE rcvd: 93You do realise that they're the same thing now, and deepbit.net will be pointed to somewhere else sometime in the future?
July 26, 2011, 03:45:04 PM
yeah.. with the failover / loadbalance you can run both.
July 26, 2011, 03:34:12 PM
both work.. i know this.
pit.deepbit.net [46.4.121.119]
deepbit.net [46.4.121.120]
Sure, but Tycho wants to completely phase out deepbit.net at some point in time, so you should use pit. pit.deepbit.net [46.4.121.119]
deepbit.net [46.4.121.120]
Jump to: