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

Woke up to a hung cgminer 0% activity and no hashing

The log below hasn't changed in the last 5 hours, so I've restarted cgminer (had to X out of the window, as "q" wasn't working)

GPU 0/1 = 5970
GPU 2 = 5830
GPU 3 = 5830
GPU 4 = 5830

[2012-04-09 04:07:28] Accepted 00000000.398219cb.0ccf2195 GPU 4 thread 9
[2012-04-09 04:07:30] Accepted 00000000.5bb7eedb.2e813ef8 GPU 3 thread 7
[2012-04-09 04:07:30] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:30] Will attempt to re-initialise ADL
[2012-04-09 04:07:30] ADL re-initialisation complete
[2012-04-09 04:07:32] Accepted 00000000.031c03e9.d02f5836 GPU 3 thread 6
[2012-04-09 04:07:32] GPU 3 stopped reporting fanspeed
[2012-04-09 04:07:32] Will attempt to re-initialise ADL
[2012-04-09 04:07:32] ADL re-initialisation complete

They already had it (for quite a while) they just increased the time allowed to use it per work.

Ozcoin just announced that they have adjusted their X-Roll-Ntime to 120 seconds, if you mine there it may have made a difference for you.

I realize this. It's just nice to see overall network efficiency improving and less discarded work because of it.

....unless you are a Pool OP that is and I am sure the OPs appreciate the newly found efficiency of CGMiner and the affect it has on Getwork requests and their server loads

Efficiency is the number of shares you find per work requests from the pool.

However, with RollNTime, a miner can generate multiple work from the one work request.

