Author

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

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
The best one to use there would be "Last Valid Work" ... that says 357835s ago or 99h 23m 55s ...

This can work when mining against pool but cannot be used for solo mining at higher diff; in that situation you can mine several days without block or share and Last valid work cannot be used.
...
Nope.

I really did say that coz it is correct ...

I added "Last Valid Work" to cgminer coz it is the best way to determine something is wrong.

It has nothing to do with shares or difficulty.

It is the last time a valid hash was returned by the device.

Tested and it doesn't work for solo mining. I calculated "timeout" from devs data, like
devs.STATUS.When-devs.DEVS(x).Last Valid Work; I see that timeout can be high even for healthy card...
Try again ... it works ... I wrote it Tongue

Code:
[STATUS] =>
(
   [STATUS] => S
   [When] => 1375430059
   [ Code] => 9
   [Msg] => 0 GPU(s) - 3 ASC(s) - 6 PGA(s) -
   [Description] => Subaru
)
[ASC0] =>
(
   [ASC] => 0
   [Name] => BAS
   [ID] => 0
   [Enabled] => Y
   [Status] => Alive
   [Temperature] => 67.00
   [MHS av] => 61520.46
   [MHS 5s] => 61445.47
   [Accepted] => 5040
   [Rejected] => 30
   [Hardware Errors] => 19392
   [Utility] => 3.35
   [Last Share Pool] => 0
   [Last Share Time] => 1375430055
   [Total MH] => 5561359878.0407
   [Diff1 Work] => 1292409
   [Difficulty Accepted] => 1271115.00000000
   [Difficulty Rejected] => 7680.00000000
   [Last Share Difficulty] => 256.00000000
   [No Device] => false
   [Last Valid Work] => 1375430059
)

1375430059-1375430059=0

Yep a BAS (61.5GH/s) will average >14 results a second so will usually be 0

For an AMU as it says 335MH/s
Code:
[STATUS] =>
(
   [STATUS] => S
   [When] => 1375430228
   [ Code] => 9
   [Msg] => 0 ASC(s) - 3 PGA(s) -
   [Description] => Pi
)
[PGA0] =>
(
   [PGA] => 0
   [Name] => AMU
   [ID] => 0
   [Enabled] => Y
   [Status] => Alive
   [Temperature] => 0.00
   [MHS av] => 335.97
   [MHS 5s] => 335.36
   [Accepted] => 35
   [Rejected] => 0
   [Hardware Errors] => 90
   [Utility] => 0.02
   [Last Share Pool] => 0
   [Last Share Time] => 1375428250
   [Total MH] => 37978409.3286
   [Frequency] => 0.00
   [Diff1 Work] => 8761
   [Difficulty Accepted] => 7430.00000000
   [Difficulty Rejected] => 0.00000000
   [Last Share Difficulty] => 256.00000000
   [No Device] => false
   [Last Valid Work] => 1375430227
)
1375430228-1375430227=1
It will average 12.8 seconds
Variance of up to 8 times is not rare so 102 would not be unexpected
(My script that checks it for my old Icarus that sometimes stops working uses a factor of 21.2 to restart cgminer)
Of course if you get a hardware error, that won't count - so consider that like doubling the time ... then a few HW in a row ... and ...
PSL
member
Activity: 166
Merit: 10
...
The best one to use there would be "Last Valid Work" ... that says 357835s ago or 99h 23m 55s ...

This can work when mining against pool but cannot be used for solo mining at higher diff; in that situation you can mine several days without block or share and Last valid work cannot be used.
...
Nope.

I really did say that coz it is correct ...

I added "Last Valid Work" to cgminer coz it is the best way to determine something is wrong.

It has nothing to do with shares or difficulty.

It is the last time a valid hash was returned by the device.

Tested and it doesn't work for solo mining. I calculated "timeout" from devs data, like
devs.STATUS.When-devs.DEVS(x).Last Valid Work; I see that timeout can be high even for healthy card...
PSL
member
Activity: 166
Merit: 10
What about API and blocks found by cgminer? It looks like noone is really interested in blocks, all effort is focused to shares reporting... The only API command "summary" reports blocks found. I can manually display blocks found for a pool. Could by API command "pools" extended to report blocks found for a pool?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
The best one to use there would be "Last Valid Work" ... that says 357835s ago or 99h 23m 55s ...

This can work when mining against pool but cannot be used for solo mining at higher diff; in that situation you can mine several days without block or share and Last valid work cannot be used.
...
Nope.

I really did say that coz it is correct ...

