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

[[Tycho]]

Something that no other pool does :)  Although the number of blocks lost as invalid is pretty small all things considered.  Not sure the actual percentage of total payout affected, but looking at deepbit and other pools, I would say it is pretty rare [probably less than once or twice per week].  Tycho ... any idea?  Anyway, a great feature you offer (necessitated by the instant payout feature I suspect).

I think that in THIS case it was caused by a bug in my part. I'm fixing it.

[Veldy]

UPDATE:

Now you can lock your bitcoin address forever. Yes, that really means "forever" and there will be no way to unlock it.
Press the button at the very bottom of advanced settings page, check that confirmation e-mail contains YOUR bitcoin address and click the link.

If you do this, does this mean that you have to create a new account if you need a new address?  I just wiped out my old wallet and started a new wallet and changed my address for the obvious reason, so I won't be locking my address down.  As a collarary to your new feature; are you going to offer the option to delete an account?  It would help avoid stale accounts if one is forced to create a new account [and this would also allow one to use the same email address if you implement it that way].

[Veldy]

Something that no other pool does  Although the number of blocks lost as invalid is pretty small all things considered.  Not sure the actual percentage of total payout affected, but looking at deepbit and other pools, I would say it is pretty rare [probably less than once or twice per week].  Tycho ... any idea?  Anyway, a great feature you offer (necessitated by the instant payout feature I suspect).

I think that in THIS case it was caused by a bug in my part. I'm fixing it.

Awesome!   I mean, that you would say so, since you do payout invalid blocks and invalid blocks do occur, you didn't have to say so

[Veldy]

Actually rig is connected by cable, so there is nothing about signal strength. Rhis rig (and my mining career) started 15 days ago, first lockup 5 days ago and last one today. Of course there were other lockups of random pages even months before I started mining.

@Tycho
Making it really permanent will just create tons of PM's from ppl that lost their wallet file and want to change address, cuz of like 10 BTC on page acc

What locked up?  Your router or your mining software?  As for lost wallets; that is really up to you to keep that from happening.  I am sure most people keep a periodic backup in a safe and recoverable place [I even kept my old wallet when I replaced it].  If you are worried about losing your wallet [which you shouldn't be if you are doing as suggested many times in these forums and elsewhere], then don't push that button

[zapakh]

Quick props to Tycho:  I caught up on this thread from the beginning and didn't really expect your sanity still to be intact by the time I got to the end.  Keep up the good work!

[zimpixa]

@Veldy
By lockup I mean that page as well as miner can't reach server/site/whatever those two are connecting (not sure what exacly is locked in miner, but 'connection problems' appears). Meanwhile all other sites are working.

[[Tycho]]

Tycho - are you aware of any issues with Phoenix and deepbit?

Since Phoenix doesn't really suits my rigs I don't have much of a personal experience.
But I know that there was a bug that caused submitting a stale share after LP notice (may be already fixed).
And many users have reported that they see higher speed in Phoenix's console than in reality.

[[Tycho]]

Making it really permanent will just create tons of PM's from ppl that lost their wallet file and want to change address, cuz of like 10 BTC on page acc

It's for those who know what they are doing. And there is a warning e-mail that says clearly that it's permanent.
E-mail confirmation is not secure enough because e-mail accounts can be stolen, so I provided just an option for really concerned people.

And BTW, they should make backups of their wallet.dat

Now you can lock your bitcoin address forever. Yes, that really means "forever" and there will be no way to unlock it.

If you do this, does this mean that you have to create a new account if you need a new address?  I just wiped out my old wallet and started a new wallet and changed my address for the obvious reason, so I won't be locking my address down.  As a collarary to your new feature; are you going to offer the option to delete an account?  It would help avoid stale accounts if one is forced to create a new account [and this would also allow one to use the same email address if you implement it that way].

This is optional feature, just for those who want it.
Also i'm thinking about some SMS confirmation support, this may add more security.

[zimpixa]

To be honest sms confirmation will just generate costs. Ppl should rather secure by sending mined BTC more often than just waiting for them to be stolen in some way.

[minerX]

Veldy, here is my stale %.   Pheonix 1.48.

Are these high? Don't remember from when I was running straight Poc.

12785 (0.75%)   Prop.
13525 (1.00%)   Prop.
11948 (1.09%)   Prop.
11934 (1.13%)   Prop.
11840 (0.90%)   Prop.
13325 (0.75%)   Prop.

Also I've managed to get the same speed on Phoenix versus straight Poc.  There doesn't seem to be any massive difference in hash speed on deepbit either.  I'm using 30 minute average.

[Veldy]

Tycho - are you aware of any issues with Phoenix and deepbit?

Since Phoenix doesn't really suits my rigs I don't have much of a personal experience.
But I know that there was a bug that caused submitting a stale share after LP notice (may be already fixed).
And many users have reported that they see higher speed in Phoenix's console than in reality.

I am curious why Phoenix doesn't suit your rigs if you don't mind elaborating [and have the time].  It should work on any platform that has driver support for the OpenCL or CUDA hardware and where the python compiler and runtime can be built from source [if not available as binaries].  I am sure you have your reasons which is why I am curious.  

I can vouch for the fact that speeds are correct and always have been, although "rejected" count was off for awhile.  That has been discussed here before.  As for the long polling bug, I believe they fixed that in 1.3x sometime, but I know that it is supposed to be fixed in 1.48 in any event.  That doesn't mean it was fixed correctly or recently broken however.  What I find odd is that I am only seeing this level of rejects with deepbit.net [so far].  

I should note that I discovered something unique to my network, but perhaps somebody else has tried similar and should be aware of it.  I run the miner off of a mirrored share (meaning changes are copied immediately from the client machine to the share and to the other client machines nearly instantly and if the share goes down it will resync when it comes back up) and have noticed that when I start the miner on one machine, it recompiles one of the python source files, BFIPatcher.py and [re]creates BFIPatcher.pyc.  So, when I start the second miner, it does the same thing and overwrites the one just compiled.  This is in the poclbm kernel.  I am not sure why it recompiles every time since the source hasn't changed and the compiled file is newer than the source file.  I just pushed the tree to each machine so that it is NOT mirrored and am running that way and will report back if it makes a difference.  I can't imagine why it should matter (I don't have Python installed on either machine for what it is worth).  Apparently, the recompile is done after detecting hardware I am guessing based on the source comment, "Patches .ELF files compiled for Evergreen GPUs; changes the microcode so that any BYTE_ALIGN_INT instructions become BFI_INT.".  I am running 5850s and 6970s and don't think there should be any change required, thus, it shouldn't be an issue, but I thought it worth mentioning anyway.

[[Tycho]]

Veldy, here is my stale %.   Pheonix 1.48.
Are these high? Don't remember from when I was running straight Poc.

12785 (0.75%)   Prop.
13525 (1.00%)   Prop.
11948 (1.09%)   Prop.
11934 (1.13%)   Prop.
11840 (0.90%)   Prop.
13325 (0.75%)   Prop.

It's normal for Phoenix.
For poclbm I'll say that =< 1% is good, =< 0.3% is perfect.

[[Tycho]]

I am curious why Phoenix doesn't suit your rigs if you don't mind elaborating [and have the time].  It should work on any platform that has driver support for the OpenCL or CUDA hardware and where the python compiler and runtime can be built from source [if not available as binaries].  I am sure you have your reasons which is why I am curious.

I have a crossfireX setup with a combination of drivers+SDK that gives no additional CPU load, that's why I like it. With this version of drivers, only old poclbm can mine on slave cores of 5970, other miners will fail (not tested with ufasoft yet).
And it's hard to balance 4 instances of Phoenix on my PCs, some tend to suppres others.

[Veldy]

Veldy, here is my stale %.   Pheonix 1.48.
Are these high? Don't remember from when I was running straight Poc.

12785 (0.75%)   Prop.
13525 (1.00%)   Prop.
11948 (1.09%)   Prop.
11934 (1.13%)   Prop.
11840 (0.90%)   Prop.
13325 (0.75%)   Prop.

It's normal for Phoenix.
For poclbm I'll say that =< 1% is good, =< 0.3% is perfect.

I usually see less than 0.3% after several thousand shares.  Even with Phoenix except for with deepbit.  I am running another test now due to the noted recompile of one of the kernel source files every time you start an instance of Phoenix.  It is very important that network conditions are taken into consideration [if high latency between you and pool or connection loss, then the number will go up].

Even now with my low sample size for two miners:
252 (0.40%)
213 (0.00%)

[EDIT] Still not highly relavent sample, but:
734 (0.81%)
592 (0.84%)

It doesn't appear that Phoenix is doing too well.  I will let it go until later tonight and then reset the counters and switch over GUIMiner 2011-05-21

[EDIT 2]  I let GUIMiner run for awhile longer and the numbers got worse, not better.  Went back to Phoenix 1.48 and have the following results:
4779 (0.71%)
3773 (0.71%)

From what I can tell, Deepbit is a bit slow with sending a long polling push.  I suspect that may be because new blocks flow in too slowly to distribute to a large pool [hence the occasional miner idle message].  I base this "guess" solely on the fact that when I created a new wallet [wiped out my Bitcoin client and all folders] and installed it again, it pulled down the current block ... and it probably took the better part of a minute [maybe more or less, I didn't think much about it at the time due to the fact that I don't mine via the Bitcoin client].  That slow download speed may indicate that data is not available in time to send work to all the clients of such a large pool, which causes them to go idle.  I would further surmise that the long poll has been pushed out either by this delay or by changes in configuration by Tycho?  Anyway, that would explain the larger stale percentage than I see with other pools [usually less than 0.40% with BTCMine using Phoenix 1.48].

[Reckman]

Hi, I'm new to pool mining...Im using GUIMiner with m0mchil, I keep getting "Connection Problems" on one or two of my cards while the others are all running fine, I simply stop and start them and they connect fine...is there anything i can do to mitigate this?

[[Tycho]]

Hi, I'm new to pool mining...Im using GUIMiner with m0mchil, I keep getting "Connection Problems" on one or two of my cards while the others are all running fine, I simply stop and start them and they connect fine...is there anything i can do to mitigate this?

Look at the console and check what's the real error message is.

[Reckman]

Doesn't seem to have an error, it came up twice on miner 2.

I saw an article where people were restarting guiminer on a given interval, would this decrease realized hashes?

Code:

stener for "3": 25/05/2011 22:50:03, long poll: new block 000034477adba8b1
Listener for "1": 25/05/2011 22:50:03, long poll: new block 000034477adba8b1
Listener for "2": 25/05/2011 22:50:03, long poll: new block 000034477adba8b1
Running command: poclbm.exe --user=xx --pass=xx -o deepbit.net -p 8332 -d1 --verbose -v -w128
Listener for "2" started
Listener for "2" shutting down
Listener for "2": 25/05/2011 22:50:56, long poll: new block 00003288eaf4f43c
Listener for "3": 25/05/2011 22:50:56, long poll: new block 00003288eaf4f43c
Listener for "1": 25/05/2011 22:50:57, long poll: new block 00003288eaf4f43c
Listener for "1": 25/05/2011 22:52:16, warning: job finished, miner is idle
Listener for "2": 25/05/2011 22:54:41, long poll: new block 00000b451100fe2a
Listener for "1": 25/05/2011 22:54:42, long poll: new block 00000b451100fe2a
Listener for "3": 25/05/2011 22:54:42, long poll: new block 00000b451100fe2a
Listener for "2" shutting down
Running command: poclbm.exe --user=xx --pass=xx -o deepbit.net -p 8332 -d1 --verbose -v -w128
Listener for "2" started
Listener for "2": 25/05/2011 22:56:48, long poll: new block 00001275f1007c3a
Listener for "3": 25/05/2011 22:56:48, long poll: new block 00001275f1007c3a
Listener for "1": 25/05/2011 22:56:49, long poll: new block 00001275f1007c3a
Listener for "2": 25/05/2011 22:57:14, long poll: new block 000021e09808fe77
Listener for "3": 25/05/2011 22:57:15, long poll: new block 000021e09808fe77
Listener for "1": 25/05/2011 22:57:15, long poll: new block 000021e09808fe77

[Veldy]

Listener for "1": 25/05/2011 22:52:16, warning: job finished, miner is idle

I see this somewhat frequently myself with deepbit.net, perhaps a couple of times per day, but when it happens, there may be several of them over the course of 15 minutes or so [not sure since my logs are gone since it last occurred]. 

I will start this GUIMiner 2011-050-21 up in a bit and let it run through the night and see if I can catch any.  I suspect congestion at the pool though.  When I see the problem, I am having no issues with VPN [which I use for about 10 hours per day when I work from home] or any other service where it might be obvious (I have a known great connection on a low usage node with Comcast in all seasons ... not to say they don't occasionally have network trouble, but they haven't had any recently and are good year round ... seasonal environmental changes can very much affect errors, levels, SNR, etc).

Advice for anybody asking such questions.

• Check your home network equipment logs for issues/errors.  Especially if using wireless and even more so if not using 802.11n.
• Make sure your down and up link to the Internet are never saturated [pushed to max] unless you have QoS configured (next item)
• Prioritize port 8332 outgoing if your router supports QoS and also for WISH if supported and mining over wireless.
• Check all equipment.  Make sure cables are good CAT6 (or 5e if you must) with secure clips, Ethernet cards are good and setup correctly (i.e. 1Gb Duplex with a good chipset like the Intel PRO/100 GT ... which is old, but good).  Most on-board motherboard Ethernet ports are trash, but they still work; just be sure you configure your network to work with them (i.e. no jumbo frames if not supported)
• If your network devices and router support jumbo frames and you have the option turned on, make sure all mining hardware and equipment between it and your modem support it and have the option on and for the same size frame.
• Verify firmware is all up to date with the best available [not necessarily latest] for your router and DSL/Cable modem.
• Verify your cable or DSL modem statistics for proper power levels, SNR, correctable error rates (these are errors that shouldn't happen often at all), etc.
• Traceroute and ping to the pool server.  Try to obtain reverse traceroute if possible.

A long list and a lot of which some people won't understand all perhaps, but all things that can make a huge difference; especially when combined together.  Having one brand router, another switch, old cables, some auto-sensing this or that with what turns out to be somewhat incompatible chipsets, wireless and saturated internet connections on the down or uplink can all contribute to networking problems that can be difficult to diagnose for a home user.

This is why I recommended the D-Link DIR-655 (2.4GHz) and the D-Link DIR-855 (2.4/5.0GHz) routers [both with a five port switch].  There are other good routers of course, but I know these devices well and have used them for years [my backup DIR-655 is hardware version A2 which is quite old and hot, but still great and replaced by my DIR-855 ... I really do NOT like Linksys hardware since they remove all the higher end options from their higher end devices trying to get you to buy more expensive Cisco products ... Netgear is OK, but not my preference ... my opinions based on a lot of home hardware experience].

[vborets]

Veldy, which  hardware you use miners?  Which kernel for phoenix? which params?

[drgr33n]

Hey Tyco.

not to worry they all coming through now Sorry !!