OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[aigeezer]

Next test:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-allsync.exe

And here's the mother of all usb changes for testing:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-ymmv.exe

Not sure if you meant that just for jmc1517 but I'm testing it anyway, replacing 3.7.2 which was going strong after 23 hours. "ymmv" is off to a good start, but only a few minutes in so far. I didn't try "allsync".

[-ck]

Next test:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-allsync.exe

And here's the mother of all usb changes for testing:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-ymmv.exe

Right.  I'll get on the case!

Just for interest, the logfile from the evening/overnight run of 3.5.1 is here. No problems visible on screen and no zombies, but there are some different looking TIMEOUT messages in the log:
 https://dl.dropboxusercontent.com/u/44240170/logfile-3.5.1.txt

Just started "allsync" and I've got a zombie AMU 5 straight away, together with the usual timeouts from AMU 0.
Unplugged AMU 5 and left it out.  Now AMU 28 has gone zombie too.  I see different error messagaes in the log though (?)
I guess I'll move on to "ymmv" then...
Logfile here (without --debug):
  https://dl.dropboxusercontent.com/u/44240170/logfile-allsync.txt

Well that is very interesting (again) because as far as I can see, the well working 3.5.1 wasn't really working well anyway. It was clear a while back that your case was different to aigeezer's but I'm going to go out on a limb here and say that you actually have a hardware problem. The one that fails every single time first up is suspicious, and it seems to create a cascade of other problems.

[Jeffrey]

...

Unless I misunderstand how you are wiring it up I would say maybe the Power supply doesn't like working at >100%.
I came to that number based on 60 erupters at .5 amp being 30A and I would have to guess the hub would waste some amount of power. I also have 0 idea how long your cables connecting to the power supply is but at 30A you should have a really short run and large cable.

But I can't figure out why one on the laptop port wouldn't work. I would have taken a shot at it earlier but I didn't see anything obvious unless you only use 1 power supply. Even then your laptop may not provide the full .5 amp without too much voltage sag. Laptops are usually not as powerful on the usb ports. But I know by spec it should work......

EDIT: by I misunderstand how you are wiring it up I mean that you say you have 2 hubs and one power supply. Possibly you wanted to convey a power supply per hub. I made the assumption that you had one power supply per hub the first time I read it as you would be woefully under powered otherwise.

Sorry maybe it was my writing. I have 2 hubs and 2 PSU's (both 30a @ 5v).
When I have 30 BE's in hub 1 and 29 BE's in hub 2, it works fine (still, both hubs on their own psu) but as soon as I add a 60th BE (be it in hub 1 or hub 2), it doesn't work anymore.

Anyway at least I know it's not a limitation by the miner, so I'll have to find a solution somewhere else.

Thanks to those who replied

[jmc1517]

Well that is very interesting (again) because as far as I can see, the well working 3.5.1 wasn't really working well anyway. It was clear a while back that your case was different to aigeezer's but I'm going to go out on a limb here and say that you actually have a hardware problem. The one that fails every single time first up is suspicious, and it seems to create a cascade of other problems.

Hmmm, well I've been running "ymmv" for 5 hours now, and no zombies.... BUT ...

What I find interesting is that there are some TIMEOUTS in the log which look VERY similar to those appearing in the 3.5.1 log - which seems to me to be working well.  I don't get any spurious zombies with 3.5.1 and the hash rates all look to be OK, so I don't really "get" the suspected hardware problem.  If it keeps running, then surely that's the main criterion?  Anyway here's the (ongoing) log from "ymmv".  There have been a couple of broadband dropouts during this time which have not caused any ongoing problems, so, "ymmv" has been running very well indeed so far:
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Of course I'm tempting fate again with this post.  But what the heck...

Edit:
I've noticed a small visual bug on some of these later builds.  You may be aware of it - it probably results from initial recognition of the devices when the table expands - at the end of the fixed-part of the display, the first line after the dashes is sometimes frozen as here, from 10:52 and doesn't scroll off, whereas the current lines are 16:39 and scrolling, if you see what I mean?  Very minor in the grand scheme of things, but you may want to fix it...:

 AMU 32:                | 335.6M/334.3Mh/s | A:1544 R: 8 HW:59 WU: 4.4/m
 AMU 33:                | 335.8M/333.9Mh/s | A:1623 R: 0 HW:21 WU: 4.6/m
--------------------------------------------------------------------------------
 [2013-11-06 10:52:20] Accepted 02506e24 Diff 111/3 AMU 12 pool 0
 [2013-11-06 16:39:08] Accepted 13f26331 Diff 13/8 AMU 1 pool 0
 [2013-11-06 16:39:08] Accepted 0a61a71f Diff 25/8 AMU 8 pool 0