I added "Last Valid Work" to cgminer coz it is the best way to determine something is wrong.

It has nothing to do with shares or difficulty.

It is the last time a valid hash was returned by the device.
PSL
member
Activity: 166
Merit: 10
Firstly, "When" - "Last Share Time" was 357929s ago ... so yeah that explains the rejects - it's spitting out crap Tongue
357929s = 99h 25m 29s
Probably scrypt mining on too high settings?

I don't comply about rejects. These are OK, it was mining against p2pool. Problem is that HASHRATE of this card was 0 for few days and API didn't indicate that card is SICK and AVG rate was not updated. Other problem is that cgminer had no data for few seconds, marked card SICK and never tried to restart mining. Two or three different issues.

I am not sure what is the trigger of this situation, maybe that PC running p2pool was rebooted to apply security updates, so p2pool was offline for few minutes.

The best one to use there would be "Last Valid Work" ... that says 357835s ago or 99h 23m 55s ...

This can work when mining against pool but cannot be used for solo mining at higher diff; in that situation you can mine several days without block or share and Last valid work cannot be used.

The MH av will take a long time to get to 0 since it is the av since it started and it obviously did 'some' work. It says you did "Total MH": 156195.3567, so it would take a long time for that to average out to less than 10kH/s (more than 180 days)

The device isn't SICK when you did the API command it was "Status": "Alive"

Card was running ok for several days and in one moment card was marked as SICK, hashrate changed to 0, temperature and GPU engine frequency were set low; card was marked sick for several days and status was ALIVE all the time, otherwise monitoring script will highlight the problem. And this is why I thing there is a bug... Is it expected that SICK card is reported in API as DEAD?

The notify command would say when it last has a problem and also how many times it was SICK.

I don't have "notify" report for sick card; next time...
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I have an Avalon batch3 4 modules, firmware 20130723.
After a few hours of hashing, some of the modules stops (once all stopped, once three of them, once two of them). The other(s) continue hashing.
Temperatures are normal, 21,65,50.
It happened @300 and @282MHz, although unit can hash @350MHz at least for some time.
I have measured power consumption at the wall and it's in normal PSU parameters.
When module(s) stop, there's this error in System Log:
Code:
usb 1-1: clear tt 1 (0030) error -71
Any ideas?
I did not create that firmware...

However that looks like a usb connectivity issue which happens quite often on avalon because of the terrible hardware that it's run on (the wrt703n router). If you can connect to it via ethernet and fully disable wifi, you will find it more reliable.

