Author

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

full member
Activity: 154
Merit: 100
I used cgminer pool and it told me that the pool I'm on has 2.3% rejected.

Is this normal or should I look into my PC or change pool?
Just a little more information might be helpful Cheesy

Edit: OK from browsing around the forum, you are using EMC and have around 1.4GH/s
The reject number is high if it is long term.
How long were you mining to get that number?
What are your long term numbers from cgminer?
Basically the output of the top of the screen (everything down to the "Accepted" lines) or if you have the API enabled, as much info as possible from the commands: config, summary, devs and pools.

Edit2: also the non-standard API 'stats' would be interesting if someone else using EMC would post theirs also

I got it down to 1.7% R 1.4% R with the eclipseMC EU server(I'm in europe).

I recently started to mine on bonuspool, it's not the standard 8332 port, do I manually need to change it to the correct port in cgminer?

It seems to be working but I need to check website if it indeed does.

Edit--> Sorry I forgot mention it is long term and when switching to EU server eclipsemc it now is 1.4% instead of 2.3%.
So is there anything else I can do to improve Rejected shares?

Also I switched to bonuspool so new pool and server now
member
Activity: 546
Merit: 10
For some reason 2.4.0 and 2.4.1 will not properly save the configuration file for me. On restart after saving and having everything working I get this.

Code:

 [2012-05-07 02:24:42] Started cgminer 2.4.1
 [2012-05-07 02:24:42] Started cgminer 2.4.1
 [2012-05-07 02:24:42] Loaded configuration file cgminer.conf
 [2012-05-07 02:24:42] Fatal JSON error in configuration file.
 [2012-05-07 02:24:42] Configuration file could not be used.
 [2012-05-07 02:24:42] Icarus Detect: Failed to open bitforce:COM3
 [2012-05-07 02:24:43] Found 0 ztex board(s)
 [2012-05-07 02:24:43] Need to specify at least one pool server.
Input server details.
URL:


This isn't a tragedy per se but it makes it very hard to restart to try to reset my averages or change placement.


I'm having the same issue.  Did you ever figure out a fix?
legendary
Activity: 1795
Merit: 1208
This is not OK.
Something else to look into:

Since upping one of my BFLs to the 864 firmware, it seems to stop working (not the CGminer issue - I don't think). the 'status' reports 'Thread got zero hashes' and the 'dev' command reports enabled 'N', how ever it still says the dev status as 'Alive'. Not so sure it should be alive, trying to re-enable it remains disabled.

Edit: restarting CGminer will kick it back into action (for a while, anyway) so maybe some re-init code should be sent when re-enabling.

Edit2: It would seem it never recovers when it throttles
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
I used cgminer pool and it told me that the pool I'm on has 2.3% rejected.

Is this normal or should I look into my PC or change pool?
Just a little more information might be helpful Cheesy

Edit: OK from browsing around the forum, you are using EMC and have around 1.4GH/s
The reject number is high if it is long term.
How long were you mining to get that number?
What are your long term numbers from cgminer?
Basically the output of the top of the screen (everything down to the "Accepted" lines) or if you have the API enabled, as much info as possible from the commands: config, summary, devs and pools.

Edit2: also the non-standard API 'stats' would be interesting if someone else using EMC would post theirs also
hero member
Activity: 868
Merit: 1000
Ckolivas:

this is a funny message generated by CGMiner (on all my miners) !:

Code:
 cgminer version 2.4.1 - Started: [2012-05-12 03:29:42]
--------------------------------------------------------------------------------
 (5s):312.0 (avg):311.9 Mh/s | Q:193  A:83  R:4  HW:0  E:43%  U:4.4/m
 TQ: 2  ST: 5  SS: 0  DW: 11  NB: 2  LW: 139  GF: 0  RF: 0
 Connected to http://pool.bonuspool.co.cc:80 with LP as user
 Block: 00000263027422ab47efedc55dcc2dc4...  Started: [03:47:03]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.5C 2287RPM | 312.4/311.9Mh/s | A:84 R:4 HW:0 U:4.50/m I: 6
--------------------------------------------------------------------------------

 [2012-05-12 03:45:47] Accepted 65beb547.b86069e7 GPU 0 pool 0
 [2012-05-12 03:45:53] Accepted 3acd4866.8076a92d GPU 0 pool 0
 [2012-05-12 03:45:54] Accepted ff3aae97.f1bf6754 GPU 0 pool 0
 [2012-05-12 03:46:59] Accepted 0df92b7c.be02982a GPU 0 pool 0
 [2012-05-12 03:47:03] [font=Verdana][b]LONGPOLL from pool 4 detected new block[/b][/font]
 [2012-05-12 03:47:31] Rejected 9d002557.57674fb4 GPU 0 pool 0
 [2012-05-12 03:47:34] Rejected 751cb3f6.be3a7a7b GPU 0 pool 0
 [2012-05-12 03:47:53] Rejected b102aecc.98c97f4d GPU 0 pool 0
 [2012-05-12 03:47:59] Rejected 49048041.99b08d57 GPU 0 pool 0
 [2012-05-12 03:48:04] Accepted 460ba46d.385763c2 GPU 0 pool 1
 [2012-05-12 03:48:16] Accepted cde0f3d9.bd62e648 GPU 0 pool 0
 [2012-05-12 03:48:19] Accepted 7c523153.1d02f184 GPU 0 pool 0
 [2012-05-12 03:48:26] Accepted 9522afd5.ca52eaaf GPU 0 pool 0

I only have 3 pools !!! My main pool (pool 0) and 2 backup pools !!!

Pool 4 does not exist !!!

Lols  Grin
full member
Activity: 154
Merit: 100
I used cgminer pool and it told me that the pool I'm on has 2.3% rejected.

Is this normal or should I look into my PC or change pool?
rjk
sr. member
Activity: 462
Merit: 250
1ngldh
I agree basing longpoll priority on absolute hashrate would be a real shame to all the smaller miners. The original bitcoin vision was that anyone connected to it could contribute a few cycles in a massively distributed computing power entity, and it's actually unfortunate that it is becoming such a "professional job" to actually earn something via mining. On the other hand, all it would take is some kind of nominal number of shares, say 1 in the last minute, to detect an active miner versus a backup miner. It would also kick botnets' arses.
I believe this is the case. At that link, you will see that Slush mentions CPU miners and says that this should deal with them. I assume that the priority doesn't apply to miners over a low rate such as 100mhash, and therefore implementing prioritization on EMC may not make a noticeable difference in load or such things.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I agree basing longpoll priority on absolute hashrate would be a real shame to all the smaller miners. The original bitcoin vision was that anyone connected to it could contribute a few cycles in a massively distributed computing power entity, and it's actually unfortunate that it is becoming such a "professional job" to actually earn something via mining. On the other hand, all it would take is some kind of nominal number of shares, say 1 in the last minute, to detect an active miner versus a backup miner. It would also kick botnets' arses.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Well, it's basically up to over 6000 outbound connections at the same instant on one server right now... how does Slush determine who gets LP priority?
LP priority is based on hashrate.

EDIT: Link: https://bitcointalksearch.org/topic/m.611014
LP priority based on hash rate ... yeah right ... piss on the little guy Tongue
Slush is certainly on my ban list once I found out about that a while back (though I have never created a slush account ...)
I used to be 720MH/s (now 2.295GH/s) so I have plenty of sympathy for people with only one or 2 medium hashing ATI cards.
Of course setting a lower limit is fine (yes people should not be CPU mining) and that would also cover people using the pool as a backup but not mining, but everyone else should be random - and anyone mining BTC (and/or running a pool) should understand exactly what random means ...
rjk
sr. member
Activity: 462
Merit: 250
1ngldh
Well, it's basically up to over 6000 outbound connections at the same instant on one server right now... how does Slush determine who gets LP priority?
LP priority is based on hashrate.

EDIT: Link: https://bitcointalksearch.org/topic/m.611014
legendary
Activity: 1260
Merit: 1000
Well, it's basically up to over 6000 outbound connections at the same instant on one server right now... how does Slush determine who gets LP priority?
rjk
sr. member
Activity: 462
Merit: 250
1ngldh
I can't see a workable solution either at the moment, which is why I'm trying to just shore up the EMC servers to handle LPs better.  Maybe if there's some way to identify a "backup" LP request to the server, so the server can prioritize active LPs and backup LPs in a QoS fashion or something... that way LPs can be pushed out as best effort for the backup LPs.  It would obviously require some changes to pool software, but I don't think they'd be that drastic and it would help out everyone.


Slush prioritizes his LPs already, it sounds like a good idea.
Also, what is the bottleneck with many LPs? Is it processing power? Memory hog? Disk reads/writes blocking? Running out of sockets? I wonder if it could or should be offloaded onto a dedicated box, if it is that much of a load issue.
legendary
Activity: 1260
Merit: 1000
I can't see a workable solution either at the moment, which is why I'm trying to just shore up the EMC servers to handle LPs better.  Maybe if there's some way to identify a "backup" LP request to the server, so the server can prioritize active LPs and backup LPs in a QoS fashion or something... that way LPs can be pushed out as best effort for the backup LPs.  It would obviously require some changes to pool software, but I don't think they'd be that drastic and it would help out everyone.

legendary
Activity: 1795
Merit: 1208
This is not OK.
Kano,

From the code, I see that when saving a conf file through the API, a blank parameter will throw up a missing file error... could that be changed to save the default (in use) conf file? Would seem to be a sensible thing to do.
hero member
Activity: 658
Merit: 500
Cgminer hangs again. Could this be an issue with Sempron CPU's? Running a Sempron 145.

I doubt it, I've been running  rings on 145's for several months now.  Never had a cgminer hang that wasn't directly related to a card settings bork up.

You aren't trying to run it with an unlocked core or odd frequency settings by any chance?

I have a 5970 with one unstable core. I run it at 825 engine and 260 memclock. Any engine clock higher than that or memclock lower than that and the system freezes. The other core is happy at 875/220. SSH/screen other terminals are fine but unable to kill the cgminer process and restart.
Could it be other processes interfering with cgminer or confusing it? What would cause multiple sshd's to run, multiple udisk to run?

check the first core VRM temps ( the one closest to the dvi connectors ). the card is throttling because they are getting over 125C, when the card throttles itself this way it crashes cgminer. I have had the same problems, had to remove the heatsink and replace the pads on the vrm there.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Longpolls are really up to the pool to return, and cgminer will wait for up to 60 minutes for one. There's no real way to say "yeah I want a longpoll, but it's fine if you delay it for a minute or so". It's basically pushed from the pool and the client just receives it whenever. It's probably not ideal for cgminer to get a longpoll from every single backup pool you have configured, but there are logistical reasons for why it's done that way, and is more indicative of just how many people use LOTS of backup pools, EMC obviously being a popular one. There are issues with only running one longpoll from the primary pool when work is gathered from multiple pools during periods of overload, and there is no way to "turn off" a longpoll once it's been requested if you decide to change pools, and some pools have extra longpolls for merged mining, blockchain variations (eg p2pool) and so on. It's virtually impossible to just "do the right thing" since there is no right thing. A longpoll from each pool is the best thing for a miner. As we've seen with EMC, though, the longpoll load can also be quite hefty, even if the rest of networking has become MUCH politer to pools since 2.4.0. I'll think about it some more, but I can't see a solution that is optimal for both miner and pool.
hero member
Activity: 807
Merit: 500
I'm not sure which reason accounts for the increase, but I have a feeling it's because EMC is used as a backup for a lot of people, so the latter is likely the more likely explanation.  Hit over 5000 LP watchers on one server last night during a few long polls.  We normally only have about 1000 active miners give or take a few hundred at any given time.
Maybe a less invasive method would be for cgminer to delay the getwork on backup pools by a few seconds (and do so randomly)?

So time 0 your would see your 1000 or so active users send getwork and then spread out over the next x seconds randomly requests would come from the other 4000 or so users. 
Does cgminer request work from the backup pools, or is the load caued by the number of connections and the fact that the longpolls (which are pushed, not requested) contain work?
donator
Activity: 1218
Merit: 1080
Gerald Davis
I'm not sure which reason accounts for the increase, but I have a feeling it's because EMC is used as a backup for a lot of people, so the latter is likely the more likely explanation.  Hit over 5000 LP watchers on one server last night during a few long polls.  We normally only have about 1000 active miners give or take a few hundred at any given time.

Maybe a less invasive method would be for cgminer to delay the getwork on backup pools by a few seconds (and do so randomly)?

So time 0 your would see your 1000 or so active users send getwork and then spread out over the next x seconds randomly requests would come from the other 4000 or so users. 
legendary
Activity: 1260
Merit: 1000
Well, I think I am reporting the first casualty of the new LP handling method of CGMiner.  After struggling with my pool servers for the past few days, I've come to the conclusion that the new CGminer is "flooding" the server with LP requests.  Previously, before the LP changes, there would be ~800 or so LP watchers per server.  After the change, there is now more than 3000 LP watchers per server and the servers were struggling to keep up with LPs when they hit, causing stale shares and non/slow response until it was caught up.

I'm redoing the servers to handle LPs more gracefully (thanks to Luke-Jr/Eloipool!)... but I figured I'd make a post in case any other pool ops are suddenly struggling to figure out why their servers might be sluggish during LPs. 
Interesting.  Is this because each client is sending more LP requests, or is it just because anyone with EMC as a backup pool is now requesting a longpoll regardless of whether they're currently connected or not?

I'm not sure which reason accounts for the increase, but I have a feeling it's because EMC is used as a backup for a lot of people, so the latter is likely the more likely explanation.  Hit over 5000 LP watchers on one server last night during a few long polls.  We normally only have about 1000 active miners give or take a few hundred at any given time.

legendary
Activity: 1540
Merit: 1001
I just upgraded from 2.3.6 to 2.4.1.  I upgraded because I had annoying problem.  Every so often cgminer would forget I have a keyboard.  It would continually happily mine away, showing on the screen what it was doing.  But it no longer accepted keyboard commands.  To change, or quit, I'd have to terminate it, and restart it.  Then it would work fine again, until it once again forgot I had a keyboard.

On windows 7 64-bit.

Cgminer hangs again. Could this be an issue with Sempron CPU's? Running a Sempron 145.
Jump to: