Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 749. (Read 4382801 times)

Nice. Bookmarked.

Yes but it tracert stops between router and gateway they will all time out... Is ISP blocking it. Ping is the same protocol... See why users give up? You didn't read the posts and your diagnostic is useless. There were 3 diagnoses and all 3 are useless.

1. You got disconected(user looked at the screen and see shares accepted)
2. Ping timeout means the problem is with you(completely different protocol that ISP sometimes block so really not)
3. Yours that I can't completely figure it up but I think it is DNS related...

Well nslookup was for the user to get the list of all ips. Ping each of them and find which one is timing out. Bear in mind that pinging stratum.bitcoin.cz may give you different ip each time from the list of assigned ips and not necessarily there is a problem with all of them.

Hi slushers

I have created a page with a couple of visualisations of the data from Slush's API, have a look if you're interested:
http://nicja.alwaysdata.net

Currently it just shows the progression of round duration, network shares per second, miner reward per block and average miner reward per hour per block over time.

You'll need to input your Slush API Token which you can find at https://mining.bitcoin.cz/accounts/token-manage/ This gets stored in a cookie which expires with your session, or you can clear it at any time.

Feel free to send any suggestions, although the possibilities are limited by the data coming from the API (only the last 30 blocks, no miner shares per round, etc.)

Cheers
nicja

Really? You feel the need to post answers without reading if the answer might exist? Blocked between router and gateway. You can also stop because the user with problems give up explaining on forum to persons who think that can help but just can't. What good would nslookup do? You will get list of IPs. Can you contact Slush to fix it if you have it? And if you would read you would know that this ping was pinging stratum.bitcoin.cz. So you have one.

Pool is loosing shares even if pool is responding that it accepted it(read above about cgminer). It is as simple as that and it is happening for days if not over a week now. This is from logs not just filling.

EDIT: And if it was DNS problem connection would be lost. Since this is not the case...

to find out where you are blocked, ping your local loopback, ping your pc ip, ping your router ip, ping your gateway, ping google dns. check at which hop you gonna get time out and address the issue.  Drop your ping output here and lests see what you get.

also can you post your output from nslookup for stratum.bitcoin.cz?

But other servers can be pinged!

This is 99.9% sure ISP blocking ICMP and nothing else... First clue was tracert not working...

Surely this is your issue as was posted earlier!

Just to be clear, when you see "Accepted" or "Rejected" on cgminer, it is not cgminer submitting it but after that when it gets the pool's response, so the pool has received and acknowledged your share has been submitted.

I can say I totally believe. I had same problems and given up on the pool. I was looking at logs of cgminer showing noting wrong but shares were missing.

Log looks like that:
 [2013-05-14 08:13:33] Accepted 9c18e33e Diff 1/1 GPU 2 pool 0
 [2013-05-14 08:13:35] Accepted efb855a5 Diff 1/1 GPU 2 pool 0
 [2013-05-14 08:13:36] Accepted 2d4f916a Diff 5/1 GPU 1 pool 0
 [2013-05-14 08:13:37] Accepted 854c4a6c Diff 1/1 GPU 2 pool 0
 [2013-05-14 08:13:40] Accepted 17474462 Diff 10/1 GPU 2 pool 0
 [2013-05-14 08:13:52] Stratum from pool 0 detected new block
 [2013-05-14 08:13:54] Accepted b0de7eea Diff 1/1 GPU 3 pool 0
 [2013-05-14 08:13:55] Accepted 6c49452a Diff 2/1 GPU 0 pool 0
 [2013-05-14 08:13:57] Accepted 6e920082 Diff 2/1 GPU 2 pool 0
 [2013-05-14 08:14:03] Accepted d448d5c4 Diff 1/1 GPU 3 pool 0
 [2013-05-14 08:14:07] Accepted c45369d9 Diff 1/1 GPU 2 pool 0

So seeing
 [2013-05-14 08:13:52] Stratum from pool 0 detected new block
means that you got data about new block and stratum sends data to you.
 [2013-05-14 08:13:55] Accepted 6c49452a Diff 2/1 GPU 0 pool 0
This means that pool accepted the share. It also means that startum is sending you work since you have only about 1 minute buffer.

I had all this in logs so pool did communicate and rsbriggs also saw this on screen. So it is time to accept that pool has issues and there is no Slush to fix them. Now I hope he is only on holidays but I'm afraid for some time that that is not the case and that something happen to him.

EDIT: I didn't have any disconnections like you. Just missing shares