(Remember I'm providing generic support for firmware I did not create though).
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
legendary
Activity: 952
Merit: 1000
I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working.

It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen".

I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer. Tongue

Other than that issue, it's working great on my BFL equipment. Thanks! Cheesy
I have also seen this happen with 3.3.1 on low-powered CPUs (Atom class) on both Windows 7 and 8.
Its a 990FXA board with a FX-8120, CPU so its not underpowered. And yes, I only minimized it, I did not close and reopen.
full member
Activity: 206
Merit: 100
Temperatures are normal, 21,65,50.
Are you sure? 65 is chip max I think and also standard cutoff in cgminer?
Default target was 70, cutoff 90. I have put them at 65 and 85.

My batch#2 Avalons make problems with 55+. Try 50 as target and you will have no issues.
in batch#3 they moved the temperature sensor to the board. 50 @batch#2 is roughly equiv. to 70 @batch#3. So I'm actually 5 degrees lower.
sr. member
Activity: 397
Merit: 500
Temperatures are normal, 21,65,50.
Are you sure? 65 is chip max I think and also standard cutoff in cgminer?
Default target was 70, cutoff 90. I have put them at 65 and 85.

My batch#2 Avalons make problems with 55+. Try 50 as target and you will have no issues.
PSL
member
Activity: 166
Merit: 10
My GPU was SICK for several days and I missed that because monitoring script reading API port 4028 reported OK. Is there a way to detect SICK card through API?

cgminer 3.2.2 reported:
Code:
[2013-07-28 11:29:54] Stratum from pool 1 detected new block
[2013-07-28 11:29:55] Pool 1 stale share detected, discarding
[2013-07-28 11:29:56] Accepted 876fa488 Diff 4/2 GPU 0 pool 1
[2013-07-28 11:31:28] Stratum connection to pool 1 interrupted
[2013-07-28 11:31:28] Lost 517 shares due to stratum disconnect on pool 1
[2013-07-28 11:31:30] Pool 1 stratum share submission failure
[2013-07-28 11:32:00] Pool 1 communication resumed, submitting work
[2013-07-28 11:32:00] Rejected acc5c400 Diff 3/2 GPU 0 pool 1
[2013-07-28 11:32:32] GPU0: Idle for more than 60 seconds, declaring SICK!
[2013-07-28 11:32:32] GPU0: Attempting to restart
[2013-07-28 11:32:32] Thread 0 still exists, killing it off
[2013-07-28 11:32:32] Thread 0 restarted

"devs" report for SICK card:
Code:
echo '{"command" : "devs"}' | nc localhost 4028 | tr -d '\0' | python -mjson.tool
{
    "DEVS": [
        {
            "Accepted": 694192,
            "Diff1 Work": 2380127,
            "Difficulty Accepted": 1360131.0,
            "Difficulty Rejected": 436120.0,
            "Enabled": "Y",
            "Fan Percent": 56,
            "Fan Speed": -1,
            "GPU": 0,
            "GPU Activity": 0,
            "GPU Clock": 157,
            "GPU Voltage": 1.1,
            "Hardware Errors": 0,
            "Intensity": "18",
            "Last Share Difficulty": 2.0,
            "Last Share Pool": 1,
            "Last Share Time": 1375003796,
            "Last Valid Work": 1375003890,
            "MHS 5s": 0.0,
            "MHS av": 0.17,
            "Memory Clock": 300,
            "Powertune": 0,
            "Rejected": 222954,
            "Status": "Alive",
            "Temperature": 40.0,
            "Total MH": 156195.3567,
            "Utility": 44.85
        }
    ],
    "STATUS": [
        {
            "Code": 9,
            "Description": "cgminer 3.2.2",
            "Msg": "1 GPU(s) - ",
            "STATUS": "S",
            "When": 1375361725
        }
    ],
    "id": 1
}

I am not sure but this could be a bug. I can try to detect SICK state from several parameters (MHS 5s, GPU Activity, Temperature) but is it correct way? If it is, what parameter should be used for detection?
BTW, reported parameter "MHS av" is wrong, it was 0.00, because card was sick for several days...
full member
Activity: 206
Merit: 100
Temperatures are normal, 21,65,50.
Are you sure? 65 is chip max I think and also standard cutoff in cgminer?
Default target was 70, cutoff 90. I have put them at 65 and 85.
sr. member
Activity: 397
Merit: 500
Temperatures are normal, 21,65,50.
Are you sure? 65 is chip max I think and also standard cutoff in cgminer?
full member
Activity: 206
Merit: 100
I have an Avalon batch3 4 modules, firmware 20130723.
After a few hours of hashing, some of the modules stops (once all stopped, once three of them, once two of them). The other(s) continue hashing.
Temperatures are normal, 21,65,50.
It happened @300 and @282MHz, although unit can hash @350MHz at least for some time.
I have measured power consumption at the wall and it's in normal PSU parameters.
When module(s) stop, there's this error in System Log:
Code:
usb 1-1: clear tt 1 (0030) error -71
Any ideas?
donator
Activity: 1617
Merit: 1012
I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working.

It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen".

I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer. Tongue

Other than that issue, it's working great on my BFL equipment. Thanks! Cheesy
I have also seen this happen with 3.3.1 on low-powered CPUs (Atom class) on both Windows 7 and 8.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
What you are showing there is libusb failing to timeout.
That's what the test program will test and show for the version of libusb you use.
I've put usbfail.c and the working libusb libusb-1.0.16-rc10.tar.bz2 in my binaries git:
https://github.com/kanoi/cgminer-binaries

On linux, To use the working libusb for cgminer instead of the system libusb -
First install udev-dev via one of:
Fedora: yum install libgudev1
Ubuntu derivatives: apt-get install libudev-dev
Arch: it should be installed by default as part of systemd
When you are in the cgminer folder:
mkdir libusb
cd libusb
wget -O libusb-1.0.16-rc10.tar.bz2 https://github.com/kanoi/cgminer-binaries/blob/master/libusb-1.0.16-rc10.tar.bz2?raw=true
tar -xvf libusb-1.0.16-rc10.tar.bz2
cd libusb-1.0.16-rc10
./configure
make
cd ..
cd ..

If you have already autogen/configured cgminer, next you want to edit Makefile
Search for -I/usr/include/libusb-1.0 change all 3 to make sure it's working to -Ilibusb/libusb-1.0.16-rc10/libusb/
Also search for -lusb-1.0 and change both of them to libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev (without the first -l)
Then
make clean
make

and now your cgminer will have been compiled against my specific libusb-1.0.16-rc10 properly
N.B. you have to use that version in my git, not the system versions - it would appear a lot if linux distros have a bad libusb
sr. member
Activity: 281
Merit: 250
http://pastie.org/private/qzjzezzghx4ojwyysygfqw

on Ubuntu 13.04
the apt-get supplied libusb fails, but libusb-1.0.16-rc10 reports success.

I use cgminer 3.1.1 to mine using the serial interface. Newer cgminers typically  do not detect AMU or show a hashrate of ~100 MH/s . I will try building cgminer master against this libusb version and report back if i have any success.

Thanks, that info is perfect and says exactly what I'd hope it says.
For 12.04 the problem for you is almost certainly in the libusb version.
I expect (though I'll wait to see before I'm 100% certain) that current git and latest libusb should not get SICK devices, should not hash at ~100MH/s for some devices (instead of ~333MH/s) and should not have regular TIMEOUT errors (a rare few is OK)

Detection problems 'might' also be addressed by current git since there is a usb config setup change I've added that may help
Though interestingly enough, writing this test code I found a situation where it would actually get out of sync with replies during initialisation, that I'll look into and see if it is related, once the libusb version issue is clarified and resolved.

FYI im on 13.04 not 12.04.

I just rebuilt cgminer (newest commit bda1e333222e9921be793a1e517d84d4aba88ea5)
./configure command:-
Code:
LIBUSB_CFLAGS="-I/home/xxx/tmp/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="/home/xxx/tmp/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev" ./configure --disable-opencl --disable-adl --enable-bflsc --enable-bitforce --enable-icarus --enable-modminer --enable-ztex --enable-avalon

Summary: http://pastie.org/private/5qstv1txipwwddh97ujhmq

both AMUs are running at ~333MH/s.. and they start mining as soon as cgminer starts. Stopped and started a few times to be sure.

If the problem is fixed for most linux users by using a specific libusb version AND inclusion of this version of libusb in distro repositories is not in the horizon, i guess cgminer should bundle the working lib.


I Also have problems. On my USB there are 10 USB Eruptions Wink en 1 BFL Jap. I pulled the latest again from github, build the latest libusb in the .16 range and build both with a configure pointing to the newly build usblib libs.

Result: Same problem, only 4 USB Erups are getting work done just above 100H the rest is going to SICK after a few moment.
I am using Raspberry PI model B , Debian Weezy fully updated and github cgminer and latest usblib.
The BFL is on one USB port the Eruptors are on the other with 2 hubs every hub beining powered by 5Amps PSU so it's no power issue at all.
BFGMiner (using plain serial comms) is working fine with very low hardware error rate.

I Guess maybee its another lib that is causing the problem , I read a lot of people on RaspPi 's with the problem and running Debian Wheezy on it. When i used ArchLinux it worked fine. But the kernel watchdog driver is not ok in that distribution and i want is the help itself when i crashes.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working.

It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen".

I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer. Tongue

Other than that issue, it's working great on my BFL equipment. Thanks! Cheesy
Yes I have seen curses go silly and lose an escape code and start spitting random junk into the window header name even on linux
So either it is indeed curses on windows or some command prompt problem.
Also note that Ctrl-S will pause the screen and Ctrl-Q unpause it.
But just to check - you mean that you didn't stop/restart cgminer, just minimised the window and brought it back up?
legendary
Activity: 952
Merit: 1000
I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working.

It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen".

I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer. Tongue

Other than that issue, it's working great on my BFL equipment. Thanks! Cheesy
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4

Occationally the cgminer log says:

Code:
BAJ 0:  max 46C 3.98V | ZOMBIE/941.2Mh/s | A:311 R:0 HW:127 U:  2.26/m
--------------------------------------------------------------------
 [2013-07-31 23:36:10] BAJ2: GetResults failed (err=-8 amt=0)
 [2013-07-31 23:36:11] BAJ2: RequestResults failed (err=-4 amt=0)
 [2013-07-31 23:36:12] BAJ 2 failure, disabling!
 [2013-07-31 23:36:12] Thread 3 being disabled

and my Jalapeno stops working.

Can anybody tell me what this (especially the codes err=..., amt=...) mean ?

Thanks in advance
It means the device disconnected (the second error = -4)
My first guess would be a bad or loose USB cable.
Second guess would be a bad hub if you are using a USB hub.
Also, what version of cgminer is it?

(Aside: rerr and werr are in the Icarus driver only - in the BAS driver you see the actual commands GetResults and RequestResults, since there are a lot more different commands on the BASs)
Jump to: