Pages:
Author

Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 64. (Read 499709 times)

hero member
Activity: 628
Merit: 504
I've been mining DGM on the diff10 server for awhile now, and I notice I'm not getting as many namecoins as I used to.  Maybe only about 10%  Could there be an issue with the namecoin reward calculation for diff10?


Confirm, I hardly get any nmc too. So what? Its like 0.4btc a month for me.
sr. member
Activity: 344
Merit: 250
I've been mining DGM on the diff10 server for awhile now, and I notice I'm not getting as many namecoins as I used to.  Maybe only about 10%  Could there be an issue with the namecoin reward calculation for diff10?
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Yeah I should have put in more info last time.
Setup for cgminer is just my conf file. No hopping. Failover with 3 pools. Failover only was losing me about 4% or my average seemed to always be a few % lower and my unit wasn't keeping at 858+ between LP's.
Although Lukejr did ask me to see if his miner exhibits the same behavior I did not try it. His attitude was really off putting before so he will likely not get me as a user unless cgminer totally dies off. Even then if something else is out there with good failover you get the idea.

I do accept that some % of my shares will be rejected. I actually would happily take 2-3%. I am thrilled EclipseMC doesn't hide the rejects. Even with no hardware glitches I will see some rejects. I both know and am ok with that. My current CGMiner figures are 45519 Accepted and 4101 rejected. It is not at 10% was 33998 A to 3405 rejcted earlier.

I was trying to give an idea on my last edit when the problem was happening so that maybe (only lasts a bit over a minute before the pool is marked rejecting) the problem could be located. Obviously I can't see the shares besides when I submit them. I was hoping maybe there was a way to look over my rejects at around the time of my older messages edits. On thinking back I am not sure that EclipseMC keeps rejects though so I may have to restart with logging in the hopes of getting full shares printed and a time stamp to see if they should be valid.

EDIT: actually not logging so much as I want to write the rejects to a log starting with logging seemed the same as D, D.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Well I don't know how EMC works with handling rejects but it does have a few different messages Smiley

The message cgminer shows you in brackets is what the pool said, cgminer doesn't choose the messages in brackets.

Assuming there are no drastic problems with the pool, yes you wouldn't expect a high number of rejects each LP.

If on the other hand, you are doing something like switching the pool on an LP, that in itself may be causing problems also.
e.g. hopping (no I am not passing judgement on doing hopping)
An example of that would be to hop 'back' to EMC but before EMC knows about the new block.
This can happen on any pool of course, since of course the pool that found the block will know about it before every other pool and the delay can in rare cases be quite long.

If you turn on protocol debug in cgminer it will probably give you enough information to work out why it is happening.

Meanwhile ... regarding rejects.
There is a reasonably clear way for any non PPS based pool to reduce them.
I do notice rejects here higher than "somewhere" else ... i.e. ~1% vs ~0.3%
But that difference doesn't "matter" Smiley

I don't point my BFL here when I point my hardware here (only my non-BFL hardware) since BFL Singles will always get worse rejects than any other hardware.
(and even more if you are using the cgminer 'clone')
Hopefully you are not using 'the clone' coz that could also explain your problem ...
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Kano,
Although that did list my configuration and that you didn't like 2 settings. I actually only asked about the rejects after that. I hadn't wanted to ask previously because I was pretty sure I would hear that either it never happens or that there is no way to diagnose it.

If I misunderstood the LP system I am sorry. From what I have been told I have recieved a work unit when EclipseMC sends me a LP request. CGMiner actually starts sending that work to my single after whatever it is activly working on when the LP comes through ends (or earlier possibly with newer CGMiner potentially dumping the late work). It should be working at 5 seconds give or take a few fractions of a second the new work.

If I have work that didn't get sumitted I can accept that but why wouldn't it submit more then 1-3 shares every 5 seconds?
Why wouldn't any of the current work actually be submitted interspersed with either the late work or the late work get submitted faster?
Why wouldn't the finished work actually submit after the pool is disabled to make sure all the shares are submitted?

Con said even an expiry of 600 should not cause it to keep rolling work from before LP and having results from that rejected after the LP. Yes I set it to submit stales but even with that disabled it still submitted some stales because (according to CGMiner) EclipseMC requested submit stales. I get 1-4 stales at each LP usualy 1-2 but sometimes my last work unit generated 2 so it would be 2 work units at 2 potential shares with all 4 rejected. That is fine they are worthless. Sometimes (rarely) I get one accepted then more rejects. Usually I get all accepted after a couple of rejects (expected output). I know it isn't expected or likely common. But to explain all 13 rejects I would need 7 pre LP work units or more solved but not submitted that start submitting after the LP with no current work submitted to stop it from hitting 13 in a row.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
legendary
Activity: 1260
Merit: 1000
Well immediately it jumps out to me that you have expiry set to 600 instead of the default 120, which is also the same rollntime that I have set in EMC... I'm not saying that's the problem, but it is what I would immediately think might be the issue.  Any particular reason you have expiry set to 10 minutes? 
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Windows 7, 64 bit. 1 BFL single @864, Cable internet 10Meg down 1 meg up. CGMiner 2.7.4, 2.7.5 have shown this issue for sure. I am unsure about befre that as it isn't a constant problem for me. Maybe is 1 in 10 where I get tons of rejects maybe 1 in 15.

Current config:
{
"pools" : [
   {
      "url" : "http://gpumax.com:8332",
      "user" : "UN",
      "pass" : "PW"
   },
   {
      "url" : "http://us2.eclipsemc.com:8337",
      "user" : "UN",
      "pass" : "PW"
   },
   {
      "url" : "http://localhost:8331",
      "user" : "UN",
      "pass" : "PW"
   }
]
,
"api-port" : "port",
"disable-gpu" : true,
"expiry" : "600",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "2",
"log" : "5",
"protocol-dump" : true,
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "90",
"temp-hysteresis" : "1",
"shares" : "0",
"scan-serial" : [ "bitforce:COM5" ],
"kernel-path" : "/usr/local/bin"
}

Config I used until 8/31 early:
{
"pools" : [
   {
      "url" : "http://gpumax.com:8332",
      "user" : "un",
      "pass" : "pw"
   },
   {
      "url" : "http://us2.eclipsemc.com:8337",
      "user" : "UN",
      "pass" : "pw"
   },
   {
      "url" : "http://localhost:8331",
      "user" : "UN",
      "pass" : "pw"
   }
]
,
"api-port" : "port",
"disable-gpu" : true,
"expiry" : "600",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "2",
"log" : "5",
"net-delay" : true,
"no-submit-stale" : true,
"protocol-dump" : true,
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "90",
"temp-hysteresis" : "1",
"shares" : "0",
"scan-serial" : [ "bitforce:COM5" ],
"kernel-path" : "/usr/local/bin"
}

Problem shows on both. Second one shows that server requested submit stale so I am not sure why that would even be a point of contention but by all means it could matter. Using eclipse 3 as my private pool in gpumax. The only difference between using it and running directly to eclipse 2 is that I see the reject reason, not how many or how often, just the reason. Both pools have been being disabled because of rejects. Both pools get a high reject rate GPUmax while eclipse is doing my work rather then prepaid work.

Command line: cgminer.exe --disable-gpu

DOING IT RIGHT NOW
legendary
Activity: 1260
Merit: 1000
I can't duplicate your problem here and I haven't heard of anyone else having this problem, so it's hard to say what's going on, but it's unlikely to be the pool.  What version of CGMiner are you using and what operating system?  Post the command line and conf file you use to start cgminer, maybe something in there will give a clue.
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Is the server so slow that all the previous blocks work takes over a minute to submit while my currently processing shares would be unable to submit at all? I doublt it as then I should show a 1 minute lag between starting CGMiner and getting a single accepted share EDIT or a bunch of small delays/EDIT. It takes in practice about 5s. I know there are super fast miners on here but my 860 Mhashs are not or should not be a real problem. As far as --No-Submit-Stale I did have it set as true and was getting the same ~10% rejects Not on every LP or every block. I turned it off to see if it would make them go stupid on me. They stayed the same. The reason I pointed out several blocks and it really shouldn't be able to help anyone but Inaba is that it isn't every block or every LP. Some blocks I have >10% stales. All show up just after LP and yes it could be enqued results that have been so far delayed that they are submitted after the LP BUT why would it go from one every 5s or so before LP as accepted and 1 every 5s or so Rejected(Prev-Blk) with the same spacing and the debug showing it is rolling work, getting a result, submitting said result, and then having it REJECTED as Previous Block?

EDIT: The 2-2.5% I wasn't worried about as it seems about normal for me. Should it be lower I would hope so. Would I kill to get the 10% rejected solid previous block work killed off directly and get to a solid 2% sure. I am getting at times 13 in a row before the pool is disabled. Assuming all 13 came from previous block how did it get so far behind?

Had asked on CGMiner thread in two places about it in different ways.
First
https://bitcointalksearch.org/topic/m.1150641
Second
https://bitcointalksearch.org/topic/m.1151969
legendary
Activity: 1260
Merit: 1000
So yeah, that sounds like the issue then.  If you're getting stale-prevblk it just means you are submitting shares from the previous block, after the LP.  

There's nothing wrong with doing this, at least in the case of EMC, but it is going to increase your "apparent" stale count (but not your actual stale count, as those shares just would have been discarded anyway). 

hero member
Activity: 700
Merit: 500
Only talking here about the option --submit-stale no longer existing and being replaced by --no-submit-stale in cgminer options.

Quote
Human readable changelog

Important: --submit-stale option no longer exists. I have replaced it with --no-submit-stale and made it submit stale shares by default now.

sr. member
Activity: 378
Merit: 250
Why is it so damn hot in here?
Quote
"I have to remember to re-enable this" and then though "Yeah, no problem I will remember this time."  

If I had a nickel for every time I used to say this....
Sometimes I used to mark an X on my hand or wrap something around a finger ( to remember I had something important to do do) only to later go: What the hell is with this on my hand  Huh

Quote
But off the top of my head, it sounds like you may have --submit-stale turned on, which would definitely cause that issue.

If I am not mistaken submit stale is by default on, so you would need to disable it with : --no-submit-stale


It's not a matter of disabling it, it's a matter of not forcing it to submit the stale shares.  99.9% of the time, neither --submit-stale , or --no-submit-stale should be used.  If neither is used, CGminer defaults to doing what the pool tells it to do.

Please don't confuse people screwing with CGminer's settings to be a problem of CGminer itself, there is a difference between operator error and a program error.
hero member
Activity: 700
Merit: 500
Quote
"I have to remember to re-enable this" and then though "Yeah, no problem I will remember this time."  

If I had a nickel for every time I used to say this....
Sometimes I used to mark an X on my hand or wrap something around a finger ( to remember I had something important to do do) only to later go: What the hell is with this on my hand  Huh

Quote
But off the top of my head, it sounds like you may have --submit-stale turned on, which would definitely cause that issue.

If I am not mistaken submit stale is by default on, so you would need to disable it with : --no-submit-stale
full member
Activity: 123
Merit: 100
Mine has come through as well, thanks Inaba...

thralen
sr. member
Activity: 476
Merit: 250
"I have to remember to re-enable this" and then though "Yeah, no problem I will remember this time."  
Oh, yeah, sure.

I've *never* done that. Not even on my real job where there was *real money* in substantial amounts involved.  Smiley

BTW, ty.

--

edit: And just to follow-up, my last auto-pay now shows on the chain.
legendary
Activity: 1260
Merit: 1000
!#@$#@$ Gah!  I disabled autopayouts while I worked out some bugs in the new Dwolla code and forgot to turn it back on.  It's back on now and they should all go out in the next 15 minutes or so.  I'm sorry about that.  When I disabled it, I even thought to myself "I have to remember to re-enable this" and then though "Yeah, no problem I will remember this time."  

Of course, I did not.  But in brief, the emails are sent out from a different queue than the payments are sent.  Lots of things in EMC are queued and handled by separate processes, some on different servers to take the load off any one server and provide a failover.  So when a payment goes out, an email is put into the queue and the payment itself is put into a different queue.  I disabled the actual payment queue but not the email one, so the emails went ahead and were sent while the actual payment queue just started to fill up. 

With regards to continuing to support EMC, I have been working for BFL for two weeks now, so yes, I will continue to support EMC as I have before.  No plans to change anything there, except possibly bring some additional help on board to give the site some much needed improvements that are beyond my time or ability at the moment.

Quote
Yeah, I can see rejected shares, just wasn't so obvious at first glance. Would be nice to have it in a separate column with percentage in brackets  . I'm running one minirig on bitminter pool atm, and I was really surprised to see 0.03%-0.045% reject rate. Taking into account that they do LP on every nmc block as well, unlike ozcoin for example, it shows really low reject rate. On emc I get around 0.075%-0.1% and that's with 0.4ms ping. DrHaribo said they made some major improvements, and zux0r helped them. At this point these small numbers don't mean anything, but when the asics come, they will

I have been thinking about re-designing the My workers page, so let me look into what can be done there.  Right now, we are short on room as far as that goes, so adding stuff has always been an exercise in juggling all the info without squeezing it all in there and looking terrible.

For reject rates, what are you getting rejected with, because that would make a difference on how to fix it.

Quote
Sometimes after LP's I get a string of rejected work saying stale (prev-blk) CGMiner is rolling the work and producing apparently stale shares for me at my normal submission rate. When a new work unit is recieved after rolling finishes I suddenly have all accepted shares. If I manually change to a different server on EclipseMC I will also suddenly have all accepted shares. Checking EclipseMC numbered blocks 2024,2025 I have around a 10% reject rate but on 2026 I have just  under 2% as well as 2027 is just above 2%. My average according to CGminer is 9.68%. Could you look into why at the LP it seems I am either given an old work unit sometimes or why it marks work from the LP work unit as prev-blk?

That sounds like a CGMiner issue, actually... make ckolivas can chime in with some suggestion(s) on a source of the problem and/or how to fix it.  But off the top of my head, it sounds like you may have --submit-stale turned on, which would definitely cause that issue.

On another note, I am going to be putting up a test server with dynamic difficulty... I will post some more information tonight, but it's the ultimate goal of the diff10 server.  For now, I will leave the diff10 server up and running and put up another server for dynamic difficulty testing.  Then once that's stable and working, I will be rolling it out to all the servers and taking the diff10 server offline.  

At that point, much like the saying "God only gives you what you can handle." the servers will start handing out shares of varying difficulty based on what you can handle. Smiley  Slower miners will get lower difficulty shares and faster ones will get higher difficulty shares and no one will be left out or left behind either now or going forward into the ASIC era.
sr. member
Activity: 476
Merit: 250
I have an autopay waiting to show in the blockchain for 4.5 hours now...
And I've not seen mine yet either, after about an hour now.

So, emails purporting payments are being sent but the actual payments are not being submitted?

Not good, Inaba.
donator
Activity: 448
Merit: 250
Yeah, did a manual payment a couple of hours ago. Still hasn't shown up. Usually takes a minute or two. Half hour at most. I guess there is some sort of bug Inaba has to work out.

I have an autopay waiting to show in the blockchain for 4.5 hours now...
legendary
Activity: 1022
Merit: 1001
I'd fight Gandhi.
Yeah, did a manual payment a couple of hours ago. Still hasn't shown up. Usually takes a minute or two. Half hour at most. I guess there is some sort of bug Inaba has to work out.
Pages:
Jump to: