[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[fcmatt]

Just did a tracert to uswest and this came back... Doesn't look good to me, but not really sure if the timeouts are causing all of my stales or not (I did xxxx a couple things out). I am on ATT Uverse at 30+ mbps.  Could ATT have some network issues that are causing my stales?

Code:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    21 ms    21 ms    22 ms  76-216-52-2.lightspeed.xxxxx.sbcglobal.net [xx.16.52.2]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7    21 ms    21 ms    20 ms  151.164.103.236
  8    31 ms    29 ms    29 ms  cgcil02jt.ip.att.net [12.122.81.17]
  9    47 ms    47 ms    48 ms  ae3.chi10.ip4.tinet.net [173.241.128.29]
 10    78 ms    79 ms    80 ms  ge-7-0-0.lax22.ip4.tinet.net [89.149.185.222]
 11   213 ms   203 ms   202 ms  aiix-gw.ip4.tinet.net [173.241.129.186]
 12    78 ms    78 ms    78 ms  aiix-10ge5-1.cr1.lax3.awknet.com [67.220.95.14]
 13    79 ms    78 ms    78 ms  69.42.216.173

You do realize that you just told everyone that your IP is 76.216.52.2 right?  First of all your hostname from lightspeed has your IP as part of it.  Second you should x out the 3rd and 4th, or 2nd, 3rd, and 4th octets of the IP, not the first.

Now as for the timeouts, that is normal, those hosts just don't reply to ICMP packets.  Really you need to do a ping, on windows ping -t, let it run for an hour, see what sort of PL you have.

I highly doubt his IP is what you think it is. His Nat router shows up as 1.1. the 2nd hop should be his default gateway at the ISP.
The 3rd hop is that default gateway's next hop.

But what I do agree with is what you are saying about how routers act very odd when you direct traffic right at them instead
of through them. Sometimes using traceroute as a tool to look for loss does not work very well. Best to fire up a ping for 15 minutes
and then look for the percentage loss. If you see a huge amount of loss that is when traceroute works very well to see where things
are stopping. With all that said I would be pissed with a traceroute like that if that was my ISP. My customers would never tolerate
that crap.

And as for what software I use.. i am on win 7 64 bit, guiminer using pocblm and pheonix 1.5 with phatk 2.2. 5830s, a 5850, and 6950s.

[1714018719]

1714018719

[1714018719]

1714018719

[kano]

OK, but whatever you do, don't type "host 76.216.52.2"

[freedenizen]

I highly doubt his IP is what you think it is. His Nat router shows up as 1.1. the 2nd hop should be his default gateway at the ISP.
The 3rd hop is that default gateway's next hop.

That's true, I wasn't paying enough attention, it does reveal geographic proximity though that I believe they were trying to hide by adding xxxx to the fqdn

[mike85123]

yea  was trying to mask location, but not very well.  ran ping -t and only got 1 unreachable over 15 mins. trying to think what has changed from when i was getting sub 1% stales. frustrating...

[Knighty]

Been running off of BTC Guild for the last few days, really like the pool, even with my lowly 400Mh/s

[carlo]

my stales did also go up to 1.9% using uscentral ... dont know what happend the pool.

[staraptor]

ddos?  hash rate down ~25-30% across the board

[fcmatt]

everything looks good here except this monster round we are trying to solve. it really eats into
the 24 hour rewards for a day.

[mike85123]

Had an approximately 2 second block solve, US West didn't catch it in time.  I updated the aggression for server sync'ing already, but it still has a 5 second pause if a sync fails.  Since the round was so short, US West ended up sync'ing after the round was already over.  As usual, if a server shows 0 shares during a round, the calculation script stops for manual inspection in case something really bad happened.  When I woke up, I forced it to calculate the round and it caught up with the backlog after a few minutes.

I think this happened again!

[fcmatt]

Had an approximately 2 second block solve, US West didn't catch it in time.  I updated the aggression for server sync'ing already, but it still has a 5 second pause if a sync fails.  Since the round was so short, US West ended up sync'ing after the round was already over.  As usual, if a server shows 0 shares during a round, the calculation script stops for manual inspection in case something really bad happened.  When I woke up, I forced it to calculate the round and it caught up with the backlog after a few minutes.

I think this happened again!

i am not so sure. a 5 hour round is not that unusual when you consider the pool speed and the difficulty.
deepbit is more then double the size and they have 1:30ish rounds which means for us to have some 3 hour
rounds is normal on occasion and a 5 hour round an usual but totally expected event.

[kano]

... and it is easy to work out

Follow my link in my sig: http://tradebtc.net/bitprob.php

Enter the pool hash rate (currently 2068.14 for west)
Then enter a number of hours and it will tell you the chance of failing to find a block for that long.

4 hours gives: 1.5230%
i.e. one in about 65 blocks ...

5 hours gives: 0.5350%
i.e. one in about 187 blocks

[mike85123]

Had an approximately 2 second block solve, US West didn't catch it in time.  I updated the aggression for server sync'ing already, but it still has a 5 second pause if a sync fails.  Since the round was so short, US West ended up sync'ing after the round was already over.  As usual, if a server shows 0 shares during a round, the calculation script stops for manual inspection in case something really bad happened.  When I woke up, I forced it to calculate the round and it caught up with the backlog after a few minutes.

I think this happened again!

I was having the same issue with shares counting backwards, which is why I thought it was a similar issue.

[eleuthria]

A few people probably saw funny looking stats in the last 6 hours.  Yesterday I put up a 4th pool instance on US West since it has been getting a bit more load than Central.  4th pool worked fine, except I missed the rpcallowip in bitcoin.conf.  The pool found a few blocks, but the master server couldn't poll bitcoind them to get the txid/fees included in the block.

This has been resolved.  Due to the way the servers handle rounds, no round share data was lost, simply the rounds for found blocks are slightly jumbled in their confirmation counts.

[BkkCoins]

Question: My accounts stats often show variations in hash rate and lower than expected hash rates. According to Phoenix output on my miner I'm getting consistent, steady 295+310=605 MHash/s. Why does this vary so much on the account stats? Sometimes I see 515 MHash/s when Phoenix is telling me the same steady values at 605. Isn't this value just reported based on how quickly I complete shares and shouldn't that be a direct result of my rate, not affected by probability or other user's rates?

Note: my stales is always about 0.2% so it's not that.

PS. The ads on the site seem to be for real-world mining equipment a lot of the time. You'd get a lot more click-thrus if you could select keywords/ads suitable for tech people, eg. web hosting, amazon gpu deals etc.

[kano]

Any pool estimate of hash rate is based on your share acceptance rate.

Since finding shares is random and thus is only a statistically expected value, the pool's estimate of your hash rate will of course vary and may even vary widely.

Once you go from a single sample to the (statistical) population of the pool - then the total shown by the pool is quite accurate.

There is no obvious solution to this since the only way for a pool to know your real hash rate would be for your software to supply it.
Then if people were to not report that correctly, the pool's estimate of their full hash rate would come in to doubt.

Since the pools report their total hash rate and using share rate is actually quite accurate over the full population, it is certainly best to use that.

[BkkCoins]

I'm talking about my own hash rate not the pool estimate. Isn't a share a fixed amount of work, or MHash calculations?  (That's a real question as I'm not sure.) I thought for each share I submit I do 2^32 hashs (or something like that) and given the server knows time between shares submitted, shouldn't it also know the exact hash rate I maintain? But it always reports varying rates different from what the miner reports.

[kano]

A share isn't a fixed amount of work.

There is a statistically expected number of shares in each work unit.

For calculation example just assume there is expected to be 1 share per 2G Hashes.
Thus if you find 2 shares in every 2G Hash work unit it would actually assume your hash rate is twice what it is.
Thus depending on how often your hash rate is calculated from your share acceptance, it is normally expected to vary.

In case it's not obvious, a block is just a share that has higher difficulty.

Comparison: There is currently expected to be one block per 7755544.3780275 G Hashes - however blocks don't appear exactly every 10 minutes, in fact one pair of blocks this morning (141,798 & 141,798) were 42 minutes apart - thus if you used the appearance of those 2 blocks (42 minutes) to estimate the total internet Hash rate over those 42 minutes, your estimate would most likely be about 1/4 of what it really was.

[BkkCoins]

Ok. I mistakenly thought a share was a fixed portion we did and only at the block level it was probabilistic.

Seems the BTC calculators project 0.334 BTC/day whereas I just got 0.289 in reality.
On BitClockers I had three days below 0.190/day. I siwtched here as I figured BTCGuild, finding blocks more quickly due to it's larger size, would smooth out the variance more and provide averages closer to the projected values.

If the shares are also statistical then I guess I should expect some days that are also above the 0.334 projection.
(value based on 600 MH/s).

[PcChip]

Oh god.  Now solidcoins.  What's next ??

[fcmatt]

Oh god.  Now solidcoins.  What's next ??

I am not sure there will be any next ones. After 3 different scam artists creating new clones of bitcoin have come out...
people are going to run out of steam for them. There is only so many greater fools out in the world that have BTC they
want to trade for a forked clone's coins. I expect the idea will settle down for a while as these fade away into obscurity.

but on the topic of this pool mining BTC.. the pool is on fire. Great times.