[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[Askit2]

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://bitcointalk.org/index.php?topic=28402.msg1150641#msg1150641
Second
https://bitcointalk.org/index.php?topic=28402.msg1151969#msg1151969

[1713975775]

1713975775

[1713975775]

1713975775

[1713975775]

1713975775

[1713975775]

1713975775

[1713975775]

1713975775

[1713975775]

1713975775

[Inaba]

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.

[Askit2]

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

[Inaba]

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? 

[kano]

...
Had asked on CGMiner thread in two places about it in different ways.
First
https://bitcointalk.org/index.php?topic=28402.msg1150641#msg1150641
Second
https://bitcointalk.org/index.php?topic=28402.msg1151969#msg1151969

You forgot this one
https://bitcointalk.org/index.php?topic=28402.msg1141034#msg1141034

[Askit2]

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.

[kano]

Well I don't know how EMC works with handling rejects but it does have a few different messages

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"

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 ...

[Askit2]

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.

[dave3]

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?

[BlackPrapor]

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.

[Askit2]

Kano, When I said no hopping I did tell the truth but in thinking over the question more I wonder if GPUMax isn't either delaying a LP or not properly sending me new work as fast as it should. I am trying to get my direct connction to go rejecting. So far no luck. There have been strings of rejects but not enough. It almost looks like CGMiner takes the prev-blk and requsts new work after 6 units or so it worked on being stale that way.

It looks like I could come up with a better way to handle it. If I could get GPUMax to actually fail when there is no work.

Deleted my private pool. eclipseMC. lets see if it helps me.

EDIT: Keeps sending work to EclipseMC. Set my private pool to diff10. hoping when that gets done with testing that I will suddenly have no private work on GPUMax. Of course if that server gets frowarded to any other then yeah will be back to manual managing. Really fairly sure is GPUMax issue now. I still get blocks of stales from eclipse but never 13 in a row rejected. Some number interspersed are always accepted. More like what it shoudl look like.
I still have the occasional 2-4 rejects and accepted another reject then all accepted. I always assumed it was actually current work as I don't leave debug on but It is possible that I still had one more late work left to submit.

[dave3]

Confirm, I hardly get any nmc too. So what? Its like 0.4btc a month for me.

I agree it's not enough to be a big deal, but I thought it's worth mentioning.  If it's a problem, probably good to get it on the to-do list before the diff10 or variable difficulty stuff gets rolled out to everyone.

[LazyOtto]

Inaba, I don't believe you are paying out transaction fees. True?

If so, do you have plans to add this?

Not much now, but twice as relevant in about three months.

[Inaba]

I think there's a problem with the diff10 server and NMC I just noticed I have been receiving less as well.  I think I found the bug and it should be fixed now going forward, I am sorry about that.

With regards to transaction fees, I will look into that when it becomes a significant issue.  Right, it averages about .1 BTC per block, perhaps a bit less, so it's one of the ways I can keep from having to charge a fee.  Between that and donations, the pool gets around 0.4% of each block, but when it starts becoming significant and impacting miner income noticeably, I will probably switch over to paying some portion, if not all of the transaction fees, yes.

[DobZombie]

I trust Inuba will do whats fair

Inuba, do you mind posting on the first page ALL the different servers.  I noticed pacific rim isn't on the list. It took me HOURS of trolling thru the forums to find it.  my connections to the server has been heaps better since I've been using it.

[Inaba]

PACRIM and EU both currently point to one of the US servers (I can't recall which off the top of my head).  I plan on putting up a new PACRIM server in Japan or such, I just haven't gotten around to it as of yet with everything else going on.  I want to get the variable difficulty in place and working flawlessly then I will put up the new PACRIM and EU servers, no sense in doing the work twice.

[Epoch]

Inaba, I noticed something strange about the 'Luck' display on the 'Block History' page. Take for example the following 2 recently-solved blocks:

block 197059, shares 2170260, luck 41.1%
block 197045, shares 1643689, luck 50.99%

The current difficulty is 2440643 so I would expect any block with shares less than 2440643 to display a luck above 50%. Taking block 197059 above as an example, that block had only 2170260 shares (i.e. less than difficulty). It was thus a bit 'luckier' than average. So its luck value should be above 50%, yet the website shows it as 41.1%.

Also, taking a look at the 2nd example above (block 197045), it shows its luck as being only 50.99% ... yet it only had 1643689 shares ... its luck value should be significantly higher than 50%.

It almost appears as if the luck calculation is being based on a lower difficulty than the current 2440643, perhaps something around 1650000. Unless I'm misunderstanding something here (which is quite possible).

[Inaba]

Luck is defined as "What percentage of blocks are longer than this one."

It used to be defined as "Percentage of shares from the target," but people convinced me to change it wayyy back in the double digit pages.  I'm open to other suggestions, of course, but that's what everyone agreed at the time was the best measure of luck. 

[Epoch]

Luck is defined as "What percentage of blocks are longer than this one."

It used to be defined as "Percentage of shares from the target," but people convinced me to change it wayyy back in the double digit pages.  I'm open to other suggestions, of course, but that's what everyone agreed at the time was the best measure of luck. 

Yes, the above has been my understanding as well. Thinking this through again, I was going by the false assumption at exactly 1/2 of the blocks would be smaller than 'difficulty' (2440643), and 1/2 would be larger, which was my mistake. It makes sense now, thanks.

[Inaba]

Ok, so I have a variable difficulty server up and running.  Before I make it public, though, I want to ask everyone what they think:

Currently, on the my workers page, it lists the actual number of shares submitted.  That's fine on a static difficulty, where, for example, a 10diff share is worth approximately 10 1diff shares... so it makes sense.  But on the new server, and going forward, as you mine your difficulty is adjusted dynamically... so over the course of an hour you might send in 10 2diff shares, 7 5.4423diff shares, 25 6.44321343diff shares, etc...  So it makes a direct comparison meaningless.

Since EMC is the first to implement this, we can effectively define the de facto standard on how to display this.  That said, my first thought is to just take everything to the lowest common denominator and display everything as 1diff shares and effectively ignore the number of shares submitted at a given difficulty.  That would be used strictly behind the scenes, but for all intents and purposes, all display GUI information would be quoted in 1diff. 

Who's got comments?  Let me hear them!