OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 38.

Buchi-88

legendary

Activity: 3990

Merit: 2695

Anyone know about this errors?

Quote

cgminer version 4.3.3 - Started: [2015-07-28 18:49:24]
--------------------------------------------------------------------------------
(5s):12.87G (1m):12.78G (5m):12.56G (15m):11.84G (avg):12.65Gh/s
A:7496 R:56 HW:0 WU:179.7/m
Connected to multiple pools with block change notify
Block: 9135be29... Diff:1.24M Started: [19:32:22] Best share: 8.88K
--------------------------------------------------------------------------------
USB management Pool management Settings Display options Quit
0: BXM 0 : | 4.393G / 4.402Gh/s WU:61.9/m
2: BXM 2 : | 4.305G / 4.203Gh/s WU:60.6/m
3: BXM 3 : | 4.138G / 3.983Gh/s WU:57.9/m
--------------------------------------------------------------------------------
[2015-07-28 19:21:12] BXM 1: SPI RX error 0, read 0 of 81
[2015-07-28 19:21:12] BXM 1 failure, disabling!
[2015-07-28 19:21:12] BXM 1: SPI TX error -4, sent 0 of 11
[2015-07-28 19:21:12] BXM 1: SPI TX error -4, sent 0 of 12
[2015-07-28 19:21:18] BXM 0: SPI RX error -7, read 0 of 8
[2015-07-28 19:21:19] BXM 0: SPI RX error -7, read 0 of 9

Then the miner restart?

tkalfaoglu

newbie

Activity: 25

Merit: 0

On a fresh fedora 22 install, I compiled cgminer with -enable-icarus
and plugged in two antiminer U3's.

It "appears" to work because I can see the hashing status of the two devices, but it also dumps lots of errors like this:

ftdi_sio ttyUSB0: Unable to write latency timer: -71
ftdi_sio ttyUSB0: Unable to read latency timer: -71
ftdi_sio ttyUSB0: Unable to write latency timer: -71
and it keeps repeating..

What can I do to fix this?

Thanks, -t

toptek

legendary

Activity: 1274

Merit: 1000

Quote from: luthermarcus on July 26, 2015, 10:05:22 PM

Quote from: toptek on July 26, 2015, 12:09:37 PM

Quote from: kano on July 24, 2015, 06:36:54 PM

Quote from: luthermarcus on July 23, 2015, 11:59:54 PM

Hey could you add support for S5 like you did for s3? Roll Eyes

Already working on it.

nice

I hope you actually fix it , so far you have once you do it . The new bitmain Firmware worked ok for me till today on one of my S5, then for no good reason the speed started dropping then one of the blades just stopped and displayed

-------- from zeros and No X es .

i rebooted it, no go . so i reset it to defaults, no go, finally i was forced to go back to one of the Firmware modified by Smit1237 with out #xnsub support sense that seems to do strange things to my S5's on some pools . it is working like it should be now with Smit1237 firmware but not with the new released firmware from bitmain Sad

. that did work well for a few days then to day for no reason it did , what i just said .

I agree the s5 does work different on each pool. I just want it fixed for p2pool becuase it hash drops from 1200 to 800-900. It works good with some pools and like you say others it displays x for no good reason and starts to act up p2pool being one of them.

I notice that to on p2pool you log on it, then about 10 mins later it caps at 800 or 900 GS on my S5s on my S3 even before the fix had no issue there . Or i would be using it over antpool any day .

luthermarcus

full member

Activity: 213

Merit: 100

Quote from: toptek on July 26, 2015, 12:09:37 PM

Quote from: kano on July 24, 2015, 06:36:54 PM

Quote from: luthermarcus on July 23, 2015, 11:59:54 PM

Hey could you add support for S5 like you did for s3? Roll Eyes

Already working on it.

nice

I hope you actually fix it , so far you have once you do it . The new bitmain Firmware worked ok for me till today on one of my S5, then for no good reason the speed started dropping then one of the blades just stopped and displayed

-------- from zeros and No X es .

i rebooted it, no go . so i reset it to defaults, no go, finally i was forced to go back to one of the Firmware modified by Smit1237 with out #xnsub support sense that seems to do strange things to my S5's on some pools . it is working like it should be now with Smit1237 firmware but not with the new released firmware from bitmain Sad

. that did work well for a few days then to day for no reason it did , what i just said .

I agree the s5 does work different on each pool. I just want it fixed for p2pool becuase it hash drops from 1200 to 800-900. It works good with some pools and like you say others it displays x for no good reason and starts to act up p2pool being one of them.

toptek

legendary

Activity: 1274

Merit: 1000

Quote from: kano on July 24, 2015, 06:36:54 PM

Quote from: luthermarcus on July 23, 2015, 11:59:54 PM

Hey could you add support for S5 like you did for s3? Roll Eyes

Already working on it.

nice

I hope you actually fix it , so far you have once you do it . The new bitmain Firmware worked ok for me till today on one of my S5, then for no good reason the speed started dropping then one of the blades just stopped and displayed

-------- from zeros and No X es .

i rebooted it, no go . so i reset it to defaults, no go, finally i was forced to go back to one of the Firmware modified by Smit1237 with out #xnsub support sense that seems to do strange things to my S5's on some pools . it is working like it should be now with Smit1237 firmware but not with the new released firmware from bitmain Sad

. that did work well for a few days then to day for no reason it did , what i just said .

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: luthermarcus on July 23, 2015, 11:59:54 PM

Hey could you add support for S5 like you did for s3? Roll Eyes

Already working on it.

Mikestang

legendary

Activity: 1274

Merit: 1000

Quote from: luthermarcus on July 23, 2015, 11:59:54 PM

Hey could you add support for S5 like you did for s3? Roll Eyes

If you pay for it I bet they'd be happy to. Tongue

luthermarcus

full member

Activity: 213

Merit: 100

Hey could you add support for S5 like you did for s3? Roll Eyes

TheRealSteve

hero member

Activity: 686

Merit: 500

FUN > ROI

If the issue is largely with reconnects to pools that start out with a too low diff for the device, and for whatever reason there's no minimum vardiff that can be set on the pool interface, see if the pool used accepts the --suggest-diff parameter? If it's a proxy type service, the end-user doesn't even have to worry about setting that up.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: NiceHashSupport on July 20, 2015, 04:12:31 AM

Quote from: -ck on July 19, 2015, 04:45:17 PM

Quote from: kenshirothefist on July 17, 2015, 11:32:39 AM

ckolivas, could you please pull this pull request: https://github.com/ckolivas/cgminer/pull/679? This is a small but annoying bug, causing small loss of performance (in terms of accounted shares on pool) when changing difficulty - especially when using vardiff or often diff changing (when switching from low to high diff miner immediately sends high diff while is should/could still send low diff and pool might wrongly account for shares). Thanks!

I will look at it eventually; the original behaviour was chosen to be robust with dodgy pools' handling of diff so it was actually there intentionally. Saying you lose a lot of shares is a gross exaggeration as most decent pools change diff only once or twice ever and that many shares will not even amount to a single satoshi over a lifetime of mining.

A robust implementation would be, if the miner was still sending low diff shares when pool requested higher diff. That way you may get some % of rejects, but would work without speed loss on pools that don't implement diff change correctly and on pools that do.

Of course, it is not a big loss, a percent or two on a pool that does vardiff moderately. But I cannot agree with satoshi claim. You forgot about reconnects (whenever miner goes offline and comes back, switches to another pool etc). There is a lot more lost than a single satoshi. Besides, according to how simple the fix is, it is also totally non-understandable to us, why it is not pulled yet (or taken look at it).

And, say this to miners; there is a patch waiting for cgminer that improves performance but "I will look at it eventually".

No, you are speaking ONLY of your pool/proxy/service which does lots of reconnects. You are biased towards your pool whereas I'm biased towards normal pools. Nonetheless the patch has been pulled into master git but it may be a very long time before a new cgminer release comes out since there's virtually nothing happening anywhere with regards to hardware till the next generation comes around.

NiceHashSupport

hero member

Activity: 588

Merit: 501

Quote from: -ck on July 19, 2015, 04:45:17 PM

Quote from: kenshirothefist on July 17, 2015, 11:32:39 AM

ckolivas, could you please pull this pull request: https://github.com/ckolivas/cgminer/pull/679? This is a small but annoying bug, causing small loss of performance (in terms of accounted shares on pool) when changing difficulty - especially when using vardiff or often diff changing (when switching from low to high diff miner immediately sends high diff while is should/could still send low diff and pool might wrongly account for shares). Thanks!

