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

[Beastlymac]

is this planed to add?

Not unless someone sends us developers one or more of them.

I sent you a pm

[Jeffrey]

@ckolivas

any answer on this question? https://bitcointalk.org/index.php?topic=28402.msg3489847#msg3489847

A simple "yes" or "no" will suffice for now so at least I know where I should be looking for a solution

[-ck]

@ckolivas

any answer on this question? https://bitcointalk.org/index.php?topic=28402.msg3489847#msg3489847

A simple "yes" or "no" will suffice for now so at least I know where I should be looking for a solution

No limit except the one imposed by your operating system. On windows that's ~127. I know of someone with 2TH of erupters (yes that's not a typo) with ~208 on each linux box running them (ARM devices too so not even full power PCs).

[jmc1517]

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

[Askit2]

Hi,

Maybe a weird question, but is there a limit on the amount of Block Erupters cgminer is able to run? I'm asking this because I'm trying to set 98 up, (2x49port hubs) and it doesn't work.

When I connect hub 1 (with 49 BE's) it's fine. When I disconnect 1 and connect hub 2, it's fine. (so it's not a power issue, both are powered by an ATX supply with 30a on 5v) When I connect both of them at the same time, cgminer tells me it can't find any device and it's waiting for a hotplug.

When connect 1 full and a couple on the 2nd hub, it works. cgminer crashes on hotplug, so I have to close it, add more, and restart it. This works until I have 59. 59 is fine, 60 gives this error. I've tried putting the 60th in different usb ports (also on the laptop host itself), also other sticks, but it just won't accept  60 or more.

This is the behavior on cgminer 3.6.4, 3.7.0 and 3.7.2 (and often, 3.7.2 crashes after 1 or 2 minutes regardless of how many I've attached)

Using windows 7 64bit

Any advise?

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.

[xyzzy099]

@ckolivas

any answer on this question? https://bitcointalk.org/index.php?topic=28402.msg3489847#msg3489847

A simple "yes" or "no" will suffice for now so at least I know where I should be looking for a solution

No limit except the one imposed by your operating system. On windows that's ~127. I know of someone with 2TH of erupters (yes that's not a typo) with ~208 on each linux box running them (ARM devices too so not even full power PCs).

The limit is 127 per host controller, not 127 per machine - right?  And that is not a Windows-specific limit...  It's a USB spec limit.

[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);