Author

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

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
BaB driver changes are:
Support for both V1 and V2 controller (automatically)
Automatic tuning of all the chips performance.
Redesign of nonce reply handling to remove all the problems I copied from chainminer (there were a few)
Dramatic drop in HW errors due to a few things: not corrupting the replies, ignoring raw E0 replies and of course (not new) checking the nonces more extensively
A bucket load of statistics in the API stats that will tell you what's going on with each chip
Included is a 5 minute history that is used for performance tuning (all fields that have "History" in the name)
Here's an example with a single 16 chip board:
Code:
   [STATS] => 0
   [ID] => BaB0
   [Elapsed] => 458
   [Calls] => 0
   [Wait] => 0.000000
   [Max] => 0.000000
   [Min] => 99999999.000000
   [Version] => 2
   [Chips] => 16
   [Boards] => 1
   [Banks] => 1
   [Chips Per Bank] => 0 16 0 0 0
   [Missing Chips Per Bank] => 0 0 0 0 0
   [Device Elapsed] => 459
   [History Enabled] => true
   [Chip History Limit] => 300
   [Nonces 0-15] => 322 286 260 268 283 288 296 263 278 258 312 306 283 257 257 238
   [Good 0-15] => 305 265 238 242 261 267 272 238 259 237 284 287 263 234 234 218
   [Bad 0-15] => 2 6 7 11 7 6 9 10 4 6 13 4 5 8 8 5
   [Conf 0-15] => 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b 0x1b
   [Fast 0-15] => 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54 54
   [Spie 0-15] => 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
   [Miso 0-15] => 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   [HW% 0-15] => 0.651 2.214 2.857 4.348 2.612 2.198 3.203 4.032 1.521 2.469 4.377 1.375 1.866 3.306 3.306 2.242
   [GHs 0-15] => 2.852 2.478 2.225 2.263 2.441 2.497 2.543 2.225 2.422 2.216 2.656 2.684 2.459 2.188 2.188 2.038
   [Sum GHs 0-15] => 38.376
   [Cont-Bad 0-15] => 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
   [Max-Bad 0-15] => 1 2 1 2 1 1 2 2 1 1 2 1 2 1 1 1
   [History Good 0-15] => 209 177 166 154 171 170 172 154 187 162 193 203 164 152 142 143
   [History Bad 0-15] => 1 4 1 4 7 4 6 9 3 6 8 3 5 6 7 4
   [History HW% 0-15] => 0.476 2.210 0.599 2.532 3.933 2.299 3.371 5.521 1.579 3.571 3.980 1.456 2.959 3.797 4.698 2.721
   [History GHs 0-15] => 2.998 2.521 2.370 2.198 2.435 2.436 2.457 2.198 2.664 2.321 2.758 2.902 2.335 2.163 2.026 2.040
   [Sum History GHs 0-15] => 38.821
   [Total History GHs] => 38.821
   [Total History HW%] => 2.789
   [History Speed 0.0 Dead] => 0
   [History Speed 0.8 V.Slow] => 0
   [History Speed 1.6 Slow] => 0
   [History Speed 2.2 OK] => 5
   [History Speed 2.8 Good] => 9
   [History Speed >2.8 Fast] => 2
   [History Dead] => None
   [History V.Slow] => None
   [Nonce Offset 0xff800000] => 2137
   [Nonce Offset 0x00000000] => 1407
   [Nonce Offset 0xffc00000] => 560
   [Discarded E0s] => 7777
   [Tested] => 4455
   [OK] => 4104
   [Total Tests] => 11835
   [Max Tests] => 13
   [Avg Tests] => 2.884
   [Untested] => 0
   [Work Links] => 6260
   [Work Processed Links] => 3396
   [Max Links] => 6
   [Max Processed Links] => 6
   [Total Work Links] => 31025
   [Avg Links] => 1.525
   [Avg Proc Links] => 0.827
   [Avg Work Links] => 7.560
   [Fail] => 111
   [Fail Total Tests] => 1600
   [Fail Avg Tests] => 14.414
   [Fail Work Links] => 950
   [Fail Total Work Links] => 950
   [Initial Ignored] => 240
   [Ign Total Tests] => 454
   [Ign Work Links] => 0
   [Ign Total Work Links] => 0
   [WFree Total] => 1024
   [WFree Count] => 859
   [Available Work] => 16
   [SPI Work] => 0
   [Chip Work] => 133
   [SFree Total] => 8
   [SFree Count] => 2
   [SPI Waiting] => 0
   [SPI Sent] => 5
   [RFree Total] => 256
   [RFree Count] => 256
   [Result Count] => 0
   [NFree Total] => 102400
   [NFree Used] => 2797
   [Delay Count] => 490
   [Delay Min] => 0.899001
   [Delay Max] => 1.019091
   [Delay Bands] => <0.5=0 <0.7=0 <0.9=242 <1.1=248 <1.3=0 <1.5=0 <1.7=0 <1.9=0 <2.1=0 <2.3=0 <2.5=0 >=2.7=0
   [Send Count] => 491
   [Send Total] => 24.646958
   [Send Avg] => 0.050
   [Send Min] => 0.045762
   [Send Max] => 0.086118
   [MaxSpeed] => 55
   [DefaultSpeed] => 54
   [MinSpeed] => 52
   [TuneUp] => 1.000000
   [TuneDown] => 10.000000
   [SPISpeed] => 1000000
   [SPIDelayuS] => 0
   [TransferDelayuS] => 0
The last 8 are the parameters you can supply with --bab-options to tune it (see ASIC-README)
I've run it fine with 1 board and with 6 boards (I have both)
I am still tuning it and it may need some adjustment to handle the large setups of 24 boards - but I've not had access to one since before the last lot of changes.
legendary
Activity: 1120
Merit: 1002
Yeah ! pretty good job , like usualy..   Cool thanx CK
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New release: Version 3.11.0, 25th January 2014

Finally a proper release for hashfast devices and a substantially updated bab driver.


Human readable changelog:

- A proper working hashfast driver tested working on a real device, including the windows version.
- Substantially updated BAB driver courtesy of Kano. Hopefully he can give us a summary of the changes there.
- Generic fixes for the reconnect bug on btcguild (unsure if other issues still exist).
- Work is discarded on a stratum reconnect message from the pool now (as btcguild uses) to avoid working on invalid work on switching URLs.
- Fixed the stuck line at the top of the log window.
- Message about block change detected no longer mentions longpoll.
- API now has a field "Last getwork" in summary which can be used to see that we are still getting work from pools. This is useful if you are trying to determine if a device is dead for device reasons or simply isn't getting work from any pools. It uses the same numbering in seconds with the "Last Valid Work" returned in the device API. If "Last getwork" is not incrementing, there is no work for any devices.
- Added a --nfu-bits command to allow you to set the clock speed on nanofury/icefury usb sticks. Note that the default was 54 so is now 50 to be in keeping with USB2 power limit standards. This means IT WILL BE SLOWER compared to 3.10.0 unless you change it with this option back to 54. The driver is otherwise unchanged so any other differences you see are pure variance.
- Threads names have been changed so they will show up with different, consistent names in your process manager of choice.
- Building will now not include libbitfury on every configuration unnecessarily.
- The crash on device removal has been fixed.
- Fixes for lean configurations that failed to build.

- Hashfast driver changes:
-- Should be more robust with respect to initialisation and dropouts
-- If the device stops returning shares, cgminer will reset the device, and if it cannot, it will drop it, which usually allows it to be re-hotplugged again.
-- If a device needs to be reset for not returning shares, and the clockspeed is still overclocked, cgminer will lower the clocks further on every reset.
-- Devices will be throttled if they reach 85 degrees. With water cooling they usually drop in temperature very rapidly. This can be configured with --hfa-temp-overheat
-- Hashrate displayed will be based on valid shares returned so should more accurately represent what the pool will see you hashing at. It will look very unstable initially. Earlier boards do have some loss so the previously displayed hashrate was always over. You can compare the total hashes estimated by this as "Calc hashcount" to compare with "Raw hashcount" the device has worked on in the API stats to see how they differ.
-- Max temp on screen will not show if it's an obvious error showing something like 512
-- The API will show board temperatures
-- Windows builds work Tongue
-- Babyjets show up as HFB while Sierras show up as HFS. Custom devices will come up with the generic HFA name. Note that if you are trying to select them with the --usb command, they are all seen as HFA due to the fact that cgminer can only tell them apart after they have been initialised and running.


Full changelog:

- Add hashfast documentation to ASIC README
- Support the variable HFA naming throughout the driver notices.
- Set the global hfa hash clock rate to equal the lowest if we are lowering it
for a device reset since it may be re-hotplugged after failing reset.
- Decrease the hfa clock rate if it is overclocked and we have had to try
resetting it.
- Put a sanity check on the measured temperature in the hfa driver for obviously
wrong values.
- Avoid calling applog from within hfa statline before to avoid a deadlock.
- Add throttling control to hfa driver, configurable at command line, nominally
set to 85 degrees.
- Reset hfa device if no valid hashes are seen for 1 minute from the last work.
- Store when the last getwork was retrieved and display it in the API summary.
- bab - also report dead chip count screen
- Count share based hashes in the hfa driver with the device diff to get more
frequent updates.
- Only count 2/3 of the accumulated hashes on each pass through the hfa scan
work loop to smooth out displayed hashrate.
- bab add total history HW% to API stats
- Test valid nonces in the hashfast driver allowing us to check against the
target when trying to submit them.
- No point casting a double to a uint64
- Convert the hfa hashmeter to one based on successful share return and display
the raw and calculated hash totals in the API.
- bab - remove libbitfury dependency since it requires USB
- Add description to hfa hash clock command.
- Add hfa board temperatures to API output.
- Wait for up to 0.5 seconds in the hashfast scanwork loop if no jobs are
required.
- Label HFA devices as B or S when their configuration matches babyjet or
sierra.
- Fix libbitfury being compiled in always by mistake.
- bab - spelling
- Add bab-options
- bab - tune the chip speed based on error rates
- bab record/report spie and miso errors
- Win32 falsely comes up as big endian pulling in the wrong hf protocol header.
- Remove unused components in hashfast driver.
- Check in all usb communication places for hashfast driver that the device
still exists.
- Do not send a usb reset on a usb read pipe error.
- Don't replace usb pipe errors with the pipe reset return code.
- Updated hf protocol header.
- The search for extra nonce is not worth performing in the hashfast driver.
- Add core address to hfa parse nonce debugging.
- Retry sending a frame once if it has failed in hfa_send_frame
- Add extra hfa usb init errors.
- Quiet now unused variable warning in hfa detect.
- Remove unused variable.
- Add board temperature to hfa debug
- Make submit_tested_work return a bool about whether it meets the work target
or not.
- Provide a helper function for determining dev runtime and use it in the
hashmeters used.
- Look for hfa usb init header for 2 seconds, then resend the init twice more
before failing.
- Really only set up the hfa crc table once.
- Generically increase the queue if we are mining on a pool without local work
generation each time we run out of work.
- Change new block detection message since longpoll is rarely relevant today.
- Change the default clockspeed bits on nanofury devices to 50 and add a command
line option to allow it to be changed.
- Use unused line at the top of the log window which often gets stuck
unchanging.
- Clear pool work on a stratum reconnect message.
- bab record/report spie and miso errors
- bab - cleanup old work for dead chips also
- bab add avg fail tests to API stats
- bab report bank/board/chip for dead and v.slow chips
- bab process all nonce replies per chip together
- bab reduce work delays
- bab record the number of E0s discarded
- bab - modified result parsing
- bab restore removed unused flag
- configure - correct minion name
- bab only scan valid nonce offsets
- bab record continuous (and max) bad nonces
- bab display Banks/Boards/Chips in the device window
- Modify thread naming to make them easier to identify
- bab reduce the work send delay
- bab remove results polling
- bab report SPI wait in seconds
- bab report missing chips at start and API
- bab ensure there's enough space for the nonce reply
- bab correct stats 'Send Max'
- bab allow long enough wait on ioctl() per board
- bab more I/O stats
- api.c 2014
- api allow any size stats data
- bab add processed links which excludes expired links skipped
- bab report chips per bank, hw% and ghs per chip
- bab lock access to new_nonces to ensure correct reporting
- bab report V2 banks/boards during initialisation
- bab expire chip work
- bab use only k_lists and make work handling more refined
- klist - allow adding to tail
- bab remove old unused #define
- bab correct for master git
- correct klist reallocs
- klist lists for bab
- api.c correct DEVICECODE and ordering
- Maxchips should be 384 (16 chips/board 24 boards/controller)
- bab more detailed stats and delay less when waiting for a buffer
- api add data type AVG float 3 decimal
- bab - add V2 detect with bug fix in detect
- api.c set the actual version number to 3.0
- API V3.0 unlimited socket reply size
- README update --usb
- Check for loss of device in usb read before any other code on the usbdev
- Change stratum strings under stratum_lock in reconnect and free old strings.
- Add mcp2210 compilation to want_libbitfury configs.
- Fix HF driver typo.
newbie
Activity: 4
Merit: 0
I am having trouble getting cgminer to even run with a 7990.

Thread with details: https://litecointalk.org/index.php?topic=13980.0
hero member
Activity: 546
Merit: 500
Quote
This reason alone made me give up windoze. Not to mention the frequent restarts because of updates .Set up a raspberry pi changed some of the instructions to compile newest version and been happily hashing since December with no down time. If you don"t like soldering then save some money and skip the lcd.
 
If we were smart we would have had updates turned off and set to manual mode to reduce accidental restarts. I'm sure Linux has its own way of updates that can tick you off. I only knew when there was updates when it was a new release or installed a new program when I messed with Linux. Windows at least tries to keep it up front. I still wish it brought current programs back up and then locked the pc with some sort of notification about it.

Btw you do realize the btc guild problem is probably both Linux and windows alike.
hero member
Activity: 812
Merit: 502
Anyone knows why all of a sudden the CGMiner on a Jupiter stopped displaying the usual lines: [2014-01-25 02:33:12] Accepted 227772c5 Diff 1.9K/1024 KnC 0 pool 0

It's not Quiet mode. When I press D it quickly goes to a blank screen and then it reverts back. It happened on 5 machines with 3.8.1 and 3.9.0
I try to turn Quiet mode blindly by doing D/Q a couple of times, but nothing.

Any ideas?

newbie
Activity: 11
Merit: 0
Yes, btcguild is a separate bug, sorry. BTCguild is the only pool that uses the redirect feature in stratum which was added blindly a long time ago when stratum support was first added and no pool used it. Cgminer's implementation is unfortunately buggy and the only workaround till I can fix it is to connect directly to btcguild's redirected url directly or use a different pool to avoid the crash.

I hope you figure this out quickly Wink .

 I thought this was a hardware issue when I first saw this since my drillbit devices were that last thing to show errors before windows tried to close it.

I need's my btcGuild.
Been looking into it. I was unable to reproduce this at all locally so perhaps it's better or perhaps I just don't have the right combo of hashrate and circumstances. I've done some generic changes to make it more robust. There may well be a second issue with btcg related to the frequent restarts it's had lately but I have no firm leads on that.

I'm set for level 16 in load balance mode with about 25Ghashes pointed at it. If you have it right, it shows up after less than 30 minutes. I was trying to watch a flash video when I last noticed my computer getting chunky which eventually led to me trying to fast disable btcguild ,but it was too late and then to get stability back I ended up voluntarily rebooting my system (pc was looking to update my display , network drivers and .net service packs, so I needed to anyway) Picture below is not from most recent event but how I found it after leaving home for a few days not knowing this would happen.
http://i40.tinypic.com/fms7xh.jpg
I hope that gives you something to look into and hope it has nothing to do with pm to check winsock headers having problems with compiling.

This reason alone made me give up windoze. Not to mention the frequent restarts because of updates .Set up a raspberry pi changed some of the instructions to compile newest version and been happily hashing since December with no down time. If you don"t like soldering then save some money and skip the lcd.

http://learn.adafruit.com/piminer-raspberry-pi-bitcoin-miner/

Cheers,  Wink
hero member
Activity: 546
Merit: 500
Yeah that was my problem libpthread "isn't" installed, you need to uninstall that version and install it via shell. That was one error I googled and edited in the windows compile file. After that I'm still in the dark waiting for ckolivias to check his pm's and see what the hecks going on with the make. We don't need two people getting eaten out by minGW user email lists.

Quote
**************************************************************************************
*Make sure you have the right pThreads version *
**************************************************************************************
You might need to install a diferent version of it to compile I needed
 mingw-get install mingw32-pthreads-w32-dev


sr. member
Activity: 332
Merit: 250
--enable-hashfast dies when checking c compiler
-enable-hashfast dies when checking for cross compiling
default CFLAGS="-O2 -msse2" ./configure dies when it thinks libpthread is not installed.  But I have all libpthread packages installed in MinGW, so this baffles me.

That's why I am asking for someone who already can successfully build a windows build to do so with --enable-hashfast, because I have spent much time and effort in attempting to do so and have not been successful

hero member
Activity: 546
Merit: 500
Is it giving an error when it crashes? Other than trying changing it to --enable-hashfast instead of hashfast-enable make sure your packages are right and that the version your compiling has hashfast built in. I haven't successfully gotten cgminer to compile but you can read my edited howto on my github version that I tried to use to solve a problem with winsock errors popping up on being made with "make"  here https://github.com/techman05/cgminer .

Hope that helps
sr. member
Activity: 332
Merit: 250
Can someone please build a windows version with hashfast-enable?  I have been unable to build it following the windows build instructions, it keeps crashing when I try to ./configure.
hero member
Activity: 546
Merit: 500
Yes, btcguild is a separate bug, sorry. BTCguild is the only pool that uses the redirect feature in stratum which was added blindly a long time ago when stratum support was first added and no pool used it. Cgminer's implementation is unfortunately buggy and the only workaround till I can fix it is to connect directly to btcguild's redirected url directly or use a different pool to avoid the crash.

I hope you figure this out quickly Wink .

 I thought this was a hardware issue when I first saw this since my drillbit devices were that last thing to show errors before windows tried to close it.

I need's my btcGuild.
Been looking into it. I was unable to reproduce this at all locally so perhaps it's better or perhaps I just don't have the right combo of hashrate and circumstances. I've done some generic changes to make it more robust. There may well be a second issue with btcg related to the frequent restarts it's had lately but I have no firm leads on that.

I'm set for level 16 in load balance mode with about 25Ghashes pointed at it. If you have it right, it shows up after less than 30 minutes. I was trying to watch a flash video when I last noticed my computer getting chunky which eventually led to me trying to fast disable btcguild ,but it was too late and then to get stability back I ended up voluntarily rebooting my system (pc was looking to update my display , network drivers and .net service packs, so I needed to anyway) Picture below is not from most recent event but how I found it after leaving home for a few days not knowing this would happen.

I hope that gives you something to look into and hope it has nothing to do with pm to check winsock headers having problems with compiling.
member
Activity: 115
Merit: 10
It seems there is also a problem with stratum+tcp://stratum.triplemining.com:3334 now. It is always marked as dead. The old version is running on another machine - there the pool is alive. Restart doesn't change anything on one of the machines.
member
Activity: 115
Merit: 10
Been looking into it. I was unable to reproduce this at all locally so perhaps it's better or perhaps I just don't have the right combo of hashrate and circumstances. I've done some generic changes to make it more robust. There may well be a second issue with btcg related to the frequent restarts it's had lately but I have no firm leads on that.

Thanks for checking. Maybe it helps checking the issue with a p2pool:
Quote
stratum+tcp://elizium.name:9332
start - looking for devices - coredump

I noticed --nfy-bits - thanks :-)
newbie
Activity: 2
Merit: 0
libcurl-4.dll is missing from my computer, this is the error message I keep getting, when tryin to open the cgminer.exe
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Yes, btcguild is a separate bug, sorry. BTCguild is the only pool that uses the redirect feature in stratum which was added blindly a long time ago when stratum support was first added and no pool used it. Cgminer's implementation is unfortunately buggy and the only workaround till I can fix it is to connect directly to btcguild's redirected url directly or use a different pool to avoid the crash.

I hope you figure this out quickly Wink .

 I thought this was a hardware issue when I first saw this since my drillbit devices were that last thing to show errors before windows tried to close it.

I need's my btcGuild.
Been looking into it. I was unable to reproduce this at all locally so perhaps it's better or perhaps I just don't have the right combo of hashrate and circumstances. I've done some generic changes to make it more robust. There may well be a second issue with btcg related to the frequent restarts it's had lately but I have no firm leads on that.
newbie
Activity: 3
Merit: 0
The php function I'm using is from the MinePeon OS for the Raspberry Pi and I just used it as it worked and I managed to get all other functions to work just this 'zero' that caused the problem.
https://github.com/MineForeman/minepeon-base/blob/master/http/inc/miner.inc.php

AddPool works fine using:
cgminer("addpool",$poolAddress . "," . $poolUser . "," . $poolPass);


EDIT: GOT IT!
cgminer('zero','all,true');
Returns "[Msg] => ZeroedAllstatswithsummary" and has indeed reset the stats to '0'

I was misreading the "|" as if it was asking for "zero,all","true" but instead its the other way around "zero","all,true" Roll Eyes
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Hi, I'm having trouble getting one of the API commands to work..
...
No idea what that PHP you are using is, but as the API-README says, the zero command is:

zero|Which,true/false

i.e.
zero|all,true

or JSON
{"command":"zero","parameter":"all,true"}

Edit: I will add that it looks exactly the same as:
addpool, poolpriority, poolquota, setconfig, pgaset, ascset
So I guess none of those worked for you either
legendary
Activity: 1946
Merit: 1035
What is a triple equal sign mean? I would have thought if(client==false) then return a 0 or a 1 and then another statement to check the return with a message if you get a failed to start error since in the code you gave you don't have a message specified.

Tripe equal in PHP: operands must be equal and of the same type (rtfm)
newbie
Activity: 3
Merit: 0
=== is the same as == but also compares the type as well value, and must be the same to return 1 otherwise it'll return 0 regardless if the value is the same.


"cgminer(zero)" returns "[Msg] => Missingzeroparameters" Obviously Smiley
"cgminer(zero,all)" returns "[Msg] => Missingparameter:true/false"

But adding the true/false parameter still returns the same Msg..
"cgminer(zero,all,false)" returns "[Msg] => Missingparameter:true/false"

I've gone through pretty much every other API command and they all seem to work but for the life of me this one just won't work Huh
Jump to: