OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 411.

loshia

legendary

Activity: 1610

Merit: 1000

Quote from: kano on February 02, 2013, 09:55:35 AM

I'll be getting an rpi B 512 next week - so I'll also be paying more attention to RAM usage.
But as I mentioned somewhere else?, cgminer (without GBT) doesn't use much RAM anyway.

2hrs:
15911 root 20 0 1282m 4228 2648 S 0.0 0.0 0:04.91 cgminer-2104n

FYI this version still has the unfreed work issue, but is only 1xBFL at ~860MH/s

... I think back when Xiangfu was running more than 40 Icarus on his OpenWRT router early last year ...

Kano,

You can trust me on that with 2.10.4 before latest commit it was eating 45M of ram for 2-3 days maks:)

I know what i am talking about..
From the other hand:
top

%VSZ
1519 1513 root S 64436 104% 20% /usr/bin/cgminer -o mint.bitminter.co

root@cgminer:~# free
total used free shared buffers
Mem: 61752 29652 32100 0 3652
-/+ buffers: 26000 35752
Swap: 0 0 0

cgminer VSZ stays untouched for 5 hours or so and free looks exelent

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

I'll be getting an rpi B 512 next week - so I'll also be paying more attention to RAM usage.
But as I mentioned somewhere else?, cgminer (without GBT) doesn't use much RAM anyway.

2hrs:
15911 root 20 0 1282m 4228 2648 S 0.0 0.0 0:04.91 cgminer-2104n

FYI this version still has the unfreed work issue, but is only 1xBFL at ~860MH/s

... I think back when Xiangfu was running more than 40 Icarus on his OpenWRT router early last year ...

loshia

legendary

Activity: 1610

Merit: 1000

Kano,
Thank for your input.
I am not using GBT only stratum. The part of the problem may be related to latest kon git fix related to submitting stratum work. I am running latest git with fix and looks good for last 5 hours or so. I can be sure if that was major leak eating openwrt RAM after a day or two

Best

PS:if you can take a look at pool_active it will be great. I looked at it but there are some labels (jumps), and i do not know jsoon methods - which of them return pointer (no need to be freed) and which one of them return copies (like strdup). I suspect that in that function can be a memleak also but i am not sure Sad

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

I have a memory.h overlay that I run on cgminer sometimes (that I wrote myself)
Although it uses 30x the RAM, it also includes an API call to list ALL calls to allocate RAM by filename/line of the code that allocated it, and stats about number allocated, free and number unfreed, amount allocated and freed etc etc (as well as various other very useful memory corruption tests)
I compile that in, once in a blue moon, to see if anything is allocating RAM and not freeing unnecessarily.
The output looks like this:

Code:

