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

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.

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!

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.

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

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

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.

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

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!

 

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

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.

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".

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.

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.

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

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).

@ckolivas

any answer on this question? https://bitcointalksearch.org/topic/m.3489847

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

I sent you a pm

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

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

I like even numbers. A lot.

Great work on this! 3.7.2 seems pretty stable.