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

[The00Dustin]

Share became stale while trying to submit, discarding...

What's the deal? CGMINER 2.4

I have 10 or so machines that are fairly useless right now.

I'd say everyone is "getting what they deserve" for Inaba fixing the time instead of editing the web pages to show it right while the server kept it wrong.

I noticed two small issues this morning, one which would be easy to reproduce but doesn't necessarily need fixed, the other which would be difficult to reproduce but should theoretically be fixed for best performance (assuming my observation was correct).

Issue one is related to the use of system time, my mining machine was about 6 minutes slow, over the course of a couple weeks with ntp not running.  I started ntp and when the time changed, cgminer immediately reported "pool not providing work enough" and subsequently switched pools.  This probably wouldn't have happened if ntp was running all along, which is why I think it is a minor issue, but it makes me wonder if DST causes dropped work and pool failovers when they shouldn't exist.  Since that would only be a problem once or twice a year, I still don't know if this would be worth fixing, because I'm guessing it would be difficult to fix (would require a unique time source or some sort of interrupt to deal with known time changes on the existing time source [assuming either one of those is even possible]).

No - time always travels forwards - oddly enough
Daylight savings does not affect the internal storage of time, it simply displays it differently.

However, if you change the computer clock backwards or forwards (with ntp) - you get what you deserve.

Issue two is related to submission of stale shares.  Note that I did not have --submit-stale on the command line in this case, but I have previously seen cgminer submit detected stales to the pool because it was instructed to (pool is eligius).  This morning, I just happened to look at my miner while this was still on the screen:

[2012-03-23 08:22:53] LONGPOLL requested work restart, waiting on fresh work
[2012-03-23 08:22:57] Accepted 00000000.949b59d0.7ecd59ab GPU 0 thread 1 pool 0
[2012-03-23 08:23:03] Accepted 00000000.58e019ff.7a3bc657 GPU 0 thread 1 pool 0
[2012-03-23 08:23:05] Pool 0 communication failure, caching submissions
[2012-03-23 08:23:05] Stale share detected, discarding
[2012-03-23 08:23:07] Pool 0 communication resumed, submitting work
[2012-03-23 08:23:07] Accepted 00000000.ade4193a.07083649 GPU 0 thread 0 pool 0

I had recently restarted cgminer, so I can't be 100% certain cgminer was again instructed to submit stales, but assuming it was, I believe the discarded share above would indicate a bug in stale share handling in this scenario.  I also believe it would have been accepted based on the length of time between the last longpoll and this event and the fact that other shares were accepted before and after this one with no other new block event shown.

I can't do much about either of these, but I thought I would bring them up in case anyone who could might want to.

If you tell cgminer to submit stales it tells you explicitly that it is doing that:
"Stale share detected, submitting as user requested" before it shows the share Accepted/Rejected/whatever

If you don't tell cgminer to submit stales, then it will discard what it considers stale.
The thing to know about stales is that a work request is stale based on when it was received, not when you see it's share(s) shown in cgminer.
Cgminer threw away that share coz it wasn't told to submit stales and the getwork time implied the share was stale.
You can't assume the getwork order matches the share display order.

Edit: oops yes the pool can also tell cgminer to submit stales - forgot to mention that - as mentioned above.

ETA:  I post this tongue-in-cheek.  No hard feelings toward Kano, and no implication that this should have been fixed in cgminer.  It's just that I believe my experience applies here, and I find it humorous on a dark level.

ETA2:  I meanct to point out that the quoted problem will probably clear up when new work is requested or the miner is restarted (assuming EMC uses stratum and it behaves differently).

[1715369169]

1715369169

[1715369169]

1715369169

[SysRun]

Everything appears to be fixed now.

[Inaba]

US3 didn't like the move.  It's been fixed now though.  US2 and US1 should have been working fine though.  Is anyone having trouble with US2 or US1?

[poon-TANG]

Earlier US1 showed my worker offline but was still accepting shares and my hash rate was at 9999. Working fine now.

[duukat]

I am having problems connecting to US1.  US2 seems to be working fine for me though.  Anyone else having the same issues?

[poon-TANG]

No problems today with US1

[Inaba]

Everything seems to be up and running at the moment. Are you still having issues?

[xblitz]

Everything seems to be up and running at the moment. Are you still having issues?

i've actually been having problems going to the website itself from my home connection.. but i can connect to the pools...  it just seems to be the web service i cant reach..  but I can from work ..  and other friend on the same provider also works.. 

this is the resolved ip for eclipsemc.com: 96.43.135.180

im getting connection timeouts over port 80:
Connecting to 96.43.135.180:80... failed: Connection timed out.

[BlackPrapor]

Everything seems to be up and running at the moment. Are you still having issues?

Inaba, what's up with nmc unconfirmed thing? I've got like 1.5 hanging for a week now, is it working at all?

[Badonkadonk]

broken for a few weeks, ive had 0.14167454 unconfirmed nmc for 2-3 weeks i think lol

[Inaba]

Are the unconfirmed fixed now?

[Badonkadonk]

yarr its gone.

[EnzoMatrix]

Everything seems to be up and running at the moment. Are you still having issues?

i've actually been having problems going to the website itself from my home connection.. but i can connect to the pools...  it just seems to be the web service i cant reach..  but I can from work ..  and other friend on the same provider also works.. 

this is the resolved ip for eclipsemc.com: 96.43.135.180

im getting connection timeouts over port 80:
Connecting to 96.43.135.180:80... failed: Connection timed out.

Yea I am having the same issue connecting to the Site from my home connection but I can access the pool servers ok

[Inaba]

That's pretty strange.  Can you run a traceroute on it?

[xblitz]

That's pretty strange.  Can you run a traceroute on it?

here are a traceroute of eclipsemc.com and us1

Code:

linux~ # traceroute eclipsemc.com
traceroute to eclipsemc.com (96.43.135.180), 30 hops max, 60 byte packets
 1  orion (192.168.5.1)  0.162 ms  0.186 ms  0.220 ms
 2  * * *
 3  10.170.169.161 (10.170.169.161)  12.519 ms  12.529 ms  12.529 ms
 4  216.113.122.17 (216.113.122.17)  12.875 ms  12.881 ms  12.882 ms
 5  216.113.123.222 (216.113.123.222)  33.327 ms  33.337 ms  33.342 ms
 6  216.113.125.38 (216.113.125.38)  31.200 ms  31.104 ms  31.088 ms
 7  10gigabitethernet1-1.core1.mci1.he.net (72.52.92.2)  40.967 ms  35.352 ms  40.483 ms
 8  10gigabitethernet1-1.core1.mci2.he.net (184.105.213.2)  41.748 ms  41.417 ms  41.419 ms
 9  joe-s-data-center-llc.10gigabitethernet1-4.core1.mci1.he.net (216.66.79.14)  39.271 ms  34.789 ms  38.432 ms
10  DC2SW1.KCMODATACENTER.COM (96.43.134.38)  39.281 ms  41.079 ms  41.950 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Code:

linux~ # traceroute us1.eclipsemc.com
traceroute to us1.eclipsemc.com (208.110.68.114), 30 hops max, 60 byte packets
 1  orion (192.168.5.1)  0.153 ms  0.179 ms  0.217 ms
 2  * * *
 3  10.170.169.165 (10.170.169.165)  13.785 ms  13.800 ms  13.794 ms
 4  216.113.122.37 (216.113.122.37)  14.246 ms  14.256 ms  14.268 ms
 5  216.113.124.118 (216.113.124.118)  37.166 ms  37.188 ms  37.184 ms
 6  216.113.125.38 (216.113.125.38)  32.848 ms  32.736 ms  32.702 ms
 7  10gigabitethernet1-1.core1.mci1.he.net (72.52.92.2)  42.560 ms  35.772 ms  40.002 ms
 8  10gigabitethernet1-1.core1.mci2.he.net (184.105.213.2)  42.213 ms  41.771 ms  41.774 ms
 9  wholesale-internet-inc.10gigabitethernet1-3.core1.mci2.he.net (216.66.78.90)  39.527 ms  36.818 ms  51.145 ms