...
 cgminer.c:6403 a=1 f=0 d=1 ta=176 tf=0 td=176 ra=12288 rf=0 rd=12288
 cgminer.c:6405 a=21 f=0 d=21 ta=215 tf=0 td=215 ra=258048 rf=0 rd=258048
 cgminer.c:6457 a=1 f=1 d=0 ta=17 tf=17 td=0 ra=12288 rf=12288 rd=0
 cgminer.c:6475 a=1 f=1 d=0 ta=104 tf=104 td=0 ra=12288 rf=12288 rd=0
 cgminer.c:6480 a=2 f=0 d=2 ta=576 tf=0 td=576 ra=24576 rf=0 rd=24576
 miner.h:552 a=3 f=0 d=3 ta=96 tf=0 td=96 ra=36864 rf=0 rd=36864
 miner.h:553 a=3 f=2 d=1 ta=41 tf=34 td=7 ra=36864 rf=24576 rd=12288
 cgminer.c:1209 a=1 f=1 d=0 ta=20 tf=20 td=0 ra=12288 rf=12288 rd=0
 jansson/memory.c:0 a=99985 f=99656 d=329 ta=4264600 tf=4252207 td=12393 ra=1228644352 rf=1224601600 rd=4042752
 cgminer.c:1147 a=1027 f=1027 d=0 ta=13611 tf=13611 td=0 ra=12619776 rf=12619776 rd=0
 cgminer.c:416 a=12 f=0 d=12 ta=11904 tf=0 td=11904 ra=147456 rf=0 rd=147456
 cgminer.c:420 a=12 f=11 d=1 ta=720 tf=616 td=104 ra=147456 rf=135168 rd=12288
 util.c:896 a=13 f=0 d=13 ta=66 tf=0 td=66 ra=159744 rf=0 rd=159744
 util.c:897 a=13 f=0 d=13 ta=173 tf=0 td=173 ra=159744 rf=0 rd=159744
 util.c:583 a=47555 f=47548 d=7 ta=1864988 tf=1864784 td=204 ra=584355840 rf=584269824 rd=86016
 driver-icarus.c:573 a=2 f=0 d=2 ta=2304 tf=0 td=2304 ra=24576 rf=0 rd=24576
 driver-icarus.c:575 a=2 f=0 d=2 ta=26 tf=0 td=26 ra=24576 rf=0 rd=24576
 cgminer.c:6363 a=3 f=0 d=3 ta=192 tf=0 td=192 ra=36864 rf=0 rd=36864
 cgminer.c:6366 a=2 f=0 d=2 ta=576 tf=0 td=576 ra=24576 rf=0 rd=24576
 cgminer.c:6368 a=7 f=6 d=1 ta=280 tf=216 td=64 ra=86016 rf=73728 rd=12288
 driver-icarus.c:579 a=2 f=1 d=1 ta=40 tf=16 td=24 ra=24576 rf=12288 rd=12288
 driver-icarus.c:588 a=2 f=0 d=2 ta=1680 tf=0 td=1680 ra=24576 rf=0 rd=24576
 usbutils.c:535 a=1 f=0 d=1 ta=280 tf=0 td=280 ra=12288 rf=0 rd=12288
 usbutils.c:1108 a=2 f=0 d=2 ta=96 tf=0 td=96 ra=24576 rf=0 rd=24576
 driver-bitforce.c:173 a=1 f=0 d=1 ta=1152 tf=0 td=1152 ra=12288 rf=0 rd=12288
 usbutils.c:890 a=2 f=0 d=2 ta=144 tf=0 td=144 ra=24576 rf=0 rd=24576
 usbutils.c:893 a=2 f=0 d=2 ta=36 tf=0 td=36 ra=24576 rf=0 rd=24576
 usbutils.c:1021 a=2 f=0 d=2 ta=35 tf=0 td=35 ra=24576 rf=0 rd=24576
 usbutils.c:1028 a=2 f=0 d=2 ta=29 tf=0 td=29 ra=24576 rf=0 rd=24576
 usbutils.c:1035 a=2 f=0 d=2 ta=35 tf=0 td=35 ra=24576 rf=0 rd=24576
 usbutils.c:1267 a=5 f=4 d=1 ta=360 tf=240 td=120 ra=61440 rf=49152 rd=12288
 usbutils.c:1270 a=5 f=0 d=5 ta=70000 tf=0 td=70000 ra=122880 rf=0 rd=122880
 driver-bitforce.c:249 a=1 f=0 d=1 ta=28 tf=0 td=28 ra=12288 rf=0 rd=12288
...

Anyway, the point being, yep I do keep an eye on that every so often (or when someone suspects such a problem exists) and have found a couple in the past.

Edit: yes 'r' stands for real amount of ram (as opposed to 't' the requested amount) and yes the massive amount of RAM usage in jansson is almost entirely GBT

loshia

legendary

Activity: 1610

Merit: 1000

Quote from: -ck on February 02, 2013, 06:44:10 AM

Yes the pool data is never relinquished to prevent a dereference from occurring if you delete a pool from the list and then a random share or work item tries to refer back to it after the fact. If you're not deleting the pool, the data needs to stay there till shutdown anyway, and no effort is made to clean it up just for the sake of it on exit. It is not a lot of ram and there's no point trying to chase it all down by keeping track of every single work item and share out there to see when none of them are referencing that data any more. It shouldn't actually increase in memory usage.

I know:)
I was wondering if pool_active is causing any additional leak. That is why I posted all the output

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Yes the pool data is never relinquished to prevent a dereference from occurring if you delete a pool from the list and then a random share or work item tries to refer back to it after the fact. If you're not deleting the pool, the data needs to stay there till shutdown anyway, and no effort is made to clean it up just for the sake of it on exit. It is not a lot of ram and there's no point trying to chase it all down by keeping track of every single work item and share out there to see when none of them are referencing that data any more. It shouldn't actually increase in memory usage.

loshia

legendary

Activity: 1610

Merit: 1000

Kon,

I saw your memleak commit an i am testing it already.
However i am not sure though, there might be some other memleaks when calling pool_active which is happening quite often. I am attaching valgrind output just in case

The other stuff seemed not to be freed on cgminer exit which is not an issue:) Or i think so..
10X

==8359== HEAP SUMMARY:
==8359== in use at exit: 908,508 bytes in 4,143 blocks
==8359== total heap usage: 31,624 allocs, 27,481 frees, 41,232,886 bytes allocated
==8359==
==8359== 10 bytes in 2 blocks are definitely lost in loss record 24 of 212
==8359== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x5C83D71: strdup (strdup.c:43)
==8359== by 0x41F7F0: extract_sockaddr (util.c:871)
==8359== by 0x404DB3: detect_stratum (cgminer.c:558)
==8359== by 0x404EA0: set_url (cgminer.c:582)
==8359== by 0x433E98: parse_one (parse.c:110)
==8359== by 0x4336B9: opt_parse (opt.c:213)
==8359== by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 32 bytes in 1 blocks are definitely lost in loss record 73 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x403F4A: string_elist_add (miner.h:528)
==8359== by 0x404C7F: add_serial (cgminer.c:507)
==8359== by 0x433E98: parse_one (parse.c:110)
==8359== by 0x4336B9: opt_parse (opt.c:213)
==8359== by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 35 bytes in 2 blocks are definitely lost in loss record 75 of 212
==8359== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x5C83D71: strdup (strdup.c:43)
==8359== by 0x41F810: extract_sockaddr (util.c:872)
==8359== by 0x404DB3: detect_stratum (cgminer.c:558)
==8359== by 0x404EA0: set_url (cgminer.c:582)
==8359== by 0x433E98: parse_one (parse.c:110)
==8359== by 0x4336B9: opt_parse (opt.c:213)
==8359== by 0x41BB19: main (cgminer.c:6454)
==8359==
==8359== 44 bytes in 1 blocks are definitely lost in loss record 82 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x41D624: resp_hdr_cb (util.c:129)
==8359== by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x4E61527: Huh

(in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x41E3A9: json_rpc_call (util.c:377)
==8359== by 0x414AC1: pool_active (cgminer.c:4807)
==8359== by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359== by 0x52A1E99: start_thread (pthread_create.c:308)
==8359== by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 49 bytes in 1 blocks are definitely lost in loss record 89 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x41D624: resp_hdr_cb (util.c:129)
==8359== by 0x4E497F2: Curl_client_write (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x4E4832D: Curl_http_readwrite_headers (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x4E5FC39: Curl_readwrite (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x4E61527: Huh

(in /usr/lib/x86_64-linux-gnu/libcurl.so.4.2.0)
==8359== by 0x41E3A9: json_rpc_call (util.c:377)
==8359== by 0x414AC1: pool_active (cgminer.c:4807)
==8359== by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 160 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359== by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359== by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359== by 0x4149F6: pool_active (cgminer.c:4794)
==8359== by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 161 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359== by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359== by 0x41F338: thr_info_create (util.c:767)
==8359== by 0x41C965: main (cgminer.c:6790)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 162 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359== by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359== by 0x41F338: thr_info_create (util.c:767)
==8359== by 0x41CBDD: main (cgminer.c:6850)
==8359==
==8359== 288 bytes in 1 blocks are possibly lost in loss record 163 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x4012074: _dl_allocate_tls (dl-tls.c:297)
==8359== by 0x52A2ABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8359== by 0x414829: init_stratum_thread (cgminer.c:4748)
==8359== by 0x4149F6: pool_active (cgminer.c:4794)
==8359== by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359== by 0x52A1E99: start_thread (pthread_create.c:308)
==8359== by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 531 (504 direct, 27 indirect) bytes in 1 blocks are definitely lost in loss record 176 of 212
==8359== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x405E0D: make_work (cgminer.c:1361)
==8359== by 0x41CCEC: main (cgminer.c:6886)
==8359==
==8359== 727 (104 direct, 623 indirect) bytes in 1 blocks are definitely lost in loss record 180 of 212
==8359== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x5092C74: Huh

(in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x50930A2: Huh

(in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x41E6F1: json_rpc_call (util.c:425)
==8359== by 0x414AC1: pool_active (cgminer.c:4807)
==8359== by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359== by 0x52A1E99: start_thread (pthread_create.c:308)
==8359== by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 1,383 (104 direct, 1,279 indirect) bytes in 1 blocks are definitely lost in loss record 187 of 212
==8359== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x5092C74: Huh

(in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x50930A2: Huh

(in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x41E6F1: json_rpc_call (util.c:425)
==8359== by 0x414CA2: pool_active (cgminer.c:4852)
==8359== by 0x417D70: watchpool_thread (cgminer.c:5757)
==8359== by 0x52A1E99: start_thread (pthread_create.c:308)
==8359== by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 65,432 bytes in 1 blocks are definitely lost in loss record 210 of 212
==8359== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x425CF6: _io_new (api.c:652)
==8359== by 0x42DC0D: api (api.c:3684)
==8359== by 0x412662: api_thread (cgminer.c:4348)
==8359== by 0x52A1E99: start_thread (pthread_create.c:308)
==8359== by 0x5CEECBC: clone (clone.S:112)
==8359==
==8359== 672,368 (104 direct, 672,264 indirect) bytes in 1 blocks are definitely lost in loss record 212 of 212
==8359== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8359== by 0x50952B1: json_object (in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x5092C74: Huh

(in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x50930A2: Huh

(in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x5093202: json_loads (in /usr/lib/libjansson.so.4.2.1)
==8359== by 0x41E6F1: json_rpc_call (util.c:425)
==8359== by 0x414CA2: pool_active (cgminer.c:4852)
==8359== by 0x41C4D3: main (cgminer.c:6708)
==8359==
==8359== LEAK SUMMARY:
==8359== definitely lost: 66,418 bytes in 12 blocks
==8359== indirectly lost: 674,193 bytes in 3,866 blocks
==8359== possibly lost: 1,152 bytes in 4 blocks
==8359== still reachable: 166,745 bytes in 261 blocks
==8359== suppressed: 0 bytes in 0 blocks
==8359== Reachable blocks (those to which a pointer was found) are not shown.
==8359== To see them, rerun with: --leak-check=full --show-reachable=yes
==8359==
==8359== For counts of detected and suppressed errors, rerun with: -v
==8359== ERROR SUMMARY: 14 errors from 14 contexts (suppressed: 2 from 2)
valgrind --lea
ak-check=full ./cgminer --api-port 9999 --per-device-stats --api-
-network --api-listen -S/dev/ICA0 --icarus-timing=1:38
==8748== Memcheck, a memory error detector
==8748== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8748== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8748== Command: ./cgminer xxxxxxxxxx --api-port 9999 --per-device-stats --api-network --api-listen -S/dev/ICA0 --icarus-timing=1:38
==8748==
[2013-02-02 12:00:23] Started cgminer 2.10.4

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Just for anyone interested while I work on it.

https://github.com/kanoi/cgminer/commits/usb2
Hotplug (currently v0.1) for usbutils.c (that uses libusb) devices.

So far, the usbutils devices are BFL and MMQ
I've been doing all my testing with the BFL (no MMQ testing done yet)
Works fine as it is with BFL already ... and 'should' work with MMQ

All new devices that are built with usbutils.c will automatically be hotplug also.
(so that will include any ASIC drivers written by us)

I'll get around to converting the Icarus driver to usbutils one day ... to make ICA, CM1 & LOT hotplug also
(though that CM1 name will need a change Tongue

... maybe CMR)
But it's low on the priority at the moment, my todo list has quite a few things in it that I want to do
(including enhancements to this basic hotplug)

Edit:
1) When a usbutils device disappears it says on the screen "ZOMBIE" (not dead)
That's also automatic (like hotplug is)
API says No Device=true
2) Hotplug devices say a message on the screen like:
"Hotplug: BitForce added BFL 2"
3) The Hotplug devices don't show in the device list section of the curses screen
I haven't decided how to handle that yet

CrazyGuy

legendary

Activity: 1973

Merit: 1007

Quote from: -ck on December 30, 2012, 08:02:26 PM

Quote from: BitMinerN8 on December 30, 2012, 07:56:57 PM

Quote from: -ck on December 30, 2012, 07:28:48 PM

Quote from: BitMinerN8 on December 30, 2012, 07:21:09 PM

I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)

I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.

Code:

CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev

Returns the following:

Code:

  curses.TUI...........: FOUND: -lncurses

Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)

Code:

util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)

That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.

That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.

I did an apt-get remove libcurl4-gnutls-dev && apt-get install libcurl4-gnutls-dev

Code:

Unpacking libcurl4-gnutls-dev (from .../libcurl4-gnutls-dev_7.21.0-2.1+squeeze2_i386.deb) ...
Processing triggers for man-db ...
Setting up libcurl4-gnutls-dev (7.21.0-2.1+squeeze2) ...

So is that the wrong version? (Still no love on the make clean / make) Any clue on how to get the 7.25.0+ version you speak of?
Thank you for your time.

It's still supposed to work with older curls. Somewhere it is thinking you have a later version installed which you don't. Anyway I usually install libcurl4-openssl-dev

I was getting the exact same compilation errors today upgrading from 2.9.6. Ubuntu 12.04 apt-get would not install higher than 7.22.0-3ubuntu4. Instead of messing around with it further, I just went ahead and updated to 12.10 and low and behold, i've now got version 7.27.0 of libcurl4-openssl-dev. CGminer compiles fine now.

PatronDragon

sr. member

Activity: 283

Merit: 250

I use 2 videocards 7970 and 5870 but CGminer writes me that the incorrect file of a configuration! Write to me as the configuration file has to look correctly!

loshia

legendary

Activity: 1610

Merit: 1000

Quote from: -ck on February 01, 2013, 05:15:03 PM

Yes there is a very slow memory leak in it which only becomes a problem at high hashrates on machines with little ram. A fix will be coming soon.

Super!
My hash rate is about 9200 Mh/s on that host. Probably that is the reason why jgarzik has frequent restarts with his Avalon...

Thanks once again ..I am watching git closely and will compile/upgrade new version immediately and let you know how it goes
10X

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: loshia on February 01, 2013, 05:00:11 PM

Guy's

I am running my lancelot cluster on tp-link openwrt platform with 64M of ram. I am noticing the restart of my system because cgminer 2.10.4 slowly and steadily eats all of the available free RAM about 45M.

And when cgminer eats all memory (45M) it takes about 2-3 days following happens

Feb 1 14:36:53 cgminer kern.warn kernel: [281314.280000] miner 11 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Kernel kills cgminer because system is running out of ram

Is there a way to reduce mem usage when cgminer is compiled for openwrt?

10X
PS: Otherwise it runs perfect same as when my pc i386 was used. No hashing speed decrease. The only difference was that my PC had 4G of RAM Sad

Yes there is a very slow memory leak in it which only becomes a problem at high hashrates on machines with little ram. A fix will be coming soon.

loshia

legendary

Activity: 1610

Merit: 1000

Guy's

I am running my lancelot cluster on tp-link openwrt platform with 64M of ram. I am noticing the restart of my system because cgminer 2.10.4 slowly and steadily eats all of the available free RAM about 45M.

And when cgminer eats all memory (45M) it takes about 2-3 days following happens

Feb 1 14:36:53 cgminer kern.warn kernel: [281314.280000] miner 11 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Kernel kills cgminer because system is running out of ram

Is there a way to reduce mem usage when cgminer is compiled for openwrt?

10X
PS: Otherwise it runs perfect same as when my pc i386 was used. No hashing speed decrease. The only difference was that my PC had 4G of RAM Sad

SAC

sr. member

Activity: 322

Merit: 250

Quote from: YipYip on February 01, 2013, 06:35:26 AM

I have tried 2 x MSI 890 FX mobo ATI 12.8 drivers...even took teh intensity down to 9 (it gave me 79k/hash for both GPU's ..lol )

The card no matter what after ~ 1 min white/blue/grey...gone

I have had 3 x XFX 5970's working fine in these boards etc... Can i safely say the card is dead Huh

Good chance of it although usually when dead they won't hash at all. Either that or one core will die on you, have had that happen as well.

YipYip

hero member

Activity: 574

Merit: 500

Quote from: -ck on February 01, 2013, 01:02:04 AM

Quote from: SAC on February 01, 2013, 12:00:35 AM

Quote from: -ck on January 31, 2013, 09:18:24 PM

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

That doesn't make much sense unless you use settings that wouldn't work with the display library - and usually that involves setting the memory clock much lower than the engine clock which you don't do on LTC. I've mined LTC numerous times and set clocks just fine with cgminer itself.

I have played around with the settings you guys have perscribed clock speed ,memory settings etc etc

I have tried 2 x MSI 890 FX mobo ATI 12.8 drivers...even took teh intensity down to 9 (it gave me 79k/hash for both GPU's ..lol )

The card no matter what after ~ 1 min white/blue/grey...gone

I have had 3 x XFX 5970's working fine in these boards etc... Can i safely say the card is dead Huh

SAC

sr. member

Activity: 322

Merit: 250

Quote from: -ck on February 01, 2013, 01:02:04 AM

Quote from: SAC on February 01, 2013, 12:00:35 AM

Quote from: -ck on January 31, 2013, 09:18:24 PM

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

That doesn't make much sense unless you use settings that wouldn't work with the display library - and usually that involves setting the memory clock much lower than the engine clock which you don't do on LTC. I've mined LTC numerous times and set clocks just fine with cgminer itself.

Sense or not it does it here is a machine I just put the proper values I need into the .conf and it appears to set the memory but not the engine to what I need and have specified.

Code:

miner4@miner4:~$ odg

Adapter 0 - ATI Radeon HD 5800 Series  
                            Core (MHz)    Memory (MHz)
           Current Clocks :    925           1185
             Current Peak :    925           1185
  Configurable Peak Range : [600-875]     [300-1200]
                 GPU load :    99%

Adapter 1 - ATI Radeon HD 5900 Series
                            Core (MHz)    Memory (MHz)
           Current Clocks :    800           1160
             Current Peak :    800           1160
  Configurable Peak Range : [550-1000]     [300-1500]
                 GPU load :    99%

Adapter 2 - ATI Radeon HD 5900 Series
                            Core (MHz)    Memory (MHz)
           Current Clocks :    800           1160
             Current Peak :    800           1160
  Configurable Peak Range : [550-1000]     [300-1500]
                 GPU load :    99%

Code:

miner4@miner4:~$ cat .cgminer/cgminer.conf
{
"pools" : [
....
],

"auto-fan" : true,
"auto-gpu" : true,
"temp-target" : "79",
"gpu-fan" : "0-100",
"intensity" : "18,18,18",
"gpu-engine" : "0-835,0-780,0-780",
"gpu-memclock" : "1185,1160,1160",
"vectors" : "4,4,4",
"worksize" : "256,256,256",
"thread-concurrency" : "6720,8000,8000",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"donation" : "0",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: SAC on February 01, 2013, 12:00:35 AM

Quote from: -ck on January 31, 2013, 09:18:24 PM

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

That doesn't make much sense unless you use settings that wouldn't work with the display library - and usually that involves setting the memory clock much lower than the engine clock which you don't do on LTC. I've mined LTC numerous times and set clocks just fine with cgminer itself.

SAC

sr. member

Activity: 322

Merit: 250

Quote from: -ck on January 31, 2013, 09:18:24 PM

Why would you use aticonfig when you can change the clocks directly with cgminer?

Never works with ltc on my machines btc sets them to exactly what I to use in the .conf and as I have said with ltc good luck with that..

Edit: Should add it appears to go with the default of the card involved in ltc mining as I have two 6970s that their default speeds are the sweet spot for kh/s rate those two I never have to set the speeds as they are already where they need to be once it starts up. Any other cards I check the speeds on after it starts are at their default values then they need to be set to where the speeds need to be for ltc mining.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Why would you use aticonfig when you can change the clocks directly with cgminer?

YipYip

hero member

Activity: 574

Merit: 500

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 411. (Read 5805537 times)