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

All cases of "None" are rounds that lasted less than a minute.  If you look at the number of shares submitted, they range from 1082 to 4021.   Think of how fast the high end users are hashing with all their workers.  Now, watch your miner and see how long it takes to actually get a share accepted.  Essentially, you submitted no shares before the round ended ... you were still working on your first share of the round.  If you are watching the output [i.e. like with Phoenix], you probably would see two lines in a row indicating a new long polling message.  That would be your "None" round.

If the rounds had any duration, say more than one minute or so (depending on your hash rate), then that might indicate something is wrong.  All that you show are 0h 00m which is clearly short enough where you wouldn't have submitted a valid share.

BTW ... those shares are total for the round, not total that you submitted for the round.

Thanks, Karasur. 

i use it with two gtx460 (gpu in 905mhz), have 72-73mh/s each (windows 7x64 & guiminer - v2011-05-21)

Hey all,

Is the rpc-cuda miner ok to use with deepbit.net?

I've been trying to get it to work, and haven't received any troubleshooting responses yet from that thread.

Any help is appreciated.

Average hash rate in 1 hour  - 205 MH/s
Does it meen that i calculated shares but its not submitted? Why its marked in shares column then.


Some days ago i had a reward for even 3000 calculated shares and such problem started before new difficulty.
May be my luck has gone

Your miners didn't submit any shares for that block.

What is your hash rate as reported by your miner(s)?  Difficulty went up 78% today and maybe you can no longer finish a single share during a round?

Why there is no reward in generated block (proportional mode)?
Earlier there was some reward for such low shares (0.01***)

Yes, that's what JSON API was created for.

Tycho, I've got a program that checks for changes on a webpage and texts my phone if a criterion is met. Basically, it'll load my deepbit.net API token every 5 minutes and look for a nonactive miner.

Is this okay? I assume that this is one reason why you set up the JSON API.

Hey Tyco.

not to worry they all coming through now Sorry !!

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

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

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?

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

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?

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

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.

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

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.