10  69.30.209.1 (69.30.209.1)  51.153 ms  46.915 ms  46.920 ms
11  us1.eclipsemc.com (208.110.68.114)  46.874 ms  41.374 ms  36.434 ms

[Inaba]

Try to US3 as opposed to US1.  Also send me you IP address via PM.

[EnzoMatrix]

Try to US3 as opposed to US1.  Also send me you IP address via PM.

Code:

Tracing route to eclipsemc.com [96.43.135.180]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2     8 ms     8 ms     6 ms  L100.DLLSTX-VFTTP-77.verizon-gni.net [71.97.84.1]
  3    11 ms    10 ms     9 ms  G0-9-0-1.DLLSTX-LCR-21.verizon-gni.net [130.81.129.46]
  4     8 ms    10 ms     8 ms  so-5-0-0-0.DFW9-BB-RTR1.verizon-gni.net [130.81.199.34]
  5     9 ms     9 ms    10 ms  152.63.4.13
  6   154 ms   222 ms   219 ms  te3-4.ccr01.dfw03.atlas.cogentco.com [154.54.12.205]
  7    78 ms   215 ms   220 ms  te7-1.ccr02.dfw03.atlas.cogentco.com [154.54.25.6]
  8    11 ms    14 ms    12 ms  te0-4-0-3.ccr22.dfw01.atlas.cogentco.com [154.54.82.29]
  9    21 ms    22 ms    21 ms  te0-3-0-6.mpd22.mci01.atlas.cogentco.com [154.54.46.213]
 10    26 ms    23 ms    19 ms  te2-1.mag02.mci01.atlas.cogentco.com [154.54.30.166]
 11    23 ms    22 ms    22 ms  38.104.86.74
 12    22 ms    22 ms    21 ms  DC2SW1.KCMODATACENTER.com [96.43.134.54]
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.

Code:

Tracing route to us3.eclipsemc.com [69.195.155.234]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     7 ms     7 ms     6 ms  L100.DLLSTX-VFTTP-77.verizon-gni.net [71.97.84.1]
  3    10 ms    10 ms    12 ms  G0-9-0-1.DLLSTX-LCR-21.verizon-gni.net [130.81.129.46]
  4     9 ms    10 ms     8 ms  so-5-0-0-0.DFW9-BB-RTR1.verizon-gni.net [130.81.199.34]
  5    75 ms    13 ms    11 ms  152.63.4.13
  6    12 ms     9 ms    10 ms  te3-4.ccr01.dfw03.atlas.cogentco.com [154.54.12.205]
  7    12 ms    16 ms    12 ms  te0-3-0-4.ccr21.dfw01.atlas.cogentco.com [154.54.82.17]
  8    12 ms    14 ms    12 ms  te0-1-0-0.ccr22.dfw01.atlas.cogentco.com [154.54.46.170]
  9    24 ms    22 ms    21 ms  te0-3-0-6.mpd22.mci01.atlas.cogentco.com [154.54.46.213]
 10    23 ms    21 ms    23 ms  te2-1.mag02.mci01.atlas.cogentco.com [154.54.30.166]
 11    21 ms    24 ms    22 ms  38.104.86.74
 12    61 ms    22 ms    21 ms  DC3SW1.KCMODATACENTER.COM [96.43.134.34]
 13    23 ms    24 ms    24 ms  69.195.155.234

Trace complete.

[Inaba]

I think we have a first ever:  Block 204499 ...  EMC orphaned itself. 

Two servers found a similar solution almost at the same time.  I guess that was bound to happen eventually, crazy though.

[zero3112]

wow some luck you have there

[HolyScott]

Is this the first pool to offer dwolla as a direct payout?