EDIT2: Interesting thing. We had 5 minutes downtime with my primary pool. One miner jumped to Slush the other detected it as not working and didn't connect to stratum, stratum2, stratum3 or api and concted to my old backup pool. They are on same line with same network settings and it happened in about the same time that rsbriggs reports the problem. Guess load balancers???

I don't know cgminer well enough to tell you if "cgminer reporting submitted shares" actually means that the shares did indeed get submitted. Although it probably does.

I was rather trying to hint that it is possible that during this time your miner may have gotten disconnected (without you noticing), then got reconnected and continued to submit shares (at which point you may have seen it working fine). However you wouldn't know about that hour or two when it was trying to reconnect and didn't submit any shares. That's unless you were actually watching cgminer's performance during those two rounds - between 2013-05-13 20:21:17 and 21:07:59 server time.

It is also possible that Amazon's balancer moved the end node to which you were connected, and your computer or router had cached the IP or DNS data, and took some time to learn about the new IP and reconnect. I caught this exact case in the act - see https://bitcointalksearch.org/topic/m.2108291 - my miners lost connection and sat idle for a while without me noticing it immediately.

As for if we'll ever know for sure - I think you're right. We may never learn for sure what exactly happened.
We should rather take the lessons learned and start more logging, so that when it happens the next time we have a better idea of what might have gone wrong.

ah ... sorry ... I guess I should've mentioned that I'm pinging google.com (and not slush's site).

Although - the ping is a really insignificant amount of traffic - at 32bytes/sec that's just over 100kb/hr. Just the front page alone with all images is about 150kb, so loading that once an hour would generate more traffic than the ping for an entire hour. Not to mention that the ping request takes almost no CPU effort, causes no load on the web/http server, no load for the database, etc. It probably doesn't even make it to the server - most likely the router/balancer replies.
So - even if someone did ping the site non-stop - the site would likely not even notice it. (and by the way - you can be almost certain that people actually do that)

Last post of subject because not having friend here anymore with better english to write what I speak making me too much work.  Knowing miners  mining because of watching monitors and seeing cgminer going without errors.  Setting zero on display command when block change and watching accepting blocks count up.  It can be mystery without solution forever from this day to me.  Thank you.

Why are you doing that? The site is having enough issues with connectivity.

Don't get me wrong - I have no interest in providing you with misleading information (and for the record - neither a good one).

However, I didn't say it just because that's the way I like it - I was merely making an observation based on the facts (the btc awards that you got for each of those rounds).

A few questions for you - how do you know that your miners did actually work?
- did you check your miner for the number of shares submitted?
- did you check the web site for number of shares accepted?
- did the two numbers match? (or not?)
- At what times?
- What makes you think that you did have internet connection during that time? (for example - I have a DOS prompt with a non-stop running ping and 3000 lines buffer - that can tell me if something fishy happened recently; Aside from that several other logs and nagios alerts when things-that-are-not-supposed-to-happen actually do happen - I've caught my internet provider cutting my internet for hours at night when they think nobody will notice)

Sorry about this - your new and I hope you don't mind me correcting you:

1. The network hashrate is ~ 85 Thps, not the difficulty (actually, I reckon about 93Thps +/- 5%)
2. Because the network adjusts on a lagged variable, when the network hashrate constantly increases, Difficulty lags and more than 144 blocks per day are solved. Earlier in the year it got up to ~225 blocks per hour for a few days.
3. Calculate your expected income as: ( your hashrate ) / 2^32 / mining difficulty * (number of seconds in the time period over which you're assessing income - must be less than time before the next retarget, 2 weeks at most).

HTH

It almost looks like you lost connection. Judging by the leftovers of 18014 - looks like it probably happened about 30min before the end. And you stayed disconnected through the next two rounds (which were rather short ones - 10 and 36min) and then reconnected. For at least the last hour of 18017 you did have connection.

Disconnect?  дa чтo yгoднo - miners submitted shares whole time.  Meня этo нe вoлнyeт - just curiosity more than another thing.

Right now bitcoin network difficulty is at around 85 th/s from what I see. Avalon Asic = 66 gh/s or 1/1333 of that. Since 150 bitcoins are released every hour it would take you 9 hours to get 1 bitcoin. Since they are released in blocks of 25, you would need to wait ~9.4 days to get a single block... I would rather be paid regularly. If I had ~10 Asics though I would mine solo.

It almost looks like you lost connection. Judging by the leftovers of 18014 - looks like it probably happened about 30min before the end. And you stayed disconnected through the next two rounds (which were rather short ones - 10 and 36min) and then reconnected. For at least the last hour of 18017 you did have connection.