Author

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

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I've noticed two odd behaviors with cgminer since switching to 4.0.1.  This is on Ubuntu 13.10 using the precompiled 64-bit binary of cgminer.  I have a small farm of 31 USB Block Erupters set up on this rig.  I configured the box using the instructions in the README file for USB devices running as a non-root user on Linux. Starting cgminer, they all run fine.

First thing, if I restart cgminer (using Settings -> Restart ->Yes), cgminer throws a "SEM" error for each device saying the devices are already in use.  Even if I wait a bit, cgminer doesn't re-detect them using hotplug.  I'll try to get you the exact error message if you need it.  Exiting cgminer then immediately restarting from the command line works fine; it instantly detects the devices and starts mining.

Second thing, cgminer doesn't seem to save queue settings.  I run p2pool, which recommends a queue of zero.  I set the queue (using Settings -> Queue -> 0), and it confirms the queue is set to zero.  Then I write the config file (Write -> type in path and name) and the summary screen that comes up shows a non-zero value for the queue.  After leaving the node running for a few days, I checked this morning and the queue size was at a stunning 4808! It manifested as a 6% drop in the hash rate for the devices.  Normally they run at a steady 335MH/s, give or take a 1%.  Today I found them at 315MH/s.
Yep restart's pretty broken. It's another one of those features from the GPU days unfortunately and shutting down all these threads reliably is really hard. I mentioned it a few pages back that only quit and start works. If I had infinite hours to work on it I'd eventually fix it, but new device drivers/features keep taking priority sorry.

I changed the queue size to auto adjust every time it hits zero now since it shouldn't - and there are devices with massive hashrates that need a huge queue to keep busy. Unfortunately that seems to be fighting with you trying to set it to zero, but that shouldn't actually drop the hashrate unless you're running out of cpu. So yeah it's not ideal. Kinda hard writing code for 333MH and 50TH setups at the same time. Lemme think about it. This might need a new command line option.

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
hi,
is there an option to use a http proxy on multi pools?
...
You use a proxy setting on each pool you want a proxy for ...
member
Activity: 67
Merit: 10
hi,
is there an option to use a http proxy on multi pools?

i found this but it is only for single pools:
Code:
EXECUTIVE SUMMARY ON USAGE:

Single pool:

cgminer -o http://pool:port -u username -p password

Multiple pools:

cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password

Single pool with a standard http proxy:

cgminer -o "http:proxy:port|http://pool:port" -u username -p password

Single pool with a socks5 proxy:

cgminer -o "socks5:proxy:port|http://pool:port" -u username -p password

Single pool with stratum protocol support:

cgminer -o stratum+tcp://pool:port -u username -p password

The list of proxy types are:
 http:    standard http 1.1 proxy
 http0:   http 1.0 proxy
 socks4:  socks4 proxy
 socks5:  socks5 proxy
 socks4a: socks4a proxy
 socks5h: socks5 proxy using a hostname
sr. member
Activity: 295
Merit: 250
I've noticed two odd behaviors with cgminer since switching to 4.0.1.  This is on Ubuntu 13.10 using the precompiled 64-bit binary of cgminer.  I have a small farm of 31 USB Block Erupters set up on this rig.  I configured the box using the instructions in the README file for USB devices running as a non-root user on Linux. Starting cgminer, they all run fine.

First thing, if I restart cgminer (using Settings -> Restart ->Yes), cgminer throws a "SEM" error for each device saying the devices are already in use.  Even if I wait a bit, cgminer doesn't re-detect them using hotplug.  I'll try to get you the exact error message if you need it.  Exiting cgminer then immediately restarting from the command line works fine; it instantly detects the devices and starts mining.

Second thing, cgminer doesn't seem to save queue settings.  I run p2pool, which recommends a queue of zero.  I set the queue (using Settings -> Queue -> 0), and it confirms the queue is set to zero.  Then I write the config file (Write -> type in path and name) and the summary screen that comes up shows a non-zero value for the queue.  After leaving the node running for a few days, I checked this morning and the queue size was at a stunning 4808! It manifested as a 6% drop in the hash rate for the devices.  Normally they run at a steady 335MH/s, give or take a 1%.  Today I found them at 315MH/s.
member
Activity: 89
Merit: 10
Will do, I have reverted the erupters to 3.12.3, which works great.  The bitcoin mining world is an odd combination of old and new hardware, I'm just running everything I have.  I suppose the financially logical thing to do would be to flip the erupters on Ebay, but I'd rather mine with them as long as they make more than the cost of the electricity that they consume.  Right now, the Avalon Mini + BE's make about $6 a day but cost around $4.  When that line is crossed, the tough thing will be throwing away working hardware, which the engineer in me hates the idea of.
Indeed, it's tough, but I'm pretty sure the erupters fell below their electricity costs a while ago, though I don't have the numbers here. You could always bet on BTC going $10k in the future and thus mining at an electricity cost loss now will pay off longer term... or you could just sell them now for more than they'll ever earn anyway (highly recommend the latter). Anyway in a future version I'll be more lax for these slowest devices left that cgminer still mines on, as this was clearly an oversight on my part. The next slowest device is a normally clocked antminer U1 at 1.6GH, and everyone overclocks them to 2GH anyway, so the difference is stark.

I ran all the numbers today in an excel spreadsheet.  First, let me say that I am mining bitcoin because I believe in bitcoin, so making money would be great but it is not a requirement.  Having run the numbers through, it appears that the Block Erupters and Avalon Mini do indeed make a small profit: Per day electricity cost $1.98, income $4.93, profit $2.95.  This is at the current 3.82G difficulty.  So it looks like 110nm has a little run life left.  I'm going to keep mining and perhaps expand the operation, depending on what happens as the all of the pre-orders are delivered and people mine regardless of cost to recoup what they can.  Interesting days ahead.  Thanks again CK for keeping cgminer up to date.
hero member
Activity: 1246
Merit: 501
Is there a way to ban Luke from this thread? I suggest asking Theymos.

I suggest you keep your nose out of it.  Tongue
full member
Activity: 174
Merit: 100
Tried out 4.0.1 with my hashfast babyjets with upgraded 0.4 preview firmware. I noticed now when a babyjet reconnects for any reason it will keep it's name (ex. HFB 0) in the cgminer window, but in the API it will get a new name (ex. HFB 14) instead of just reactivating the old name. It's not really high priority, but id help clean up the stats I'm pulling from the API if this was corrected.

Also, had a few cases were 4.0.1 crashed when a babyjet hit 90C, went back to 3.12.0 and this did not reoccur.

EDIT: Also, cpu usage by cgminer seems to have greatly increased. I noticed these things with two machines running Windows 7.
legendary
Activity: 1414
Merit: 1001
To weird to live To rare to die
when using 4.0.1 what should my bat file look like for overclocking antminer u1

[/quote)
Whatever it normally looks like plus: --anu-freq 250


works perfectly
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
when using 4.0.1 what should my bat file look like for overclocking antminer u1

Whatever it normally looks like plus: --anu-freq 250
legendary
Activity: 1414
Merit: 1001
To weird to live To rare to die
when using 4.0.1 what should my bat file look like for overclocking antminer u1

edit : thank you ckolivas for the speedy reply on the other thread
member
Activity: 89
Merit: 10
- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...

Running 12 BE's with 4.0.1, working well.  Also updated Avalon Mini to 4.0.1, no issues.  Though oddly, the Mini has slowed down from 62 GH/s to 59 GH/s over a period of months, unrelated to cgminer - I suspect some of the chips have failed.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...
legendary
Activity: 3583
Merit: 1094
Think for yourself
- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?

Give it a try and let us know.
sr. member
Activity: 295
Merit: 250
- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
member
Activity: 109
Merit: 10
Unofficial Mac binaries have been updated for v4.0.1 and tested, and are available here.

These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.

Also, the forum thread title is still 4.0.0 Smiley
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New version: 4.0.1, 28th February 2014

A few fixes for most users on top of 4.0, and some major improvements for hashfast users that hopefully will run in tandem with their 0.4 firmware release.


Human readable changelog:

- Fixed cgminer getting stuck at startup when no pool is valid and getting itself into an endless loop
- Fixed AMUs being detected as failing and resetting them too early
- Made the check for failing devices proportional to hashrate to not get false positives
- Queue size is now adjusted up dynamically when it bottoms out regularly which it may on very high hashrates/many devices
- Fixed ANU and other icarus devices falsely showing higher hashrates by calculating hardware errors - NOTE this means if you were seriously overclocking it before, your hashrate will appear to be lower now, but it was simply reporting wrong before.
- Changed the priority of various threads to bias towards work generation instead of giving the mining threads priority.
- Fixed a crash when a device drops out during an attempt to initialise
- Ava2 voltage detection
- Show the device number on the left without padding
- Fixes for devices that ended in OFF state instead of dropping out to allow them to hotplug
- Hashfast changes:
Multiple devices are now added one by one by hotplugging according to name and then initialising instead of trying to initialise them together which made them fail previously.
Dropping the clock speed on a device failure is limited to default clock speed of 550 and the amount of drop per failure can be configured or disabled with:
Code:
--hfa-fail-drop Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10)

