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

[LightRider]

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

[1714312038]

1714312038

[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.

[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? =)

349 shares from phoenix

1195610 from deepbit, 1195610-1195261=349, seems to be ok.

[Hawkix]

I thing this "bug" may have something to do with the fact that I, after a long time, edited some details in my advanced settings. Maybe, the interval for hashrate is now calculated over different time, even that I never changed it and it still reports "10 minutes average".

[DeepBit]

349 shares from phoenix
1195610 from deepbit, 1195610-1195261=349, seems to be ok.

Thanks. So it seems to be a display bug after all.
Strange because there were no any changes in the code. Will try to find it...

I thing this "bug" may have something to do with the fact that I, after a long time, edited some details in my advanced settings. Maybe, the interval for hashrate is now calculated over different time, even that I never changed it and it still reports "10 minutes average".

Have you tried to check the more precise measurement in the history column or your stats in the team table ?

[Quantus]

I have noticed large variances in the "Average speed in last 10 minutes" displayed.

My miners show me running at a almost flat 850mh/s
but the site some times shows Mh/s as low as 450.
I restart and reset counters from time to time and I see no lost shares. But it dose worry me. Has any thing changed in the mining community in the last 60 days?

 I only started mining again in the last week. So I don't know if there was some update or new software that I mite need.

[DeepBit]

I have noticed large variances in the "Average speed in last 10 minutes" displayed.
My miners show me running at a almost flat 850mh/s
but the site some times shows Mh/s as low as 450.
I restart and reset counters from time to time and I see no lost shares. But it dose worry me

Large variance is expected within 10 minutes interval.
You can change your averaging window size in account's advanced settings. Try 40 minutes and numbers will be more consistent.

[Quantus]

Yes thanks that fixed it