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

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.

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.

LP priority based on hash rate ... yeah right ... piss on the little guy
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 ...

LP priority is based on hashrate.

EDIT: Link: https://bitcointalksearch.org/topic/m.611014

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?

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.

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.

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.

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.

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.

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?

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. 

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.

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.

Yeah, Think the API should have it's own section detailing it's changes separately from CGminer.

NEWS file

I'm pretty certain I've changed the version number every time for a new release with new commands or new data.

Edit: also - it's highly consistent from one version to the next - new fields are added to the end - the order is never changed ... with CGMiner

Edit2: hmm looks like some of the NEWS descriptions don't say the actual API version numbers very often
(I guess I'll need to check the git why ...)

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?

Kano,
Do you have a list of each version of your API, and what it adds? Change log type thing?

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?

AniceInovation,

If you are running cgminer on Windows, you could try my akbash watchdog.  It will do what you wanted (and more).