Pages:
Author

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

hero member
Activity: 560
Merit: 500
broken for a few weeks, ive had 0.14167454 unconfirmed nmc for 2-3 weeks i think lol
hero member
Activity: 628
Merit: 504
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?
newbie
Activity: 32
Merit: 0
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.
legendary
Activity: 1260
Merit: 1000
Everything seems to be up and running at the moment. Are you still having issues?
full member
Activity: 150
Merit: 100
No problems today with US1
newbie
Activity: 35
Merit: 0
I am having problems connecting to US1.  US2 seems to be working fine for me though.  Anyone else having the same issues?
full member
Activity: 150
Merit: 100
Earlier US1 showed my worker offline but was still accepting shares and my hash rate was at 9999. Working fine now.
legendary
Activity: 1260
Merit: 1000
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?
hero member
Activity: 616
Merit: 500
Portland Bitcoin Group Organizer
Everything appears to be fixed now.
hero member
Activity: 807
Merit: 500
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 Smiley
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:
Quote
[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.
Wink

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).
hero member
Activity: 616
Merit: 500
Portland Bitcoin Group Organizer
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. Its not failing as it should. It would be better to shut down until you get it fixed so that a failover is possible.
legendary
Activity: 1260
Merit: 1000
So it is... time zone data on the new server was set to CDT and not UTC.  I fixed that, the DB should start populating properly now.
full member
Activity: 226
Merit: 100
Ok... I think I have everything moved.  Please report any errors.


Last activity on miners is off by some hrs.
yxt
legendary
Activity: 3528
Merit: 1116
I have a few NMC which are not confirmed for weeks. Acc: yxtyxt
legendary
Activity: 1260
Merit: 1000
Ok... I think I have everything moved.  Please report any errors.
legendary
Activity: 1260
Merit: 1000
Yeah, US1 is set at I think 30 SPM target over a 3 minute period, so that's about right. 

On another note, I am going to try moving the DB in a few minutes, so the website will go offline.  Mining nodes should remain up though.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Is vardiff on US1 not doing the vardiff dance any more? I'm stuck at diff 1 despite ~38 shares per minute.
Never mind, it just took a long while... But it seems to only hover between 1 and 2 where previously it would go 3-4.
legendary
Activity: 1260
Merit: 1000
Ok... I think I have the NMC thing worked out.  I was going to move the DB, but I think I will wait until tomorrow.  I don't' want to move it before I go to bed and wake up and find things gone all wonky, so I'll leave it until tomorrow so I can keep an eye on it.

full member
Activity: 226
Merit: 100
Hmm.. yeah something is wrong with the NMC. I think I have a clue where it might be.  I will get that looked at shortly and report back.


Much obliged.
legendary
Activity: 1260
Merit: 1000
Hmm.. yeah something is wrong with the NMC. I think I have a clue where it might be.  I will get that looked at shortly and report back.
Pages:
Jump to: