Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 44. (Read 499791 times)
October 23, 2012, 09:20:48 AM
Are the unconfirmed fixed now?
October 23, 2012, 06:48:46 AM
broken for a few weeks, ive had 0.14167454 unconfirmed nmc for 2-3 weeks i think lol
October 23, 2012, 06:46:55 AM
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?
October 22, 2012, 11:00:58 PM
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.
October 22, 2012, 07:25:19 PM
Everything seems to be up and running at the moment. Are you still having issues?
October 22, 2012, 07:03:48 PM
No problems today with US1
October 22, 2012, 08:28:42 AM
I am having problems connecting to US1. US2 seems to be working fine for me though. Anyone else having the same issues?
October 21, 2012, 02:06:13 PM
Earlier US1 showed my worker offline but was still accepting shares and my hash rate was at 9999. Working fine now.
October 21, 2012, 01:40:55 PM
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?
October 21, 2012, 01:29:56 PM
Everything appears to be fixed now.
October 21, 2012, 01:06:27 PM
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.What's the deal? CGMINER 2.4
I have 10 or so machines that are fairly useless right now.
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 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]).
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:
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: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.[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 can't do much about either of these, but I thought I would bring them up in case anyone who could might want to.
"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).
October 21, 2012, 01:00:34 PM
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.
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.
October 21, 2012, 12:45:47 PM
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.
October 21, 2012, 12:41:52 PM
Ok... I think I have everything moved. Please report any errors.
Last activity on miners is off by some hrs.
October 21, 2012, 12:27:58 PM
I have a few NMC which are not confirmed for weeks. Acc: yxtyxt
October 21, 2012, 12:22:45 PM
Ok... I think I have everything moved. Please report any errors.
October 21, 2012, 10:05:06 AM
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.
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.
October 21, 2012, 03:16:05 AM
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. October 20, 2012, 11:24:19 PM
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.
October 20, 2012, 10:22:36 PM
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.
Jump to: