[DEAD] DeepBit.net PPS+Prop,instant payouts, we pay for INVALID BLOCKS too

[os2sam]

Where did the shares per block averages go on the stats page?  We're no where near a difficulty change.
Sam

[1576018485]

1576018485

[1576018485]

1576018485

[1576018485]

1576018485

[DeepBit]

Where did the shares per block averages go on the stats page?  We're no where near a difficulty change.

Sorry, it was caused by site update. Already enabled again.

[os2sam]

Where did the shares per block averages go on the stats page?  We're no where near a difficulty change.

Sorry, it was caused by site update. Already enabled again.

No problem.
Thanks,
Sam

[Eveofwar]

Where did the shares per block averages go on the stats page?  We're no where near a difficulty change.
Sam

Stats are delayed by one hour
Average shares per block: 1269163 (+9.4%)
Average in last 24 hours: 1364050 (+17.6%)

?

[RobertRibbeck]

I just watched several shares sent and show accepted by Phoenix 1.7.1
pool didn't count at least 3 of the shares

how can a accepted be sent back to the miner but pool total never counts them
I'm seeing at least 5% loss per day for the last month alone

I reported this behavior over a month ago
NO REPLY - NO ANSWER

hello !!!!!!!!!!!!!!!!!!!!!!

[DeepBit]

hello !!!!!!!!!!!!!!!!!!!!!!

I already sent you four PMs today, no need to add that many exclamation marks :)

Since you are experiencing this issue only with two PCs and only with phoenix, but not poclbm and I don't see any errors in your submissions, I can assume that it may be something caused my combination of the phoenix miner and your internet connection (or hardware).
I'll check my logs again tomorrow, may be I'll ask you to post sample share that was not accounted for (but not today, not ready to check it yet).

UPDATE: Looks like I found one possible reason. There may be a bug in the Phoenix miner that causes it not to check the allowed nTime rolling range, so on slow hardware this may cause some shares to be... well, almost valid.
This needs additional checking.

Currently the best miner is poclbm or poclbm-based GUIminer. Other miners may be sometimes a bit faster, but may contain some bugs.

[LightRider]

Getting a lot of errors recently. Problems with the site?

[DeepBit]

Getting a lot of errors recently. Problems with the site?

If you are talking about last ~4 hours then I noticed some hashrate drop, possibly caused by connection problems between DCs.
~2% of users were affected, but I don't know for sure yet what is the cause. Looking into this issue.
What kind of errors are you getting ?

UPDATE: Looks like the issue is resolved.

[jedi95]

UPDATE: Looks like I found one possible reason. There may be a bug in the Phoenix miner that causes it not to check the allowed nTime rolling range, so on slow hardware this may cause some shares to be... well, almost valid.
This needs additional checking.

Phoenix never supported nTime rolling, so this isn't possible. I added support for it to the backend in 1.7.2, but the miner core doesn't do anything with it yet.

[DeepBit]

Phoenix never supported nTime rolling, so this isn't possible. I added support for it to the backend in 1.7.2, but the miner core doesn't do anything with it yet.

Sorry, I got this info from slush and had no time to check myself yet.

[kitich]

Hello DeepBit. HNY )

What happened at 00:00? =)

Daily graph:
http://dl.dropbox.com/u/4553930/ff_hashrate_day.png

Weekly graph:
http://dl.dropbox.com/u/4553930/ff_hashrate_week.png

My local hashrate is at the same level than before 00:00. About 9.5Ghs. All workers are up.

[Hawkix]

I must confirm that I also experience about 10% reported hashrate drop since new year. Not sure if it is real hashrate drop (aka slower shares submissions), or just different formula for computing the number. Can you please check it?

[DeepBit]

Hello DeepBit. HNY )
What happened at 00:00? =)

Thanks.

Check this post: https://bitcointalk.org/index.php?topic=3889.msg669081#msg669081
Since another pool on the same DC reported similar hashrate drop I think that it was caused by some peering link suffered from attack or newyearing, but this lasted only a few hours and now it's normal again. Do you still experience this issue ?
Can you try reconnecting one of your miners and check if it's normal again or not?
Do you see any packet loss to pit.deepbit.net ?

[Hawkix]

I restarted all workers, but hashrate is still reported as low.

What is interesting, i cannot see any problems in the clients, no reports about disconnecting, empty work queue, etc.

The only wrong number is the last 10 minutes average hashrate, which is about 10% lower than it used to be for months. Surprisingly, when I counted number of submitted shares (reported on deepbit) and used that to calculate my hashrate, I got the correct, good-old number.

To me, it looks like someone changed the code for estimating hashrate.

[DeepBit]

The only wrong number is the last 10 minutes average hashrate, which is about 10% lower than it used to be for months. Surprisingly, when I counted number of submitted shares (reported on deepbit) and used that to calculate my hashrate, I got the correct, good-old number.

To me, it looks like someone changed the code for estimating hashrate.

That's strange. Yes, I noticed this 10% drop with my pool monitoring routines, but it only lasted for a few hours.
I just checked the rate estimation code, but there is nothing that can be affected by new year or absolute time and there were no changes recently.
PM me your login name please so I can check your displayed hashrate.

At least if your submitted shares number is the same, your income won't be affected.

[slush]

Phoenix never supported nTime rolling, so this isn't possible.

Not sure why, but some miners which were reporting themselves as "phoenix" already performed some ghetto-style ntime rolling. They were using one job for many minutes, only extending the ntime, which is corrupted behaviour (miner should ask for new job even when there's no new bitcoin block, to refresh his merkle tree). Not sure if it was done by unofficial patch floating on the Internet, but I implemented few workarounds especially because of such issues with phoenix.

[kitich]

Hello DeepBit. HNY )
What happened at 00:00? =)

Thanks.

Check this post: https://bitcointalk.org/index.php?topic=3889.msg669081#msg669081
Since another pool on the same DC reported similar hashrate drop I think that it was caused by some peering link suffered from attack or newyearing, but this lasted only a few hours and now it's normal again. Do you still experience this issue ?
Can you try reconnecting one of your miners and check if it's normal again or not?
Do you see any packet loss to pit.deepbit.net ?

There are no any network problems. All miners have been restarted. Hashrate monitoring from deepbits API still 10-12% less.

[DeepBit]

There are no any network problems. All miners have been restarted. Hashrate monitoring from deepbits API still 10-12% less.

Can you please check if submitted shares are accounted correctly ?

[kitich]

There are no any network problems. All miners have been restarted. Hashrate monitoring from deepbits API still 10-12% less.

Can you please check if submitted shares are accounted correctly ?

Ok. Just restarted one of the miner:

Now total shares:

1195261

How much time we need to test? =)

[DeepBit]

Can you please check if submitted shares are accounted correctly ?

Ok. Just restarted one of the miner:
Now total shares:

1195261

How much time we need to test? =)

Somewhere around 50-100 shares.
Just to ensure that 10% of submitted shares aren't disappearing.