OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[canford]

are we able to update the cgminer on the s1 or is it best to leave with the older build?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

[1542273167]

1542273167

[1542273167]

1542273167

[norgan]

are we able to update the cgminer on the s1 or is it best to leave with the older build?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

yeah thanks I know about that one. but I just wondered if the main fork that says it supports s1 could be used to keep it more up to date. (I just like to have the latest lol)

[canford]

are we able to update the cgminer on the s1 or is it best to leave with the older build?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

yeah thanks I know about that one. but I just wondered if the main fork that says it supports s1 could be used to keep it more up to date. (I just like to have the latest lol)

Not sure, I think you'd have to build the binary for the S1 yourself.  Kano might update github with an updated version, though I'm not aware of any S1-related improvements.  My AntMiners are all running 4.3.2a from Kano's build.

[Buchi-88]

Good day,

i have an existing problem with my configuration:

8 x Antminer U2 +
8 x BFx2 Bitfury

as soon as I both operate (. / configure - enable-bitfury - enable-icarus) remains Cgminer hang over again, and "watchdog" restarts the Raspberry new!

Once I only BFx2 Bitfury (. / Configure - enable-bitfury) used, runs the Cgminer 24/7.

Code:

0: BXM 0       :                         | 3.810G / 3.751Gh/s WU:52.9/m
 1: BXM 1       :                         | 2.394G / 3.187Gh/s WU:44.6/m
 2: BXM 2       :                         | 3.136G / 3.167Gh/s WU:44.6/m
 3: BXM 3       :                         | 2.990G / 3.006Gh/s WU:42.1/m
 4: BXM 4       :                         | 3.767G / 3.819Gh/s WU:53.7/m
 5: BXM 5       :                         | 3.894G / 3.919Gh/s WU:55.0/m
 6: BXM 6       :                         | 3.952G / 3.932Gh/s WU:55.5/m
 7: BXM 7       :                         | 3.804G / 3.867Gh/s WU:54.4/m
--------------------------------------------------------------------------------
 [2014-06-12 23:19:41] Zero length string passed to valid_hex from in util.c ini
tiate_stratum():2609
 [2014-06-12 23:19:41] Zero length string passed to valid_hex from in util.c ini
tiate_stratum():2609

Exactly the same is in the use of Antminer (. / Configure - enable-icarus)?

The problem is only with the simultaneous use, is it possibly there is a compatibility issue between the two drivers?

I had raised the issue before, but still wanted to thoroughly test!

On the Pi is the newest Kernel installed.

regards

[kano]

are we able to update the cgminer on the s1 or is it best to leave with the older build?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

yeah thanks I know about that one. but I just wondered if the main fork that says it supports s1 could be used to keep it more up to date. (I just like to have the latest lol)

I'll not update the S1 until I've sorted out the S2 issues - since I've no idea if those issues will affect the S1 also - and the last S1 release is pretty stable.

[mdude77]

are we able to update the cgminer on the s1 or is it best to leave with the older build?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

yeah thanks I know about that one. but I just wondered if the main fork that says it supports s1 could be used to keep it more up to date. (I just like to have the latest lol)

I'll not update the S1 until I've sorted out the S2 issues - since I've no idea if those issues will affect the S1 also - and the last S1 release is pretty stable.

S1 patch works great with p2pool.  So I don't think the issues affect the S1.

M

[norgan]

are we able to update the cgminer on the s1 or is it best to leave with the older build?

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

yeah thanks I know about that one. but I just wondered if the main fork that says it supports s1 could be used to keep it more up to date. (I just like to have the latest lol)

I'll not update the S1 until I've sorted out the S2 issues - since I've no idea if those issues will affect the S1 also - and the last S1 release is pretty stable.

S1 patch works great with p2pool.  So I don't think the issues affect the S1.

M

yeah there's nothing wrong with the current s1 build. I am just one of those who love to know I am running the very latest code. haha

[LARTAS]

Hi
My terraminer which is good
One CTA is showing high temperatures
CTA0 Metrics             High   Low          Avg
Core Temp 1 (°C)   91.14   63.74   77.77
Core Temp 2 (°C)   64.54   56            59.57
Ambient Temp (°C)   65.5           56          59.93
Fan Speed (RPM)   4782   4248   4,542
Pump Speed (RPM)   2990   2967   2,979

Who can help me? Before it get worst

[Micky25]

Hi
My terraminer which is good
One CTA is showing high temperatures
CTA0 Metrics             High   Low          Avg
Core Temp 1 (°C)   91.14   63.74   77.77
Core Temp 2 (°C)   64.54   56            59.57
Ambient Temp (°C)   65.5           56          59.93
Fan Speed (RPM)   4782   4248   4,542
Pump Speed (RPM)   2990   2967   2,979

Who can help me? Before it get worst

CoinTerra Support (CoinTerra)
May 13 15:23
The temps are operating in the expected range. It will not have an issue until 120C at which time it will shut itself off.
Regards,
Marshall

Comments: Hi, I have a very high difference on the temperatures of CTA0 and CTA1. Is there something I can do about this?
Thanks and best regards, Micky25
CTA0 Metrics High Low Avg
Core Temp 1 (°C) 108.49 76.79 87.35
Core Temp 2 (°C) 100.19 82.66 87.87
Ambient Temp (°C) 65.25 57.5 60.68
Fan Speed (RPM) 4122 3994 4,038
Pump Speed (RPM) 2991 2954 2,973
CTA1 Metrics High Low Avg
Core Temp 1 (°C) 64.23 55.89 60.13
Core Temp 2 (°C) 58.41 52.3 55.29
Ambient Temp (°C) 49.75 45.25 48.31
Fan Speed (RPM) 4225 4150 4,188
Pump Speed (RPM) 2952 2941 2,947

]

[-ck]

Comments: Hi, I have a very high difference on the temperatures of CTA0 and CTA1. Is there something I can do about this?

Unfortunately not.

[Taugeran]

im trying to get a MrTeal chili up and running on my BBB running some Onestringminer devices. alas when i plugged it in, it was recognized but once it was it started spewing "hex2bin scan failed" errors, as well as a single WARNING: firmware not recognized "mrteal fw version here" using Ver2.

0 hashrate is produced

this is cgminer 4.3.4 on a RevA6, running 5 OSM and [trying] 1 chili.

[detro]

Any idea when support for Rockminer r-box's will be available without having to hack up the code?

[-ck]

Any idea when support for Rockminer r-box's will be available without having to hack up the code?

Kano and I have both received rboxes to incorporate support into cgminer for, however the current code by the manufacturer for them trashes a whole lot of other cgminer driver code making the code not portable so it will take a while longer while we rewrite the driver.

EDIT: Experimental support is now in git.

[Xian01]

I've created an AntMinerS2 firmware.
...

Thank you for this. Most appreciated. Updated two of my S2's this morning and will report any issues.

Cheers.

[DeeBo]

Has anyone noticed improved hash rate by updating cgminer on the Antminer S1?  It looks like the latest firmware from Bitmain is running cgminer 3.12.  I just got mine recently so that's the version it shipped with and it's been running without issue right around 180GH/s each (I didn't overclock... my 750W power supply probably couldn't handle any extra load since I'm running 2 S1's off of it.)

I read your instructions and it seems pretty straight forward to update since I'm very familiar with Linux and ssh.  I'd just like to know what practical benefits I would get from updating.  I'm kind of leaning towards "if it ain't broke don't fix it" unless it would help me out in some way.

[norgan]

Has anyone noticed improved hash rate by updating cgminer on the Antminer S1?  It looks like the latest firmware from Bitmain is running cgminer 3.12.  I just got mine recently so that's the version it shipped with and it's been running without issue right around 180GH/s each (I didn't overclock... my 750W power supply probably couldn't handle any extra load since I'm running 2 S1's off of it.)

I read your instructions and it seems pretty straight forward to update since I'm very familiar with Linux and ssh.  I'd just like to know what practical benefits I would get from updating.  I'm kind of leaning towards "if it ain't broke don't fix it" unless it would help me out in some way.

As I understand it, the update was meant to fix efficiency issues while using the s1 on p2pool. I'm not sure it makes any difference on other pools. My reject rate is below 5% now with the update and a local p2pool node.

[Davefox]

Gents

Firstly i am a complete noob who has been bitten hard!!!

BUT all day today has fryed my head... completely shot.

Basicly i have got an avalon 2 100ghs single unit. I got a tplink mr3020 and tired to flash with new firmware and guess what bricked it. SO i thought bullocks i wanted a Raspberry PI anyway so an excuse to get one and have a play.

So today i get one from a local shop, get noobs installed and running, install a version of CGminer via GIT and following instructions. This version couldnt see the device. Found another thread where someone else had used a certain version of CGMINER. Installed this and it still wouldnt find it.

So found this thread installed lastest version. When compiled i used -enable-avalon2 which in the list it said enabled.

Some commands from pervious threads didnt seem to work in this version.

Sat looking at the readme file and well my head is beyond repair. I cant even find the basic commands to view usb device lists to see if its now visable.

Is there an idiots guide to install 4.3.5? and setup or am i beyond help lol.

[os2sam]

I cant even find the basic commands to view usb device lists to see if its now visable.

The "-n" argument displays all usb devices available and exits.  It is in the readme.

[-ck]

New release: Version 4.4.0, 16th June 2014

New driver warrants the minor version bump.


Human readable changelog:

- Rockminer R-Box support. This driver is based on the manufacturer provided driver but does NOT interfere with existing icarus devices such as the AMU, ANU, CMR2 etc. and it only takes the one parameter for overclocking,

Code:

--rock-freq <arg>   Set RockMiner frequency in MHz, range 125-500 (default: 270.0)

In my testing, this device usually only starts with hotplugging so after starting be patient while it gets going. This seems to take longer on windows. Also no frequency above 290 will be passed to the device and I didn't have much success running it higher than the default frequency, getting ~32GH.
- Fixed the failure to work with p2pool on the last release.
- Error messages on stratum connections are now displayed if something really borked has happened and the pool has informed you (such as invalid nonce2 length).
- Cointerra and minion fixes.
- Build fixes for some mips environments.


Full changelog

- Tidy unused rockminer variables
- Tidy rockminer defines
- Make rockminer driver compatible with other icarus drivers being present
- Import basic rbox driver
- minion - add optional (on) GPIO chip selection
- Clear the pool idle flag in the pool test thread
- CoreFmatch in cointerra should be a uint16
- Display error message if we receive one on share rejects
- Allow zero length strings to be passed to valid_hex
- delete unused roundl definition

[BenTuras]

To me it looks like a valuable change, given the waste of traffic that now occurs.

This is a gross exaggeration for any existing hardware that uses the bifury protocol on cgminer which produces only tiny amounts of traffic. Scaling device internal diff to pool diff will just make the hashrate calculation more and more inaccurate but not have any significant effect on performance or decrease CPU utilisation. Your OSM devices max out at 32GH which produces only 7 shares per second - even an RPi wouldn't register any measurable CPU usage processing those to filter out and send only the suitable shares to the pool. That's not to say the change won't eventually be required and welcome, just that it is not something I have time to work on at the moment since there is no benefit to existing miners.

"Any existing hardware". I am sure you don't know all existing hardware using Bitfury chips, so your "produces only tiny amounts of traffic" is wrong.
You are right when only looking at one OneStringMiner board, doing 32GH/s, but what about 384 of them in a cluster ? Do you now see why it would be beneficial ?

Given the fact that you don't react on my small code changes, I may assume they are correct ?