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

That's some useful information that the developers can hopefully consider in some future build.  However, if that isn't the case, I think we need to know whether or not there is any indication that the device is visible in the OS and/or powered on since, as a general rule of thumb, I would expect underpowered ports to not power on devices that require more power than is available.  Sure, there may be some mining devices could see enough power to come on, but not enough to mine without errors.  I don't know whether or not there are, but even if there are, I would expect that to be an edge case, not something typical of underpowered USB ports (unless all underpowered USB ports provide the exact same less-than-spec amount of power for some mystical reason [or they are powered to spec and "underpowered" actually means "not overpowered"]).

I had the same issue. By any chance, is it a very recent PC, with a Z87 chipset? In my case, the conclusion was that my particular chipset or USB port wasn't supported by the libusb that cgminer uses. Windows was seeing the BE fine and loading the right drivers, but they still appeared invisible to cgminer. Ultimately I had to find a different platform to mine on.

Win7 x64, just like the PCs.

I could see them being underpowered.  But cgminer doesn't see them.  It's not like it sees them and they don't work, it's like they aren't there.

M

What OS is on your laptop?

Plugging them directly into the laptop?  If so, probably the reason they arent running.  Laptop ports are notoriously under powered.

I ran into a problem with the USB block erupters.  They work great under 3.4.2 on my main PC, plugged straight into my USB 3.0 ports.  They work great on one of my rigs, plugged into multiple USB 3.0/2.0 hubs.  No configuration, just the WinUSB driver and it "just works".

Not so on my laptop.   3.4.2 (and 3.4.3) do not find the miners.  WinUSB is installed.  It looks the same in device manager on my laptop as it does my PC.  But cgminer doesn't see them.

I'm going to try updating my drivers on the laptop.  They should be up to date, but I'm going to check anyhow.

Any ideas?

M

That's why the one Icarus driver does all 5 ICA, BLT, LLT, CMR, AMU
They all work the same way ... just different speeds and different core counts.

CMR does, however, also have a glasswalker bitream that has extra options, but the other 4 are ... well ... missing any useful functionality other than simply hash 4 billion times in a row.
That's why an AMU costs SFA to make and why Friedcat has literally made something like a million selling them.

Look for the specs on the Icarus FPGA since that is the interface BE use.  Seems plausible to me anyway.

New release: Version 3.4.3, 13th September 2013

Stable codebase, feature upgrade version - Proxy support on stratum and per pool quota support. I also sneaked onto my wife's laptop to get osx working.


Human readable changelog:

- Build fixes for cgminer releases to build on OSX (building from git still requires massaging).
- Fix for an extremely rare cause of crashes.
- Updated the screen to show when there is block change notification with multipool strategies and stratum.
- Don't show the "waiting for work" message unless it is longer than it takes to switch pools during lag periods.
- Cope with trailing slashes being used on stratum based URLs.
- miner.php updates.
- Native proxy support on stratum for http1.0, http1.1, socks4, socks4a, socks5 and socks5h proxies without using libcurl for maximum stability.
- A completely rewritten load-balance strategy that now supports per pool quota support. See the following from the updated documentation to see how it works:

LOAD BALANCE:
This strategy sends work to all the pools on a quota basis. By default, all
pools are allocated equal quotas unless specified with --quota. This
apportioning of work is based on work handed out, not shares returned so is
independent of difficulty targets or rejected shares. While a pool is disabled
or dead, its quota is dropped until it is re-enabled. Quotas are forward
looking, so if the quota is changed on the fly, it only affects future work.
If all pools are set to zero quota or all pools with quota are dead, it will
fall back to a failover mode. See quota below for more information.

The failover-only flag has special meaning in combination with load-balance
mode and it will distribute quota back to priority pool 0 from any pools that
are unable to provide work for any reason so as to maintain quota ratios
between the rest of the pools.

QUOTAS

The load-balance multipool strategy works off a quota based scheduler. The
quotas handed out by default are equal, but the user is allowed to specify any
arbitrary ratio of quotas. For example, if all the quota values add up to 100,
each quota value will be a percentage, but if 2 pools are specified and pool0
is given a quota of 1 and pool1 is given a quota of 9, pool0 will get 10% of
the work and pool1 will get 90%. Quotas can be changed on the fly by the API,
and do not act retrospectively. Setting a quota to zero will effectively
disable that pool unless all other pools are disabled or dead. In that
scenario, load-balance falls back to regular failover priority-based strategy.
While a pool is dead, it loses its quota and no attempt is made to catch up
when it comes back to life.

To specify quotas on the command line, pools should be specified with a
semicolon separated --quota(or -U) entry instead of --url. Pools specified with
--url are given a nominal quota value of 1 and entries can be mixed.

For example:
Will give poola 1/3 of the work and poolb 2/3 of the work.

Writing configuration files with quotas is likewise supported. To use the above
quotas in a configuration file they would be specified thus:



Full changelog:

- Put corefoundation and iokit separate in ldflags for darwin.
- Add rules for libusb Makefile.am building on osx
- Add flags for building libusb statically on osx.
- Find the greatest common denominator in quotas and use the smallest number of
consecutive work items per pool in quota load balance mode to smooth hashrate
across pools with large quotas. Give excess quota to priority pool 0 instead of
pool 0.
- Avoid dynamically adding stack memory for nonce2 in the stratum send thread
and check the pool's nonce2_len will not cause an overflow.
- Add subdir-objects to automake options.
- Use inet_addr instead of inet_network to fix windows build.
- Remove unused pbase variable.
- Add support for socks4/4a proxies with stratum, and drop back to socks4
support via the global --socks-proxy command to not break previous
configurations.
- Fix warning on mingw build.
- Only show long-poll message in pool summary if it's not using stratum.
- Increase the time for the waiting for work message to be given to be greater
than that required for a pool swap in the scheduler which is set to 5s.
- Change message in status when using a balanced pool strategy to notify if
there's a stratum pool as well.
- Use the --failover-only flag to have special meaning in combination with
load-balance mode to distribute any unused quota back to pool 0 to maintain
ratios amongst other pools.
- Display quota and allow it to be modified via the pool menu.
- Add API commands and modify output to support pool quota displaying and
changing.
- Change message in status when using a balanced pool strategy to notify if
there's a stratum pool as well.
- Add quota support to configuration files.
- Rotate pools on all failures to set a pool in select_pool.
- Use quotas for load-balance pool strategy.
- Provide a mechanism for setting a pool quota to be used by load-balance.
- Use the --socks-proxy option with stratum, changing it to defaulting to socks5
and give appropriate message should it fail to connect.
- Cope with trailing slashes in stratum urls.
- Add more debugging messages when negotiating with proxies for stratum.
- Test specifically for socks5h in socks support for stratum.
- Add support for socks5 proxy with stratum
- Provide support for negotiating a stratum connection via http proxies.
- Connect to the proxy URL and port if specified for stratum sockets instead of
the pool directly.
- Extract any proxy url and port to be used by sockaddr if possible using
extract_sockaddr.
- Make extract_sockaddr set variables passed to it rather than pool struct
members.
- miner.php sort the mcast rigs so they are always in the same relative order
- miner.php allow sending the muticast message multiple times
- miner.php mcast ignore duplicate replies

cgminer version 3.1.1

I managed to compile cgminer in Android and trying to run it in my SGS4 with opencl, and I have some problems running it (spare me the "why bother" response, I think running cgminer in my phone is kinda cool, and with the advancement of GPUs in the mobile space, you'll never know  )

Anyway-- running cgminer -n gives me:


So it should be ok, right?  But trying to run cgminer with the usual parameters (--scrypt -o -u -p ) gives me:

Code:

[2013-09-13 12:08:12] Started cgminer 3.1.1
[2013-09-13 12:08:12] Probing for an alive pool
Assertion failed: !spillIs.empty() && "No spill intervals?", file vendor/qcom/proprietary/gles/adreno200/llvm/lib/CodeGen/QGPURegAlloc.cpp, line 2628

I compiled cgminer with OpenCL Adreno SDK instead of AMD SDK (for obvious reasons).

Ah right, yeah that doesn't show it though - windows fault (the -12 error)
I guess I could add to the list of possible changes (on windows), to force cgminer to ignore any device that gets a -12 a few times ...

Smart, and about time.

Has anyone experienced any crashes when trying to mine with specific pools using cgminer? It seems that whenever I try to use cgminer against 50BTC's pool, I get a crash after a couple hours. If I change my pool to BTCGuild, it works flawlessly with no crashes.

I'm using something like this in my batch file:
cgminer-nogpu.exe -o http://stratum.50btc.com:3333 -u myuser@goeshere -p mypass -G --no-submit-stale

I have tried pool.50btc.com:8332 as well and still get the same crashes.

Thanks for the quick response Kano!  I'll try editing usbutils.c .

I'm not certain what you're asking for.  The entire output of cgminer -n is in my original post.  I would be happy to investigate further if you guide me.

Thanks again,

~PulsarAV~

Very interesting!

...except cgminer does not use the cp210x driver they're blaming in that thread. It uses libusb to do direct USB communications.

So I brought up this issue over at the Raspberry Pi support Forums and it sounds like this is probably a kernel bug.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=55370

The files have the OpenCL dependent code excluded by the precompiler.  The compiler never sees that code.  It sees roughly this for driver-opencl.c for example:

I don't know if it's a bug or if it's been reported before but :

When I change pool with the API from my modified CryptoSwitcher or with Crypt-o-Matic (to mine the most profitable crapcoin), often, one of my GPU will become SICK and I have to reboot the miner...

I found a work around : using "gpudisable|k" on all GPU, wait 2 seconds, switch pool[addpool, switchpool, disablepool, removepool], wait 2 seconds, use "gpuenable|k" on all GPU. So to make it clear, I need to turn the mining OFF on all cards before switching pool.

That's because the default is to build for opencl. You'll see that ./configure shows:
--disable-opencl
As for install, it's ancient and hardly anyone uses installs via "make install" so no attempt was made to modernise it.