So on my cgminer at the moment that shows Efficiency of 271% (which isn't actually very high) it means for each work request I ask from the pool, I generate on average 2.71 work requests (and on average reply with 2.71 shares)

The time it takes to mine those 2.71 shares is on average 2.71 times as long as mining 1 share.

A higher efficiency means that the pool had to provide you with less work and thus less communication and thus also less communication for your miner to the pool when trying to get work ...

Overall it's a big advantage for the pool and usually a small advantage for each miner
(but it doesn't mean you are getting more shares)

likely your pool implemented longer/better NTimeRolling.

BTW high (or low) efficiency has absolutely no effect on your bottom line.  It is a pretty useless stat.

I'm a bit out of the loop, but, did something drastic change in 2.3.2 ?

I have rigs reporting as high as 170% Efficiency right now, with 125-150% being the average range for the others.

Win7 x64, CGMiner 2.3.2
5 rigs each with either SDK 2.1 or 2.4 and CAT 11.12 on all.
Mixed 5xxx/6xxx series card machines, exclusive 5xxx series card machines and exclusive 6xxx series card machines.

The performance is not specific to any card/config. The ONLY thing they all have in common is the 11.12 driver and CGminer version 2.3.2.

WTF ?

I double checked and didn't rely on the Efficiency% readout only. The ratio of GetWork's to Accepted's (even with Rejected included/excluded) does not lie.

Colour me impressed

Seems like diablo and poclbm now fail to compile on SDK 2.1 and seg fault.

Not a problem just letting others know on 5870s.

Use diakgcn or phatk with 5870s and SDK 2.1

It seems that diakgcn is not as good as phatk.

Ahh that makes sense.  Thanks a lot!

As it says - the quit command is blocked (which it is by default)

The problem is that BAMT then does a process kill after the quit command - which of course only a program running on the same machine can kill a process.

Yup... BAMT.  Now that I look there, I see it sending the quit in the logs...  But the quit only kills cgminer when I run cgminer in a screen... weird.
It was fix 20 that added a cgminer watchdog.... since I'm not starting cgminer with the official BAMT profile, that probably caused some issue.  I removed BAMT fix 20 and its running fine now.  Thanks Kano!

Any way to make the cgminer API "readonly" or block the "quit" command?

BAMT running?

That "quit|\n" is what BAMT used to send cgminer (and probably still does) rather than just "quit"

Anyway the message means that something somewhere on your computer is send a "quit|\n" to cgminer and then killing the cgminer process (when the quit fails)

My guess would be BAMT - since that's what it does.
(unless someone else has written something to work like BAMT)

EDIT:  Found out it was fix 20 for bamt, just happened to apply that the same time i went to 2.3.2.... thank Kano!

I have a weird problem, doesn't happen in 2.3.1, but 2.3.2 has the problem... whenever I run in a screen, cgminer stops within a minute or two with this in the log:




However, if I run it without the screen command, it runs just fine....

My script to start with screen is:


Where quickcgminer.sh is:





If run just /root/quickcgminer.sh, then it runs just fine... without any quitting, so seems to be something with the screen command?

Any ideas?

In case anyone else runs into a similar situation...

I was wondering how to put multiple scan-serial command line arguments (for my icarus boards) into the cgminer config files so that I could stop including them on the command line.  After some experimentation, it seems the right way to do this is to use JSON array syntax to indicate the multiple values.  For example, here is a sample config file for my icarus devices (the line with scan-serial in it is the relevant line):

Code gets sent to git pull requests

We will try, mommy.

I'll be away for ~10 days. Behave while I'm away kids.

A few things ...

I'm wary of any code that includes "not sure if"

I guess I'll look at that windows stuff if I ever get around to fixing my windows compile and read up on the details of SetupComm, SetCommConfig and PurgeComm
... and find out what problems that PurgeComm could cause ...

As for the linux code:

Yes it is supposed to be a DEBUG, it is not an ERR.
I happens every time a work request doesn't have a share within the 'total' timeout
I changed it way back to DEBUG since it was originally a WARNING (always displayed).

Your read will write off the end of the buffer when there are more than 4 bytes available ...

My suggestion Post ideas, not code ...

The driver simply did not configure my 6970s at all so I had to manually add them. It was a basic blank configuration so all I had to do was find out what pci bus number they were and add them:

Changed:
Section "ServerLayout"
        Identifier     "aticonfig Layout"
        Screen      0  "aticonfig-Screen[0]-0" 0 0

to also have:
        Screen         "aticonfig-Screen[1]-0" RightOf "aticonfig-Screen[0]-0"
        Screen         "aticonfig-Screen[2]-0" RightOf "aticonfig-Screen[1]-0"
etc..


Changed
Section "Monitor"
        Identifier   "aticonfig-Monitor[0]-0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"
EndSection

to have extra entries of:
Section "Monitor"
        Identifier   "aticonfig-Monitor[1]-0"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"
EndSection
etc...

Changed
Section "Device"
        Identifier  "aticonfig-Device[0]-0"
        Driver      "fglrx"
        BusID       "PCI:1:0:0"
EndSection

to have extra entries of:
Section "Device"
        Identifier  "aticonfig-Device[1]-0"
        Driver      "fglrx"
        BusID       "PCI:6:0:0"
EndSection
etc...

Note I manually figured out what PCI bus numbers to put in based on the output of:
lspci  | grep VGA
which reads:
01:00.0 VGA compatible controller: ATI Technologies Inc Device 6798
06:00.0 VGA compatible controller: ATI Technologies Inc Device 6718
07:00.0 VGA compatible controller: ATI Technologies Inc Device 6718
etc.

And finally
Section "Screen"
        Identifier "aticonfig-Screen[0]-0"
        Device     "aticonfig-Device[0]-0"
        Monitor    "aticonfig-Monitor[0]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

had extra entries of:

Section "Screen"
        Identifier "aticonfig-Screen[1]-0"
        Device     "aticonfig-Device[1]-0"
        Monitor    "aticonfig-Monitor[1]-0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection
etc..

So yeah not exactly a straight forward operation. It's supposed to work automatically with the command:
aticonfig --adapter=all --initial -f

but it didn't...