Edit: Midnight update: 12 hours and still no zombies. Go ymmv!

 

[os2sam]

OK, I was going to try 3.7.0 when it was released so I rebooted my rig to make sure the old .dll's were purged from memory.  Well what a fiasco that was with the new 49 port hub and 47 BE's in it.  I just now got the rig going again with the new neat and nifty hub, I'm not so impressed with it at the moment.  Well in the mean time there have been only two new versions released.

So I'm starting with 3.7.2 in two instances, one with 47 BE's and one with a Jalapeno.  Is there anything in particular I should be watching for?  I just want to make sure I put in a good report if the need arises.  There has been ALLOT of development since 3.4.3 and I haven't kept up with all of it.

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.

Thanks,
Sam

[jedimstr]

OK, I was going to try 3.7.0 when it was released so I rebooted my rig to make sure the old .dll's were purged from memory.  Well what a fiasco that was with the new 49 port hub and 47 BE's in it.  I just now got the rig going again with the new neat and nifty hub, I'm not so impressed with it at the moment.  Well in the mean time there have been only two new versions released.

So I'm starting with 3.7.2 in two instances, one with 47 BE's and one with a Jalapeno.  Is there anything in particular I should be watching for?  I just want to make sure I put in a good report if the need arises.  There has been ALLOT of development since 3.4.3 and I haven't kept up with all of it.

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.

Thanks,
Sam

It may be a good idea to unplug the ASICMiner hub from your computer when rebooting and plugging it back in after Windows startup chug chug chugging is done.  Once replugged and after detection from Windows, you should be good to go.  I find I have to do this with any of my hubs connected to miners.

[os2sam]

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.

It may be a good idea to unplug the ASICMiner hub from your computer when rebooting and plugging it back in after Windows startup chug chug chugging is done.  Once replugged and after detection from Windows, you should be good to go.  I find I have to do this with any of my hubs connected to miners.

Yep that does speed up the shutdown/reboot.  But when I plugged it back in Windoze only detected 4 out of the 8 generic hubs and none of the BE's in it.  If I tried to scan for new hardware or delete one the device manager just hangs, for days if I let it.

Same behavior on three different machines with Win7 32 and 64 bit.
Thanks,
Sam

[os2sam]

I have an instance of CGminer 3.7.2 with a Jalapeno.  I'm getting a WU: 0.3.  It is definitely submitting more shares than that per minute.  My BE instance seems OK.
Sam

[jedimstr]

On a side note, is there a thread for these ASICMiner hubs?  Rebooting a Windoze box shouldn't be a week long project.

It may be a good idea to unplug the ASICMiner hub from your computer when rebooting and plugging it back in after Windows startup chug chug chugging is done.  Once replugged and after detection from Windows, you should be good to go.  I find I have to do this with any of my hubs connected to miners.

Yep that does speed up the shutdown/reboot.  But when I plugged it back in Windoze only detected 4 out of the 8 generic hubs and none of the BE's in it.  If I tried to scan for new hardware or delete one the device manager just hangs, for days if I let it.

Same behavior on three different machines with Win7 32 and 64 bit.
Thanks,
Sam

hmmm... at that point, can't help much... my miners are either Linux or Mac based.  They have the same issues with reboots (especially macs who like to look for any bootable device on USB and would take awhile pinging each and every hub and BE) but once reconnected after boot, everything lights up nice and solid.  I only startup the mining software (depending on the worker, its either running cgminer or another software that will go un-named in this thread ) once everything is lit and ready to go.

[ThinkFast]

Trying to mine litecoins with cgminer.
W2KSP3
GPU 0 HD4850

LTC.bat:
set term=
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer.exe -d 0 --scrypt -o http://ltc.give-me-coins.com:3333 -u user.worker -p pass --failover-only --shaders=800 -I 10 -Q 2

Log:
[2013-11-06 23:18:41] Started cgminer 3.7.2
Just seems to hang. I can CTRL-C to cmd prompt.

I've looked at just about every site's config for cgminer. They are all the same.

Question: What's the most likely reason I can't connect to their server?
Should I be using an older version of cgminer (2.6.1)?

Thanks!

[os2sam]

Trying to mine litecoins with cgminer.
W2KSP3
GPU 0 HD4850

Should I be using an older version of cgminer (2.6.1)?

I don't know squat about alt coin mining.  But, doesn't scrypt require newer Catalyst versions than are supported by that old GPU and OS?  Pretty sure you need Catalyst in the 13.x version range.

[ThinkFast]

Yeah...You might be right.
I will try it on my HD5570 to confirm.

[loshia]

Kon,
 I discovered flowing nasty bug which is present on MIPS TP-link only

/* This is the central place all work that is about to be retired should be
 * cleaned to remove any dynamically allocated arrays within the struct */
void clean_work(struct work *work)
{
  if (work->job_id) free(work->job_id);

For some reason work->job_id is not set always - do not ask why and tp-link breaks badly - debugged and fixed with gdb server/client

Best

PS:

 [2013-11-07 10:38:34] Accepted fbc145d6 Diff 260/128 HEXa 3 pool 0
 [2013-11-07 10:38:54] Accepted f6a0cfde Diff 266/256 HEXa 0 pool 0
 [2013-11-07 10:39:30] Pool 0 difficulty changed to 128
 [2013-11-07 10:39:51] Rejected 017a21de Diff 173/128 HEXa 3 pool 0 (Below difficulty)



On tp-link MIPS  from times to time some good shares seemed to be rejected. Probably there is some issue in checking work if it matches pool difficulty?

Please comment
10X

[-ck]

Con,
 I discovered flowing nasty bug which is present on MIPS TP-link only

/* This is the central place all work that is about to be retired should be
 * cleaned to remove any dynamically allocated arrays within the struct */
void clean_work(struct work *work)
{
  if (work->job_id) free(work->job_id);

For some reason work->job_id is not set always - do not ask why and tp-link breaks badly - debugged and fixed with gdb server/client

Ioshia. Thanks , that's very interesting, however calling free on NULL is a valid thing to do so I don't understand how this helps? If work->job_id == NULL then free(work->job_id) equates to free(NULL);

[loshia]

Con,
 I discovered flowing nasty bug which is present on MIPS TP-link only

/* This is the central place all work that is about to be retired should be
 * cleaned to remove any dynamically allocated arrays within the struct */
void clean_work(struct work *work)
{
  if (work->job_id) free(work->job_id);

For some reason work->job_id is not set always - do not ask why and tp-link breaks badly - debugged and fixed with gdb server/client

Ioshia. Thanks , that's very interesting, however calling free on NULL is a valid thing to do so I don't understand how this helps? If work->job_id == NULL then free(work->job_id) equates to free(NULL);

I know...
but life sucks
Can you comment the diff issue also?
PS: I can revert back my change and post gdb output if you want ?

[-ck]

PS:

 [2013-11-07 10:38:34] Accepted fbc145d6 Diff 260/128 HEXa 3 pool 0
 [2013-11-07 10:38:54] Accepted f6a0cfde Diff 266/256 HEXa 0 pool 0
 [2013-11-07 10:39:30] Pool 0 difficulty changed to 128
 [2013-11-07 10:39:51] Rejected 017a21de Diff 173/128 HEXa 3 pool 0 (Below difficulty)

I'll investigate.... no wait a minute, HEXa is not a driver that I maintain or support in cgminer so I can point the finger at that.

[jmc1517]

Update: The test of cgminer-ymmv is still going strong. Almost 24 hours now and no zombies. Whatever is in this build seems to have done the trick

Ongoing logfile here (without --debug), although nothing new in it except accepted shares
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Edit:  OK, the only problem I can see is with AMU6 which has a much lower accepted share rate than all the rest (others are all up in 6000's).  Suppose this might be something to worry about (?):

 AMU  2:                | 335.3M/333.5Mh/s | A:6322 R:12 HW: 67 WU: 4.6/m
 AMU  3:                | 335.8M/333.6Mh/s | A:6276 R: 8 HW: 57 WU: 4.6/m
 AMU  4:                | 335.5M/333.4Mh/s | A:6169 R: 3 HW:207 WU: 4.5/m
 AMU  5:                | 335.3M/333.3Mh/s | A:6300 R: 8 HW:191 WU: 4.6/m
 AMU  6:                | 335.8M/333.4Mh/s | A:2245 R:19 HW: 83 WU: 1.6/m     <---- low ??
 AMU  7:                | 335.5M/333.5Mh/s | A:6149 R:16 HW: 50 WU: 4.6/m
 AMU  8:                | 335.6M/333.6Mh/s | A:5795 R: 8 HW: 67 WU: 4.6/m

[-ck]

Update: The test of cgminer-ymmv is still going strong. Almost 24 hours now and no zombies. Whatever is in this build seems to have done the trick

Ongoing logfile here (without --debug), although nothing new in it except accepted shares
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Sync transfers.

Except for regular gross timeout overflows.

Code:

 [2013-11-06 15:41:15] AMU11: TIMEOUT GetResults took 822ms but was 100ms
 [2013-11-06 15:41:15] AMU3: TIMEOUT GetResults took 813ms but was 100ms
 [2013-11-06 15:41:15] AMU6: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU27: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU19: TIMEOUT GetResults took 797ms but was 100ms
 [2013-11-06 15:41:15] AMU7: TIMEOUT GetResults took 795ms but was 100ms
 [2013-11-06 15:41:15] AMU12: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU20: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU5: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU1: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU26: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU4: TIMEOUT GetResults took 783ms but was 100ms
 [2013-11-06 15:41:15] AMU25: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU21: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU29: TIMEOUT GetResults took 769ms but was 100ms
 [2013-11-06 15:41:15] AMU32: TIMEOUT GetResults took 760ms but was 100ms
 [2013-11-06 15:41:15] AMU31: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU0: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU18: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU33: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU30: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU9: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU22: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU23: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU24: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU16: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU8: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU17: TIMEOUT GetResults took 735ms but was 100ms

Note they all happen at the same time. So whatever is causing communication issues is happening across the board which is why it looks hardware related to me.

Still not sure what to make about all this and whether it's even pursuing it any further. Perhaps offering a sync option or a binary for troublesome setups or something...

[jmc1517]

Update: The test of cgminer-ymmv is still going strong. Almost 24 hours now and no zombies. Whatever is in this build seems to have done the trick

Ongoing logfile here (without --debug), although nothing new in it except accepted shares
 https://dl.dropboxusercontent.com/u/44240170/logfile-ymmv-ongoing.txt

Sync transfers.

Except for regular gross timeout overflows.

Code:

 [2013-11-06 15:41:15] AMU11: TIMEOUT GetResults took 822ms but was 100ms
 [2013-11-06 15:41:15] AMU3: TIMEOUT GetResults took 813ms but was 100ms
 [2013-11-06 15:41:15] AMU6: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU27: TIMEOUT GetResults took 803ms but was 100ms
 [2013-11-06 15:41:15] AMU19: TIMEOUT GetResults took 797ms but was 100ms
 [2013-11-06 15:41:15] AMU7: TIMEOUT GetResults took 795ms but was 100ms
 [2013-11-06 15:41:15] AMU12: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU20: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU5: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU1: TIMEOUT GetResults took 784ms but was 100ms
 [2013-11-06 15:41:15] AMU26: TIMEOUT GetResults took 785ms but was 100ms
 [2013-11-06 15:41:15] AMU4: TIMEOUT GetResults took 783ms but was 100ms
 [2013-11-06 15:41:15] AMU25: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU21: TIMEOUT GetResults took 770ms but was 100ms
 [2013-11-06 15:41:15] AMU29: TIMEOUT GetResults took 769ms but was 100ms
 [2013-11-06 15:41:15] AMU32: TIMEOUT GetResults took 760ms but was 100ms
 [2013-11-06 15:41:15] AMU31: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU0: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU18: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU33: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU30: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU9: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU22: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU23: TIMEOUT GetResults took 736ms but was 100ms
 [2013-11-06 15:41:15] AMU24: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU16: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU8: TIMEOUT GetResults took 735ms but was 100ms
 [2013-11-06 15:41:15] AMU17: TIMEOUT GetResults took 735ms but was 100ms

Note they all happen at the same time. So whatever is causing communication issues is happening across the board which is why it looks hardware related to me.

Still not sure what to make about all this and whether it's even pursuing it any further. Perhaps offering a sync option or a binary for troublesome setups or something...

True, but...
a)  It hasn't happened since yesterday.
b) These look like the same "errors" which 3.5.1 reports
c) It doesn't result in the setting of a zombie, so mining continues (?)

I would happily run this build as it doesn't cause me - the end-user - any problems!!

Edit: Please see edited previous post - One AMU has low accepted share rate. Ah, it hasn't done any work since 19:00 last night.  Perhaps this one "should" have been a zombie after all then?

[-ck]

OK, the only problem I can see is with AMU6 which has a much lower accepted share rate than all the rest (others are all up in 6000's).  Suppose this might be something to worry about (?):

 AMU  2:                | 335.3M/333.5Mh/s | A:6322 R:12 HW: 67 WU: 4.6/m
 AMU  3:                | 335.8M/333.6Mh/s | A:6276 R: 8 HW: 57 WU: 4.6/m
 AMU  4:                | 335.5M/333.4Mh/s | A:6169 R: 3 HW:207 WU: 4.5/m
 AMU  5:                | 335.3M/333.3Mh/s | A:6300 R: 8 HW:191 WU: 4.6/m
 AMU  6:                | 335.8M/333.4Mh/s | A:2245 R:19 HW: 83 WU: 1.6/m     <---- low ??
 AMU  7:                | 335.5M/333.5Mh/s | A:6149 R:16 HW: 50 WU: 4.6/m
 AMU  8:                | 335.6M/333.6Mh/s | A:5795 R: 8 HW: 67 WU: 4.6/m

Makes me wonder then if it isn't this one device causing issues with everything else cause that's clearly dodgy.