Topic: [DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too - page 231. (Read 1601343 times)

is this permanent?

UPDATE:

Please use pit.deepbit.net as the hostname in your miner settings instead of deepbit.net

This depends on your timezone :)
Initially I wanted to implement failure detection by monitoring submitted shares, like it's done now for making worker name red, but then we decided that this may generate some false alarms due to randomness of the process, so now i'm replacing this system by another that will watch over getwork requests, not the shares.

No, the pool was not down today.
This may be caused by a connection problem at your side or switching to PPS mode.

FWIW - it seems that now that the Internet rush hour is largely over, things are looking up.  Still, no congestion going to Great Britain [England actually], just via the Comcast router leading to the France to Germany routed indicated before.

Now I am seeing some better numbers which included that difficult period from earlier:

2101 (0.38%)
1811 (0.39%)

One step ahead of ya, It's already on a network harddrive now, And the HDD is in in a bay, Wich is connected to an APS now i only need to worry about my lan cable falling out.

So Tycho said he'd comment about hte eta on the email notify system within 16 hours, I wonder if it'll be tonight or tomorrow morning

Comcast intentionally keeps their traffic on-net for as long as they can. And last I checked, BGP didn't react THAT fast.

Ha!  Well, I doubt they are the one saturating Comcast .. way to many connections to the major U.S. backbones to throttle one Comcast router where BGP would likely balance it nicely ... funny none-the-less

http://en.wikipedia.org/wiki/111_Eighth_Avenue

Holy crap it's Google... 2.9 Million square feet of Google.

OK, I will bite ... what is at 111 Eight Avenue [presumably in New York City]? 

I recommend that you get Diskeeper 2011 Premier; they have a full featured trial.  This is  not a plug beyond that I have used it for years [and swear by it] and will completely avoid this problem forever.  Get the SSD extension for those of you [like me] that boot the OS and programs from the SSD and store data and swap on hard drives [granted, I have 12GB of tri-channel RAM on my machine, so, I rarely see much use of swap [although a relatively large file is reserved of course].  Scheduled defrag [especially on Windows XP], is terrible.  It is best to keep the OS from fragmenting the data in the first place when practical [and clean up when it has too].

[EDIT] Even with an admittedly small sample (would like several thousand) and while I have uTorrent running grabbing the latest Debian 6.0.1a DVDs [all 8 DVDs, although I personally will probably only need the first one or two].  You might find it interesting that both miners are have the same percentage loss ... although that is likely somewhat coincidence.  It definitely could be worse.

1205 (0.66%)
1054 (0.66%)

And all that research and the loss is fairly similar to what I have been seeing with BTCMine.com lately [nearly the same number of long-polling pushes obviously].  I ran the same tests, but found absolutely no packet loss.  Used the DSL Reports tool I mentioned on the first hop address on my traceroute for deepbit.net and it came up great with low jitter, 25-27ms latency from both servers used [West Coast and Central I think it was].  So, while the packet loss through New York is part of the problem, it seems like long polling isn't quite as good as it is reputed to be [or could be improved] ... still better than the alternative of not having it though.

I'm not surprised if 111 Eighth Avenue has some minor congestion. Though I'd also suspect any other possible route would be worse.

Fast is definitely NOT the issue.  I have a very stable, low latency and fast connection (22Mbps/5Mbps down/up TCP/IP ... not ATM or DOCSIS frames which would imply a slight lower effective speed].  Testing against most any site in the United States or Canada results in nearly perfect results, at least through the Comcast network.  However, there is an international route in play here.

You are in part correct that it is an Internet issue, but the issue isn't speed (throughput).  See the results below.  The issue is occasional packet loss along the route.

100 ping packet test
Ping statistics for 46.4.99.204:
    Packets: Sent = 100, Received = 91, Lost = 9 (9% loss),
Approximate round trip times in milli-seconds:
    Minimum = 144ms, Maximum = 188ms, Average = 155ms

WHOIS shows I am being routed to German from the US
role:            Hetzner Online AG - Contact Role
address:         Hetzner Online AG
address:         Stuttgarter Straße 1
address:         D-91710 Gunzenhausen
address:         Germany

Traceroute shows a backbone issue between deepbit.net in Germany and my host
Tracing route to deepbit.net [46.4.99.204]
over a maximum of 30 hops:

  1    14 ms     8 ms    10 ms  73.115.174.1
  2     9 ms    14 ms    12 ms  ge-9-1-ur02.hamlake.mn.minn.comcast.net [68.85.165.229]
  3    12 ms     9 ms    13 ms  te-0-3-0-2-ar01.roseville.mn.minn.comcast.net [68.87.174.70]
  4    22 ms    21 ms    19 ms  te-0-4-0-0-cr01.chicago.il.ibone.comcast.net [68.86.91.137]
  5    90 ms    57 ms    54 ms  pos-2-10-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.86.113]
  6    54 ms    56 ms    54 ms  pos-0-4-0-0-pe01.111eighthave.ny.ibone.comcast.net [68.86.85.22]
  7    54 ms    54 ms    59 ms  nyk-s2-rou-1001.us.eurorings.net [75.149.228.126]
  8   135 ms   167 ms   136 ms  nntr-s1-rou-1021.FR.eurorings.net [134.222.226.166]
  9   135 ms   136 ms     *     nntr-s1-rou-1022.FR.eurorings.net [134.222.231.154]
 10   141 ms   142 ms   140 ms  ffm-s1-rou-1022.DE.eurorings.net [134.222.229.30]
 11   144 ms   155 ms   156 ms  ffm-s1-rou-1021.DE.eurorings.net [134.222.231.141]
 12   147 ms   149 ms   148 ms  nbg-s1-rou-1001.DE.eurorings.net [134.222.225.26]
 13   147 ms   143 ms   143 ms  kpn-gw.hetzner.de [134.222.107.21]
 14   159 ms   150 ms   162 ms  hos-bb2.juniper1.fs.hetzner.de [213.239.240.146]
 15   150 ms     *        *     hos-tr1.ex3k7.rz14.hetzner.de [213.239.224.136]
 16   149 ms   152 ms   147 ms  j2.deepbit.net [46.4.99.204]

Trace complete.

Looking at the obvious points on the route, hops 5, 8, 9 and 10 are candidates due to large jumps and variation

Hop 5 - the largest variation and most likely candidate
Ping statistics for 68.86.86.113:
    Packets: Sent = 100, Received = 90, Lost = 10 (10% loss),
Approximate round trip times in milli-seconds:
    Minimum = 52ms, Maximum = 92ms, Average = 58ms

I checked for packet loss to hop 4 and it was clean [well, I lost 1 packet in 250 hops].  I would rather see this was at hop 5, since then it would arguably be an issue between Comcast and the connection crossing the Atlantic, but alas, it is a Comcast issue.

So, in this case, outbound communications from my miners to deepbit.net seem to be caused by a bad or overloaded Comcast backbone router in New York. NOTICE to Comcast users; it is most likely that nearly all connections to deepbit.net are going through this same router in New York and thus ALL Comcast customers are likely suffering the same issue.  This is not necessarily the cause however, but most likely the connection is maintained on the same route in both directions in this particular case. 

To there you have it, the issue does not seem to be deepbit as far as outbound goes.  I have no idea what inbound traffic from deepbit.net looks like since a reverse traceroute would be required along with ping results from each hop originating from deepbit.net.  Having said that; there is one hop that looks a little troubling and that would be 15 which looks to be one hop upstream of data center used by deepbit.net.

netname:         HETZNER-RZ14
descr:           Hetzner Online AG
descr:           Datacenter 14

So, any Euro customers, especially Germany or France, if you could do something similar, we can at least see if there is loss on your side of the pond   Looking through the hosting company's site, http://www.hetzner.de, I don't see any tools for doing a reverse traceroute ... so I have to leave that task to Tycho if he cares to do it.  A good example of a such a tool in the US that is connected very well as far as the US and Canada are concerned is from Giganews at http://www.giganews.com/performance.html#traceroute, but doesn't do the ping tests in either direction looking for packet loss.  Perhaps one of the better tools out there, again to one of two sites, is from DSL Reports at http://www.dslreports.com/pingtest.

So, perhaps a little overkill, but I did it to find out why the issue and it solidly points to a single network backbone router in New York owned by Comcast (arguably the largest single network entity in the world and one of the best maintained, especially considering their size).  They seem to have blown it on this one. 

I Use MSIa fan profiles aswell, My cards run at 75°aswell, I had the "schedualer" service disabled but a registry value stating "perform first defrag?" was never answer, So when the OS went to call upon the schedualer to tell me to defrag, It sat there looping with requests until it filled my ram, Once my ram was full, My comp went "yo dude your ram is full, This is bad" and then Qued a system restart, Wich could not be done due to no schedualer service, So it flooded the ram as much as it possibly could with requests, Until for somereason my OS lockup and stop responding, At wich point my cards continued to mine somehow (i assume) Whilst the auto tune profile didnt update fan speeds in relation to card temperatures, Causing the cards to "restart" at 110°
The othercard, (i assume) never reached 110 because it's Next Door Neighbour in the case "restarted" but couldnt due to full ram.
I only know this because this is what the event viewer has recorded.

Make the Internet faster.

Seems long polling notifications are coming a little too late in many cases.  Look at the following.

[28/05/2011 19:46:36] Result: b7e9b22d accepted
[28/05/2011 19:46:55] Result: c941723a accepted
[28/05/2011 19:47:08] Result: 6a3f8cad rejected
[28/05/2011 19:47:08] LP: New work pushed
[28/05/2011 19:47:15] Result: 5f8f3e8d accepted
[28/05/2011 19:47:53] Result: 3730a2cf accepted

Is there anything that can be done about this?

After a lot of testing, I am seeing the reject counts in poclbm and phoenix (1.48 anyway) seem almost identical [for any given pool]. 

Thoughts?

I have a problem where my internet randomly disconnects me and requires my computer to restart.  I'm pretty sad about it.   Any of you guys know a trick to tell the computer to restart when this happens?

Maybe an idle task or something?   Or I was thinking a batch ping file that ran every hour or something... Hmm.

Would I be correct in assuming that the pool was down for a bit today and that's why the rewards for about 6-7 hours were "none?"

Hello,

would be nice to see ETA on all other useful features! 

This is the "lastminer" scammer, back to its old tricks. Ignore it, and whatever you do - don't send it any BTC!