If you overclock your hashfast device with --hfa-hash-clock and cgminer detects
it failing to return hashes, it will restart it at a lower clock speed if
possible. Changing this value will allow you to choose how much it will lower
the clock speed or to disable this function entirely.
Devices with newer firmware can be named using the op name feature, or cgminer will generically choose a suitable name for them and display it at startup
Code:
--hfa-name     Set a unique name for a single hashfast device specified with --usb or the first device found

This command allows you to specify the unique name stored in nvram on a single
hashfast device. This name can be queried from the API stats command and comes
up as "op name". Discrete names are used by cgminer to try to maintain settings
across restarts, unplugs/hotplugs and so on. If this command is used by itself,
the name will be given to the first hashfast device it encounters and then
cgminer will proceed to go back to regular mining. If you have multiple devices,
it is best to discretely choose the device you wish to use with the --usb
command. For example
'lsusb' on linux shows the following devices (297c:0001 is a hfa device):
 Bus 001 Device 079: ID 297c:0001
 Bus 004 Device 042: ID 297c:0001
If you wished to name the second device Slug you would add the commands:
 --hfa-name Slug --usb 4:42
Devices that are re-hotplugged are recognised by their name or serial number if possible and appear back as the same device number on screen
More information in API stats
Updated udev rules file to allow regular users to update firmware
Fixes for corrupt message reading and runs of crc errors
Ability to disable the core shedding feature in new firmware:
Code:
--hfa-noshed        Disable hashfast dynamic core disabling feature

Newer firmwares on hashfast devices dynamically disable cores that generate
invalid data. This command will disable this feature where possible.
Numerous low level fixes


Full changelog:

- Refresh the log window on pool failure message at startup.
- Rework the pool fail to connect at startup to not get stuck indefinitely
repeatedly probing pools with new threads and to exit immediately when any key
is pressed.
- Fix for crashes with a failed startup.
- Use an early_quit function for shutting down when we have not successfully
initialised that does not try to clean up.
- Add more information to a hfa bad sequence tail event.
- Increase the work queue at the top end if we've hit the bottom as well.
- Set the work generation thread high priority, not the miner threads.
- Bringing each hfa device online takes a lot of work generation so only ever do
one at a time.
- Increase the opt_queue if we can hit the maximum amount asked for but are
still bottoming out.
- Keep the old hfa device data intact with a clean thread shutdown to allow it
to be re-hotplugged with the old information.
- Cope with the API calling hfa on partially initialised devices having no info.
- Show only as many digits as are required to display the number of devices.
- Cold plug only one hashfast device to get started, and then hotplug many to
minimise startup delays and possible communication delays causing failed first
starts.
- Send a shutdown and do a usb_nodev if hfa_reset fails.
- Null a device driver should thread prepare fail.
- Add a function for making all driver functions noops.
- Don't try to reinit a device that's disabled.
- Disable a device that fails to prepare.
- Check for lack of thread in watchdog thread for a failed startup.
- Make all device_data dereferences in the hfa driver safe by not accessing it
in statline before when it's non-existent.
- Add an option to disable dynamic core shedding on hashfast devices.
- Do not remove the info struct on a failure to hfa prepare.
- Detect an hfa device purely on the basis of getting a valid header response to
an OP_NAME query, leaving init to hfa_prepare which will allow multiple devices
to start without holding each other up at startup.
- Store the presence and validity of opname in the hfa info.
- api - buffer size off by 1 for joined commands
- minion - clean up statline
- Only break out of usb_detect_one when a new device is found.
- Use usb_detect_one in the hfa driver.
- Provide a usb_detect_one wrapper which only plugs one device at a time,
breaking out otherwise.
- Issue a usb_nodev on a bad work sequence tail in hfa
- Read in hfa stream until we get a HF_PREAMBLE
- Add shed count to hfa API stats output.
- Display the base clockrate for hfa devices with a different name to per die
clockrates to be able to easily distinguish them.
- Use op_name if possible first with hfa devices to detect old instances and be
able to choose the starting clockspeed before sending an init sequence,
reverting to setting op name and serial number as fallbacks.
- Make hfa resets properly inherit across a shutdown.
- Don't break out of hfa_old_device early if there's no serial number.
- Fix harmless warning.
- Allow the drop in MHz per hfa failure to be specified on the command line.
- Icarus - ignore HW errors in hash rate ... and fix detection of them
- Enable the hfa shed supported feature by default.
- Add to udev rules hfa devices for firmware writing.
- Remove ENV from hashfast udev rules.
- Add a --hfa-name command that allows one to specify the unique opname for a
hashfast device.
- Ava2 decode the voltage, get the temp_max
- Set the clock rate with a work restart instead of an init when changing to old
clocks for hfa
- Set opname on hfa devices without a serial number to a hex value based on time
to not overflow the field.
- Add op name to hfa API stats output if it exists.
- Set the actual op_name in hfa devices if cgminer is choosing it itself due to
it being invalid.
- Re-init an hfa device to its old data before setting up info structures as
their sizes may change.
- Remove the usb device whenever we do a running shutdown on hfa and do a
shutdown as the imitated reinit  to allow it to hotplug again.
- Reset opt hfa dfu boot after it's used.
- Comment out windows only transfer on hfa startup.
- Clean up structures unused in case of all failures in hfa detect common
- Clear all structures should we fail to hfa reset on adjusting clock on a
hotplug.
- Set master and copy cgpu hash clock rate for hfa when dropping it on a
restart.
- Set the master hfa clock speed to lower when shutting down a copy.
- Do a clear readbuf on any hfa reset in case the device  has not yet cleanly
shut down.
- Increase hfa fanspeed slightly more when it's rising in the optimal range than
falling.
- Always decrease hfa clock speed on a running shutdown and don't try sending an
init frame since it will be dropped regardless.
- Match hfa devices to old ones based on OP_NAME values before serial numbers if
possible.
- Read off the OP_NAME if it exists and is supported on hfa devices, setting it
to the device serial number or a timestamp if it is invalid.
- Updated hf protocol
- Check for an amount along with no error in hfa clear readbuf
- Hfa clear readbuf can return a nonsense amount when there's a return error so
ignore the amount.
- Running resets always cause a shutdown on hfa meaning the device will
disappear with modern firmware so always kill off the threads to allow
re-hotplugging.
- Reset the hfa hash clock rate to the old one if we find an old instance, only
setting the device id in hfa_prepare
- Keep the device_id on the original zombie thread for HFA in case of further
resets.
- Break out of hfa inherit if there is no device data.
- Inherit the hfa zombie instance after the device id has been allocated.
- The list_for_each_cgpu macro will dereference when there are no mining threads
yet.
- Make hfa hotplug inherit some parameters from a previous instance if the
serial number exists and is matching, avoiding dropping the clock on all
devices.
- Per device last getwork won't work if the device stops asking for work.
- Use the share_work_tdiff function in the driver watchdogs.
- Provide a helper function for determining time between valid share and getwork
per device.
- Store last_getwork time on a per-device basis.
- Limit the decrease of hfa clock rate on reset to the default clockrate.
- Base the hfa failure time on the current expected hashrate instead of a static
15 seconds.
- We shouldn't be trying to read from the hfa_send_shutdown function itself.
- Reset the icarus failing flag only when a valid nonce is found.
- Transferred value is corrupt on a NODEV error in usbutils.
- Set each miner thread last valid work just before starting its hash loop in
case there are delays at startup.
- Only memcopy *transferred data in usbutils if we have received only success or
a non-fatal error.
- Increase to 25 nonce ranges on icarus fail detect.
- Set icarus device fail time to be dependent on device speed to avoid falsely
detecting failure on slower AMU devices.
- Updated hf protocol header.
- Updated BE hf protocol header.
- Take into account shed cores on hfa devices when determining how many jobs to
send.
- Fix compilation error with two avalon types.
- Fix missing A1 files from distribution.
member
Activity: 117
Merit: 10
You're a funny man, Mr. Kolivas  Smiley

https://github.com/ckolivas/cgminer/pull/556
... meanwhile the person who sent the pull request ... isn't

Seriously - a pull request that puts code back into cgminer that's been removed on purpose?
Sigh.
http://www.youtube.com/watch?v=xECUrlnXCqk
I subscribe to the cgminer listserv and see you guys having to shoot these down pretty often. I just found that one too beautiful not to share with this thread.

..I really hope it's clear BIGKAT is not me...
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
You're a funny man, Mr. Kolivas  Smiley

https://github.com/ckolivas/cgminer/pull/556
... meanwhile the person who sent the pull request ... isn't

Seriously - a pull request that puts code back into cgminer that's been removed on purpose?
Sigh.
newbie
Activity: 6
Merit: 0
from time to time my PI hang upwith CG 4.0.0?

Hanging Pi?  Try adding the slub_debug=FP boot argument as described here:

http://projectklondike.org/how-to-run#rpi-freeze
This don't helped me. I have random freeze Sad
I have 3.10.25+ firmware and CG 4.0.0
member
Activity: 117
Merit: 10
Jump to: