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

This is a bitcoin miner. All altcoin variants are forks.

Does this now have native Zeus support or do we still need to use the fork from dmaxl? Can't find suitable information on this.

Yeah i got your point
Something like
#ifndef WIN32
 pthread_tryjoin_np
#else
...
#endif
What about it?
PS: if last two commits do same job then this is not needed of course
 

Yes I know it works for Linux but many platforms don't have it implemented so I needed something cross platform hence the change to the code. The pain of writing cross platform software...

Hello Con,

pthread_tryjoin_np was working great for last two days or so. Cgminer starts up for a sec or two:)

However you are removing it due to:
---------------------
Remove the use of the pthread_tryjoin_np which is currently unimplemented on many platforms
---------------------

If you can make it #ifdef where this is implemented will be great.

PS: i have not tested two latest commits after 4.2.2 release yet

Best

How do I start mining?

New release: Version 4.4.2, 17th July 2014

A stable/bugfix/driver update release for accumulated issues while I was away.


Human readable changelog:

- Fixed an issue where some types of file configuration parameters (like hfa-fan) would be lost when write config was chosen from the menu.
- Fixed a crash that could occur on trying to connect to a stratum server.
- Fixed write config file crashing when bitfury was compiled in.
- Fixed the "Failed to sem_timedwait" issue seen by some people.
- Fixed failover not working if one of the initial pools never responded.
- Fixed a corruption when solo mining (ALL SOLO MINERS URGED TO UPGRADE!)
- Rbox now accepts frequencies up to 400.
- Spondoolies driver updates including SP30 driver.
- Minion driver updates.
- Avalon2 driver updates.
- Fixed broken S1 compilation.
- Other low level fixes.


Full changelog:

- Fix processarg parameters loaded from a config file not being saveable
- We only use the jansson in our source tree so no need for special case
handling of older versions
- Upgrade jansson to 2.6
- Only clear sockbuf if it's been allocated
- Fix missing osm-led-mode support in write config
- Deal with nanosecond overflow in both directions on both addition and
subtration of timespecs
- Rename sp10 driver internally from spondoolies to sp10
- minion - add a 2nd (optional - disabled) reset test
- production stats added, reset queue added
- minion - correct led ghs2 choice
- minion - correct ghs2 display
- minion - reset the led counter when doing a chip RSTN full reset
- minion - don't reset the led counter for an SPI reset
- minion - led per chip and use all time average
- minion - report spi error counts and settings in stats
- minion - undeclared fix
- minion - chip power cycle option
- minion - record 0xff error history and reduce screen output
- minion - reset on result or fifo 0xff
- minion - clarify the 0 value of spireset
- minion - make SPI reset more configurable
- minion - make the SPI reset ms sleep a parameter and API settable
- sp10 sensors
- sp30
- minion - led+more api setting
- Avoid blocking all pool testing if one pool fails to ever init
- There is no point storing the hints addrinfo in struct pool
- minion - 'reset' SPI when getting errors
- initialise more pool values in benchmark
- minion - auto adjust freq
- merge upstream frequency changes
- icarus - timing history in its own function
- rbox - add lotsa stats, tidy up a bit more
- Fix an off-by-one.
- icarus - detect stat should be LOG_DEBUG
- icarus - tidy up rbox code, remove statics, and add rocketbox
- minion - do an early reset to clear the chip status
- minion - use descriptive names for the list types
- Avalon2: automatic adjust fan speed, using crc16 on job_id compare, turn on
the led by API, detect twice when start, remember the last stratum message
increase the hashrate, add cutoff option
- fix AntS1 breakages from AntS2 changes
- minion - disable dup nonce check
- minion - add an ioseq number for each ioctl to simplify work ordering
- minion - redo old work expiry based on txrx order
- minion - more work stats, minimise queued work, free flushed queued work
- minion - allow resetting a chip via the API
- minion - correct 'WQue Count' in stats
- minion - delay after reset, reset history also, add dups to api stats
- noncedup - give access to the internal stats
- minion - increase reset to 75%
- minion - dup checking, disable reread by default and extra ioctl debugging
- minion - always check the chip queue before queuing new work

It's very much dependent on the hardware. Some stuff by design has 10% errors in a harmless way (any bitfury). Most hardware designs are under 2% which is fine.

Thank you ckolivas, I though something was wrong with the hardware.

When is considered the hardware errors rate too much ?

Looks okay to me. 2 hours at 909 shares per min is ~110k shares and you have ~900 errors total.

Any way to troubleshoot this hardware errors?
I think is too much for only 2 hours.
I am using 2 R-BOX connected to the USB ports on the laptop with Bitcoin-0.9.2.1 and cgminer-4.4.1

 [2014-07-16 19:37:58]
Summary of runtime statistics:

 [2014-07-16 19:37:58] Started at [2014-07-16 16:52:19]
 [2014-07-16 19:37:58] Pool: http://localhost:8332
 [2014-07-16 19:37:58] Runtime: 2 hrs : 45 mins : 39 secs
 [2014-07-16 19:37:58] Average hashrate: 65121.3 Mhash/s
 [2014-07-16 19:37:58] Solved blocks: 0
 [2014-07-16 19:37:58] Best share difficulty: 4.43M
 [2014-07-16 19:37:58] Share submissions: 0
 [2014-07-16 19:37:58] Accepted shares: 0
 [2014-07-16 19:37:58] Rejected shares: 0
 [2014-07-16 19:37:58] Accepted difficulty shares: 0
 [2014-07-16 19:37:58] Rejected difficulty shares: 0
 [2014-07-16 19:37:58] Hardware errors: 850
 [2014-07-16 19:37:58] Utility (accepted shares / min): 0.00/min
 [2014-07-16 19:37:58] Work Utility (diff1 shares solved / min): 909.83/min
 [2014-07-16 19:37:58] Stale submissions discarded due to new blocks: 0
 [2014-07-16 19:37:58] Unable to get work from server occasions: 0
 [2014-07-16 19:37:58] Work items generated locally: 156744
 [2014-07-16 19:37:58] Submitting work remotely delay occasions: 0
 [2014-07-16 19:37:58] New blocks detected on network: 14
 [2014-07-16 19:37:58] Summary of per device statistics:
 [2014-07-16 19:37:58] LIN0 (5s):38.14G (avg):32.55Gh/s | A:0 R:0 HW:822 WU:454.8/m
 [2014-07-16 19:37:58] LIN1 (5s):34.35G (avg):32.59Gh/s | A:0 R:0 HW:28 WU:455.4/m
 [2014-07-16 19:37:58]

Currently, mainline cgminer only supports R-Box

Any support for the Rockminer "Rocket" RK-Box?

I asked the vendor and they say is a USB ASIC like the R-BOX and it use cgminer for software but I will no buy it if no confirmation here that it is supported.

Read in a post back that Kano was working on it.

To be honest, I never thought it was a bug.
I thought it would be something weird with my hubs, since it never happened before.
I posted here seeking some solution, never thought about it as a bug.
But, I'm glad to help, every time I can.
And if you ever need to test something out, just drop me a message and I'll compile it with no problem at all.
BTW, any suggestion to find out why I can't manage to have U1 recognized if I don't plug a BE?

Thank you again!

No, thank you for the bug report and for reporting back. 

Hey ckolivas!

12h have passed without any crash.
Just the usual incidents caused by the hubs, but nothing new.
I still have to try to run the U1's without the BE in this version but I'll wait for when my new hubs arrive.

Thank you very much!!

Yes indeed you can, though cointerra pushed me some driver updates that seem to depend on a firmware update that hasn't happened which means the last good working mainline cgminer for it was 4.3.5.

Mind you I've had all sorts of ever increasing hardware problems with my terraminer too and it is now completely offline.

I haven't any 3.0 ports in this machine, yet so I guess I'm safe.
I will , thanks!


Compiled fine and so far so good, but I'll only be able to confirm tomorrow or so.
Sometimes it only lasted 2h, sometimes about 9h.

But anyway, thank you very much, I'll keep you updated.

I am having issues with my beaglebone for the terraminer.  Are you saying that I can plug each board into a PC with a USB cable and then run cgminer on my PC to get it working again?  If so, that would be an easier solution than trying to replace the beaglebone.

I really like the Gearmo USB 3.0 hubs.