I will look at it eventually; the original behaviour was chosen to be robust with dodgy pools' handling of diff so it was actually there intentionally. Saying you lose a lot of shares is a gross exaggeration as most decent pools change diff only once or twice ever and that many shares will not even amount to a single satoshi over a lifetime of mining.

A robust implementation would be, if the miner was still sending low diff shares when pool requested higher diff. That way you may get some % of rejects, but would work without speed loss on pools that don't implement diff change correctly and on pools that do.

Of course, it is not a big loss, a percent or two on a pool that does vardiff moderately. But I cannot agree with satoshi claim. You forgot about reconnects (whenever miner goes offline and comes back, switches to another pool etc). There is a lot more lost than a single satoshi. Besides, according to how simple the fix is, it is also totally non-understandable to us, why it is not pulled yet (or taken look at it).

And, say this to miners; there is a patch waiting for cgminer that improves performance but "I will look at it eventually".

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: kenshirothefist on July 17, 2015, 11:32:39 AM

ckolivas, could you please pull this pull request: https://github.com/ckolivas/cgminer/pull/679? This is a small but annoying bug, causing small loss of performance (in terms of accounted shares on pool) when changing difficulty - especially when using vardiff or often diff changing (when switching from low to high diff miner immediately sends high diff while is should/could still send low diff and pool might wrongly account for shares). Thanks!

I will look at it eventually; the original behaviour was chosen to be robust with dodgy pools' handling of diff so it was actually there intentionally. Saying you lose a lot of shares is a gross exaggeration as most decent pools change diff only once or twice ever and that many shares will not even amount to a single satoshi over a lifetime of mining.

kenshirothefist

sr. member

Activity: 457

Merit: 273

ckolivas, could you please pull this pull request: https://github.com/ckolivas/cgminer/pull/679? This is a small but annoying bug, causing small loss of performance (in terms of accounted shares on pool) when changing difficulty - especially when using vardiff or often diff changing (when switching from low to high diff miner immediately sends high diff while is should/could still send low diff and pool might wrongly account for shares). Thanks!

rkinnin

sr. member

Activity: 316

Merit: 250

Quote from: kano on July 16, 2015, 08:41:17 AM

Download it again and check the checksum on the file?

i misunderstood one of your steps....sorry about that.

RTFM. Cheesy

I am good. Thanks.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Download it again and check the checksum on the file?

rkinnin

sr. member

Activity: 316

Merit: 250

Quote from: kano on July 09, 2015, 10:01:12 PM

Quote from: rkinnin on July 09, 2015, 09:56:25 PM

...
Would you suggest I use the same instructions to upgrade my s1's and s2's as you posted for the s3?

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

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

when attempting to use the s2 link on the actual s2 on the upgrade page I get the following error after I hit "flash image":

tar: invalid magic tar: short read cp: can't stat '*': No such file or directory

Thoughts??

rkinnin

sr. member

Activity: 316

Merit: 250

Quote from: kano on July 13, 2015, 11:47:41 PM

Quote from: rkinnin on July 13, 2015, 11:42:12 PM

I upgraded my s3's as was suggested.

I checked one of them tonight and now it says it found 6 blocks.

How can I really verify the validity of the 6?

Clearly alt-coin blocks.

No idea - we don't really care about alt-coins ... at all

agreed.

Ty

NathanB

newbie

Activity: 12

Merit: 0

win 7, version 4.9.2
rotate doesn't seem to work
tried different amt of time from 0 to 60 minutes
always stayed on which ever pool it was running on at time of change to rotate.
all pools were alive, and could switch pools manual
let run all night with rotate set to 13 minutes and when check this AM.
found it had ran the same pool all night.
checked pools web site, have graph showing hash over time
only one show hashing on graph, all other pools showed no hashing at all
pressed p for pool in cgminer display and still showed rotate at 13 minutes.
didn't switch off pool to next one.
bug?

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: rkinnin on July 13, 2015, 11:42:12 PM

I upgraded my s3's as was suggested.

I checked one of them tonight and now it says it found 6 blocks.

How can I really verify the validity of the 6?

Clearly alt-coin blocks.

No idea - we don't really care about alt-coins ... at all

rkinnin

sr. member

Activity: 316

Merit: 250

I upgraded my s3's as was suggested.

I checked one of them tonight and now it says it found 6 blocks.

How can I really verify the validity of the 6?

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