There is still no sign of a fix for the out of memory condition killing cgminer. I wouldn't be pleased to have a nice shiny new november order Jupiter dying periodically for such a simple well known reason, losing hours sitting there waiting for me to wake up and notice because they neglected to include a watchdog to keep the thing running and/or neglected to ensure their software fit into the amount of RAM they saw fit to build into the unit...
-MarkM-
I believe the issue there is/was while using Bertmod, the ram is otherwise sufficient. It has 512MB of DDR3 You have something else going on? I agree with Mark there is a memory leak somewhere, on some machines at least. I've had the best luck with running cgminer 3.7.2 manually after killing the one that comes with the knc firmware, but even then after 3 days free memory has dropped 100MB, from 250MB down to 150MB free, I haven't had it drop so low that it stops mining like Mark has, but I've seen it drop down to the 12MB free mark before I rebooted. |
|
|
|
Umm, that's cool, but I can assure you not that's clearly not he case on all units. I have pictures of the one I took to Atlanta using a Kill-A-Watt, and there were enough witnesses that were present, including members of this forum (Bargraphics, Phin Gage), and representatives from competing companies that saw this for their own eyes. Also there's plenty in this thread amongst the first recipients to verify otherwise.
And I'd be willing to bet a few satoshi's that the unit you took to Atlanta did not have the same firmware as those units that were subsequently shipped out to Day 1 customers onwards...and that the voltage was tweaked upwards in the interim thus increasing the power requirements (in the name of increasing performance/stability, I'm sure). Couple the fact that the actual physical design of the product was changed quite substantially (8 VRMs to 4 VRMs) and it's not exactly apples-to-apples  So basically all you can say is that a few machines that you know of pulled high watts, you don't know how many right? I'd guess that, relative to the entire Day1/Day2/October production run its probably just a few isolated units caused by manufacturing and/or production tolerances. I don't know for sure, thats why I am saying "I guess" but at least I'm not making out like it was a huge problem for everyone. Plus it was like Day 1 units, almost prototypes in a way, cutting-edge-get-it-before-anyone type stuff. Surely the discussion is about now, people coming into the thread recently to find out what they need for the next batch. I'm saying that all of the Day1/Day2 machines that were delivered with pre-.95 firmware pulled very high wattage..and in some cases that translated to hardware failures when coupled with PSU's like the Corsair HX850 that contributed to exploding capacitors. Actually testing specific PSU's and making specific recommendations based on known-working models would have been better instead of leaving it to chance for customers to figure it out on their own. I, myself, bought the same model as KnC's hosting but gave myself some extra margin with higher wattage rating so my machine was never running over-spec of the PSU at any time on any firmware (the VRMs themselves, well, that's another story). I don't know how you think you can say that ALL of them had the same issue, especially with the variation in ability of the devices. e.g. My Jupiter is happiest running 0.96 with any variation of cgminer however its not happy running any firmware above that. I don't know why, I think its to do with it not liking what the newer firmware does to the voltage to try and stabilize machines with flakey cores. But I firmly believe that my machine is probably in the minority, just as I believe that the ones you are talking about are a drop in the ocean compared to the number of non-problematic machines they have shifted that we just never hear about. |
|
|
|
Umm, that's cool, but I can assure you not that's clearly not he case on all units. I have pictures of the one I took to Atlanta using a Kill-A-Watt, and there were enough witnesses that were present, including members of this forum (Bargraphics, Phin Gage), and representatives from competing companies that saw this for their own eyes. Also there's plenty in this thread amongst the first recipients to verify otherwise.
And I'd be willing to bet a few satoshi's that the unit you took to Atlanta did not have the same firmware as those units that were subsequently shipped out to Day 1 customers onwards...and that the voltage was tweaked upwards in the interim thus increasing the power requirements (in the name of increasing performance/stability, I'm sure). Couple the fact that the actual physical design of the product was changed quite substantially (8 VRMs to 4 VRMs) and it's not exactly apples-to-apples So basically all you can say is that a few machines that you know of pulled high watts, you don't know how many right? I'd guess that, relative to the entire Day1/Day2/October production run its probably just a few isolated units caused by manufacturing and/or production tolerances. I don't know for sure, thats why I am saying "I guess" but at least I'm not making out like it was a huge problem for everyone. Plus it was like Day 1 units, almost prototypes in a way, cutting-edge-get-it-before-anyone type stuff. Surely the discussion is about now, people coming into the thread recently to find out what they need for the next batch. |
|
|
|
Jebus we've had this PSU discussion at least twice before. Just buy the PSU that you want that has at least the minimum spec the manufactrer recommends. Personally I run mine off a 1500W Silverstone connected to a 2200W UPS. But that's what I just had lying around after my CM 850V died.
A lot of people still come to the thread and start at the end... Reading 100+ pages of mostly drivel would try the patience of a saint.  LOL There is also a search box, pop PSU in there while in the thread and its amazing what comes back. Of course its no issue people not wanting to read the thread, but then it goes on and on rehashing the same old arguments and the thread gets full of crap. |
|
|
|
|
Jebus we've had this PSU discussion at least twice before. Just buy the PSU that you want that has at least the minimum spec the manufactrer recommends. Personally I run mine off a 1500W Silverstone connected to a 2200W UPS. But that's what I just had lying around after my CM 850V died.
|
|
|
|
The components on a PC motherboard do the same things as the components on an ASIC board. In fact, the ASIC board does even less. The only difference is the power requirements, but you can split that up into multiple smaller pieces. "500-1000 times faster at hashing" doesn't mean 500-1000 times more actual electricity.
thats simply not exactly true now is it? making out that the only difference is the power requirements is making light of a huge issue. with great power requirements comes great heat and thus great cooling requirements, and great power supply requirements. the components on a pc board are to support the intel processor and in general, it runs at a very low wattage most of the time, and is very peaky. i.e.: it only draws LOTS of power when doing something very taxing.. which is not very often.... whereas the components on a mining rig have to run at full pelt, all of the time, 24/7. thats a very different demand were making of them. All the components in a PC are absolutely designed to run flat out 24/7, as they will if you have to render a video or do something else processor intensive for a long period of time. Damn straight, heres my 64 thread quad Intel rig. top - 17:52:56 up 10 days, 4:44, 1 user, load average: 64.04, 64.03, 64.05
Tasks: 425 total, 1 running, 424 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 10.4%sy, 89.6%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32913112k total, 4126464k used, 28786648k free, 108276k buffers
Swap: 356348k total, 0k used, 356348k free, 693244k cached
|
|
|
|
I've got two now that are hung unconfirmed, coming up to 48 hours on the first one and its gone back to 10 hours ETA  |
|
|
|
You lied either about having spoke to Emilia, or the status of the RMA. Pretty simple.
"Your return arrived today, was processed and repaired today, and left here by courier today.
In and out the same day.
That two week stuff is nonsense, you weren't even issued the RMA until the 29/10/13 (last Friday) it's in the RMA code itself." < your quote
Or it was just a mistake and he was given the wrong info. |
|
|
|
I've got a transaction from Slush's today but its status is "Seen by 4 peers. Pending/Unconfirmed"
It's been like that for over 5 hours, dunno what I can do about it.
Wait longer  Its nearly 24 hours now, how long would you wait, and is there even anything that can be done about it? Guess its just wait and see, it appears some people jipped on the transaction fee so now we all have to wait. |
|
|
|
|
Also when you talk of "days" in this industry are they working days or full week days including weekends and holidays?
|
|
|
|
hey guys, i sent btc to the wrong bloody address somehow. fucking copy and paste, can anyone help me recover it? or how to?
Status: 2/unconfirmed, broadcast through 7 nodes
Date: 11/7/2013 21:44
To: 1AmniUAKMDcR2yPfmi6qtt8EiZ3uur9xQ3
Debit: -1.914 BTC
Transaction fee: -0.001 BTC
Net amount: -1.915 BTC
Transaction ID: f6a5c6a8341a8978e4ca47987b147b812dd37e90772cdcefce2699685d6ef6ef
From where the destination address come from? How it ended in your OS clipboard? To recover the funds sent you need to know who controls the destination address. Then you will have to contact the person and ask back the funds. Agree with Augusto, unfortunately you are screwed unless you can contact the recipient of the coins and convince them to return them to you. |
|
|
|
The site is down, either an update or they are being DDOS'ed Unpingable.... ooer |
|
|
|
Are you guys kidding?
I was contemplating a November Jupiter...
and went thru the numbers, and made all the predictions in my usual way, and I came to the conclusion, that a November Jupiter is definitely worth it, and spent the 17.6 BTC, of my 27BTC I made in the first 20 days, to order it moments ago....
And I'm stoked about it...
Think about it...
The November units may even deliver before HF & CT get their act together!
I did the same, but with 15.23 of my BTC  You lucky devil you... !! I'm going to pickup again, I'll might get another t-shirt, and Orama owes me a few beers.  |
|
|
|
Are you guys kidding?
I was contemplating a November Jupiter...
and went thru the numbers, and made all the predictions in my usual way, and I came to the conclusion, that a November Jupiter is definitely worth it, and spent the 17.6 BTC, of my 27BTC I made in the first 20 days, to order it moments ago....
And I'm stoked about it...
Think about it...
The November units may even deliver before HF & CT get their act together!
I did the same, but with 15.23 of my BTC |
|
|
|
|
I've got a transaction from Slush's today but its status is "Seen by 4 peers. Pending/Unconfirmed"
It's been like that for over 5 hours, dunno what I can do about it.
|
|
|
|
Well isn't this a nice familiar site...someone says blah blah blah and another says you are wrong, blah blah blah...
and now sorry for being off topic *ahem!*...
but anyone noticing that their Jupiters stop hashing randomly? The miner webpage inaccessible and the putty window crashes. When i reboot it starts up fine again, but 2 of the 3 crashed again after 4 hours. Will keep track of how long it takes for the next crash.
I get this maybe once every two days. Seems likely it is same problem I have: running out of RAM. The handler for that chooses something to kill and does nto always kill cgminer, last time mine had that it was something to do with the web page that was killed so instead of a working web page saying the miner was stopped I had a not-working web page. Actually maybe even a cannot be pinged machine. I powered down and back up to get it running again. I think we need a new "firmware" upgrade that gets rid of any RAM usage that isn't absolutely system-critical, as software bloat seems to have hit the limits of the beaglebone's RAM or some item of software in there has a memory leak. -MarkM- Tracking the memory on mine its getting low after 25 hours. Start 23:47: Mem: 223984K used, 286588K free, 0K shrd, 28K buff, 203096K cached
CPU: 4% usr 8% sys 0% nic 86% idle 0% io 0% irq 0% sirq
Load average: 2.00 2.01 2.04 1/68 12077 Ater 12 Hrs: Mem: 383664K used, 126908K free, 0K shrd, 28K buff, 351112K cached
CPU: 0% usr 10% sys 0% nic 90% idle 0% io 0% irq 0% sirq
Load average: 2.00 2.01 2.04 1/67 2816
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
2816 31147 root R 2148 0% 10% top
8322 8321 root S 123m 25% 0% ./cgminer -c /config/cgminer.conf
After 25 Hrs: Mem: 488260K used, 22312K free, 0K shrd, 20K buff, 475988K cached
CPU: 15% usr 9% sys 0% nic 74% idle 0% io 0% irq 0% sirq
Load average: 1.88 1.90 1.82 1/67 21144
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
29828 29827 root S 103m 21% 16% /usr/bin/cgminer --default-config /con
Heres the output from meminfo: After 12 Hrs kB After 25 Hrs kB Difference
MemTotal 510572 510572 0
MemFree 125852 20040 -105812
Buffers 28 20 -8
Cached 352044 478276 126232
SwapCached 0 0 0
Active 356396 16136 -340260
Inactive 20312 300 -20012
Active(anon) 24636 4044 -20592
Inactive(anon) 0 0 0
Active(file) 331760 12092 -319668
Inactive(file) 20312 300 -20012
Unevictable 0 465904 465904
Mlocked 0 0 0
HighTotal 0 0 0
HighFree 0 0 0
LowTotal 510572 510572 0
LowFree 125852 20040 -105812
SwapTotal 0 0 0
SwapFree 0 0 0
Dirty 0 0 0
Writeback 0 0 0
AnonPages 24652 4088 -20564
Mapped 3664 3544 -120
Shmem 0 0 0
Slab 5092 5240 148
SReclaimable 2060 2212 152
SUnreclaim 3032 3028 -4
KernelStack 592 584 -8
PageTables 360 316 -44
NFS_Unstable 0 0 0
Bounce 0 0 0
WritebackTmp 0 0 0
CommitLimit 255284 255284 0
Committed_AS 127684 107388 -20296
VmallocTotal 499712 499712 0
VmallocUsed 27484 27484 0
VmallocChunk 389116 389116 0
Interestingly somewhere between 12 and 24 hours it killed the cgminer I was running 3.7.2 and ran the default one instead.  |
|
|
|
I am using the executable ckolivas most recently posted about, supposedly 3.7.1
I don't have an ARM development machine nor know a thing about cross-compiling on Fedora 17 or 19 for ARM machines.
I have run over 48 hours before dying sometimes, even over 72 maybe. Actually maybe it didn't die like this until they released a release that had a ckolivas version in it, hmm I wonder if that one is/was stripped? Hmm... I am not sure when I first encountered this "mystery dying" problem, seems liek it ran quite a few days originally.
I killed it to try running strip on it on the beaglebone, that is how I discovered they dont' seem to have strip on that. But now it shows in web page as 282 so maybe its not goign to lose much by using --lowmem option afterall. I do wonder how much RAM the debugging symbols are consuming though...
-MarkM-
Hi Mark, just a FYI Another 24 hours running the same setup (0.96 with 3.7.2 cgminer) and my memory footprint hasn't changed cgminer is still fluctuating between 23% and 25% memory. However, overall system memory has dropped to only 127MB free. So something is using up memory on the system over time, but its not cgminer. Now: Mem: 383664K used, 126908K free, 0K shrd, 28K buff, 351112K cached
CPU: 0% usr 10% sys 0% nic 90% idle 0% io 0% irq 0% sirq
Load average: 2.00 2.01 2.04 1/67 2816
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
2816 31147 root R 2148 0% 10% top
8322 8321 root S 123m 25% 0% ./cgminer -c /config/cgminer.conf
326 1 root S 3272 1% 0% /usr/bin/ntpd -p /var/run/ntp.pid -g
341 1 root S 3112 1% 0% /usr/sbin/lighttpd -f /etc/lighttpd.co
334 1 avahi S 2824 1% 0% avahi-daemon: running [knc-jupiter1.lo
31009 323 root S 2732 1% 0% /usr/sbin/dropbear -r /config/dropbear
335 334 avahi S 2728 1% 0% avahi-daemon: chroot helper
8321 1 root S 2616 1% 0% {screen} SCREEN ./cgminer -c /config/c
31147 31009 root S 2328 0% 0% -sh
323 1 root S 2272 0% 0% /usr/sbin/dropbear -r /config/dropbear
1775 1 root S 2148 0% 0% {monitordcdc} /bin/sh /sbin/monitordcd
1895 1775 root S 2016 0% 0% sleep 60
1773 1 root S 1908 0% 0% /sbin/getty 115200 ttyO0
1774 1 root S 1908 0% 0% /sbin/getty 38400 tty1
1 0 root S 1652 0% 0% init [5]
1756 1 root S 1496 0% 0% /usr/bin/monitor-pwbtn /usr/bin/factor
58 2 root DW 0 0% 0% [spi1]
10 2 root SW 0 0% 0% [rcu_sched]
15 2 root SW 0 0% 0% [kworker/0:1]
36 2 root SW 0 0% 0% [irq/87-4802a000]
Before: Mem: 223984K used, 286588K free, 0K shrd, 28K buff, 203096K cached
CPU: 4% usr 8% sys 0% nic 86% idle 0% io 0% irq 0% sirq
Load average: 2.00 2.01 2.04 1/68 12077 Heres the output from meminfo: root@knc-jupiter1:~# less /proc/meminfo |more
MemTotal: 510572 kB
MemFree: 125852 kB
Buffers: 28 kB
Cached: 352044 kB
SwapCached: 0 kB
Active: 356396 kB
Inactive: 20312 kB
Active(anon): 24636 kB
Inactive(anon): 0 kB
Active(file): 331760 kB
Inactive(file): 20312 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 510572 kB
LowFree: 125852 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 24652 kB
Mapped: 3664 kB
Shmem: 0 kB
Slab: 5092 kB
SReclaimable: 2060 kB
SUnreclaim: 3032 kB
KernelStack: 592 kB
PageTables: 360 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 255284 kB
Committed_AS: 127684 kB
VmallocTotal: 499712 kB
VmallocUsed: 27484 kB
VmallocChunk: 389116 kB
|
|
|
|
Are some people getting paid to talk positive about KNC?
I think some people ARE KNC. Avenger has made several posts which are negative, yet 100% accurate. If that's poisonous he didn't make the poison, he's just reporting it. On a brighter note.. I just woke up to see us hovering around the 300 exchange rate. That I would never have guessed even a week back. I think some people ARE paranoid. When you have a large production run of any product, there will be some units that have problems. The people who have problems are many orders of magnitude louder than the people who don't. In the end I think the vast majority of people, positive or negative are just providing feedback on their experience and trying to help each other out. |
|
|
|
Are some people getting paid to talk positive about KNC?
Why? Do you want to compare rates?  |
|
|
|
What version are you using? I'm using 3.7.2 over 0.96 firmware. 3.7.0 had some bugs, and 3.7.1 was broken. cgminer is using about 23% of memory on the device. Looks like the device has 512MB of mem. My machine has been running for 24 hours like this. Mem: 223984K used, 286588K free, 0K shrd, 28K buff, 203096K cached
CPU: 4% usr 8% sys 0% nic 86% idle 0% io 0% irq 0% sirq
Load average: 2.00 2.01 2.04 1/68 12077
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8322 8321 root S 112m 23% 4% ./cgminer -c /config/cgminer.conf
326 1 root S 3272 1% 0% /usr/bin/ntpd -p /var/run/ntp.pid -g
341 1 root S 3112 1% 0% /usr/sbin/lighttpd -f /etc/lighttpd.co
334 1 avahi S 2824 1% 0% avahi-daemon: running [knc-jupiter1.lo
9390 323 root S 2732 1% 0% /usr/sbin/dropbear -r /config/dropbear
335 334 avahi S 2728 1% 0% avahi-daemon: chroot helper
8321 1 root S 2616 1% 0% {screen} SCREEN ./cgminer -c /config/c
9576 9575 root R 2328 0% 0% top
9575 9390 root S 2328 0% 0% -sh
323 1 root S 2272 0% 0% /usr/sbin/dropbear -r /config/dropbear
1775 1 root S 2148 0% 0% {monitordcdc} /bin/sh /sbin/monitordcd
11709 1775 root S 2016 0% 0% sleep 60
1773 1 root S 1908 0% 0% /sbin/getty 115200 ttyO0
1774 1 root S 1908 0% 0% /sbin/getty 38400 tty1
1 0 root S 1652 0% 0% init [5]
1756 1 root S 1496 0% 0% /usr/bin/monitor-pwbtn /usr/bin/factor
|
|
|
|
|
Show Posts
