So if I mine at I'll say for sake of argument 1Ghs and some guy is mining 2Ths our shares can be the same based on who finds what. So from what I read there, the bigger miners just have a difficulty advantage for keeping a server stable.
On anoher note, I think for me I'll just keep all the default settings (diificulty etc.) minus the warn threshold I set of 300 per worker / stick which I think is ok for ASIC's advertised at 333.
What is the sway on these things anyway, assuming someone knows. Like I know they will flucuate a few pts from advertised based on temp etc. but to really nail down a problem with a specific ASIC. What would a optimal threshold setting be assuming it's not the 300 I have set assumin a person has good cooling which I'm still thinking on ? I'd hate to lose 4 USB slots / 1.2Ghs just to use 4 USB fans on a 20 port hub.
Edit: Hey Doc, got to thinking... people always say as the dificulty grows that only the big miners will be "profitable" that said. Doesnt what I said before sort of hold true. Since it will come down to upgrade, get out or just live with it ?
your share is 1gh out of 270th . my share is 44gh out of 270th so my payout is 44x bigger then your payout. as to wanting more gh it all depends on the price you are paying to get it. and the power that it uses… blue fury and red fury usb sticks are nice but they cost a lot up front and are hard to setup. yah, but if you read exactly what he said then his (FIRST) statement is true. i have no clue what the second one is saying re: if it's variable difficulty (is it? i dunno), his difficulty 100,000 share will have just as much value as anyone else's difficulty 100,000 share.. it'll just take 2000x longer to get them, based on the 2TH example |
|
|
|
Indeed situation has been improved since commit  At the day of patch release, p2pool was on 36 TH/s with 161k share diff. Right now it's on 50.6 TH/s with 171k share diff. That's 40% hashrate increase with only 6% sharediff increase. Very nice surprise for small miners But we need more people to upgrade, so variance for small miners will go down even further. Please upgrade! Is the hash rate increase due to multipool.us hooking up to p2pool? Or does it not show on the p2pool graph? It likely is. Their address is 146197ntzrBT41DDQRrB2STBb19dw7ct2F, the highest hashrate of all miners. it's only at 90% efficiency, hoho Maybe point this to them? If you know of a way to improve efficiency.  I didn't snoop around & couldn't see an easy way to get the list of peers he's connected to & how many (outgoing/incoming) & where his shares are coming from atm, so not sure ed: oh, not sure what the sample size is either, it could just be luck & getting a lot of shares directly before a new block hits the network good example being 195.72.200.193's two orphans |
|
|
|
|
probably blocked a range of IPs
unless you did something specifically
|
|
|
|
|
Oh, there's also at least a dozen peers connected to me that essentially never send data, just receive it.
re: connected at height 0 (or sometimes -1) (and no they aren't downloading the blockchain, heh)
|
|
|
|
2013-11-07 23:00:12 receive version message: version 70001, blocks=0, us=127.0.0.1:8333, them=127.0.0.1:8333, peer=88.198.17.xx:42873
2013-11-07 23:09:17 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-07 23:09:17 ProcessMessage(ping, 0 bytes) FAILED
2013-11-07 23:18:37 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-07 23:18:37 ProcessMessage(ping, 0 bytes) FAILED
2013-11-07 23:27:38 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-07 23:27:38 ProcessMessage(ping, 0 bytes) FAILED
2013-11-07 23:36:58 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-07 23:36:58 ProcessMessage(ping, 0 bytes) FAILED
2013-11-07 23:46:18 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-07 23:46:18 ProcessMessage(ping, 0 bytes) FAILED
2013-11-07 23:55:38 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-07 23:55:38 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 00:04:58 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 00:04:58 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 00:13:59 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 00:13:59 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 00:23:19 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 00:23:19 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 00:32:19 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 00:32:19 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 00:41:40 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 00:41:40 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 00:51:00 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 00:51:00 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 01:00:20 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 01:00:20 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 01:09:21 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 01:09:21 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 01:18:41 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 01:18:41 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 01:28:01 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 01:28:01 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 01:37:21 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 01:37:21 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 01:46:42 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 01:46:42 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 01:56:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 01:56:02 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 02:05:22 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 02:05:22 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 02:14:22 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 02:14:22 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 02:23:43 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 02:23:43 ProcessMessage(ping, 0 bytes) FAILED
2013-11-08 02:33:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-08 02:33:03 ProcessMessage(ping, 0 bytes) FAILED
9m or 9m20s between each, started after node @ 88.197.17.xx connected. Didn't have any other of these messages in the prior 15 hours or so of log. used tcpkill to kill that connection and nothing in 20 minutes now. showed up as: "addr" : "88.198.17.xx:42873", "addrlocal" : "xxxxxxxx:8333", "services" : "00000000", "lastsend" : 1383878216, "lastrecv" : 1383878203, "bytessent" : 1501084, "bytesrecv" : 99201, "conntime" : 1383865212, "pingtime" : 0.00000000, "version" : 70001, "subver" : "/BQS:0.0.1/", "inbound" : true, "startingheight" : 0, "banscore" : 0 |
|
|
|
Indeed situation has been improved since commit At the day of patch release, p2pool was on 36 TH/s with 161k share diff. Right now it's on 50.6 TH/s with 171k share diff. That's 40% hashrate increase with only 6% sharediff increase. Very nice surprise for small miners But we need more people to upgrade, so variance for small miners will go down even further. Please upgrade! Is the hash rate increase due to multipool.us hooking up to p2pool? Or does it not show on the p2pool graph? It likely is. Their address is 146197ntzrBT41DDQRrB2STBb19dw7ct2F, the highest hashrate of all miners. it's only at 90% efficiency, hoho |
|
|
|
BDB0055 illegal flag specified to DB_ENV->open
config still fails at this, have to manually edit it |
|
|
|
|
Overlaps a bit; I have a relative in Austin that's savvy enough that I'd trust to purchase in my stead.
Would want to be able to see that it works before making final purchase.
I'll pay $2000 cash for it, no money orders, cashier's checks, or any of that bs.
Yes, lower than what a lot of people would offer, but most people wouldn't drive over to a stranger's house with $2000 in cash on their person, either
|
|
|
|
agreed. but maybe he thinks i'm selling one for $60? i dunno. |
|
|
|
So nice it has been implemented already. But I will agree with comments made earlier on, it should be applied to miners with 500 GH/s (1.7% of total p2pool hashrate). Please reduce it to at least 2% from 5%. It's a simple fix, and it will help a lot to small miners.
From experience, having "only" 2% of the p2pool hashrate doesn't mean there's too much variance (the rewards oscillate +/-~10% around). With 5%, ~20 large miners can take most of the pie, leaving crumbs to others. With 2%, this is raised to 50 large miners. I'd be OK with a 1% limit, but 2% should limit complains of high variance from large miners (the reward may even move as much from the hashrate fluctuations of the whole pool as from the share frequency variance, people with 5% or more may be able to confirm this if they have variance around 10% in their rewards too). BTW: I've not looked into the code, what would happen if there were only 10 miners on p2pool? Is the current algorithm able to converge on sane values or would the current 5% target raise the individual share difficulty without bonds. From the one-liner extract above it seems there's a missing parameter to achieve this protection (the number of distinct addresses with valid shares in the recent sharechain). I will decrease the percentage then. Maybe 1.67%? That's a share every half hour. If there are very few miners, nothing insane happens. Each miner's share difficulty multiplier becomes the maximum, 30, and then the 30-second share period target decreases the minimum difficulty until there's a share every 30 seconds again. Has this been implemented yet? I'm considering turning my node back on to see if it improves anything.....  Any news yet? yeah, it's in a git commit from 3 or 4 days ago |
|
|
|
I'll give you what it'll be worth if/when it actually/eventually arrives........BTC0.4
score! |
|
|
|
Local p2pool node for about an hour.
Just set it up so I haven't verified the whole p2pool chain yet, not sure if that matters...
hmm, the numbers don't add up with your HW errors. are those just not even submitted to the pool? i would like to see it on an existing p2pool node, lenny's is fine if the latency is too high there, you could try nogleg.net or zevus.nogleg.com and I'd give you any BTC back if it actually did take a fee, those are in US rather than Europe |
|
|
|
I sell gigabyte for 2.5 btc 7970 + shipping
that's more than they cost new, by several hundred $ |
|
|
|
|
I'll give you $60 for it, which is way more than it's worth, offer good for 48hrs
|
|
|
|
|
I doubt it
I could do local pickup in Houston, though
I went down there with >$2000 cash about 18 mo ago to pick some stuff up, lol
|
|
|
|
For sale KnC Saturn
Hashing speed ~240Gh/s. Used 1 day - new. 2 of 6 units left. Price 2400$. All details here!
this was a very fair price but i bet you could have gotten $3000/ea+ from the nutters |
|
|
|
well, it was kept artificially low, it should have gone to 540m or so, though i don't really see how it's such a profitable strategy. possibly for a company that sells ASICs |
|
|
|
OK, fees aren't mandatory, but these aren't the days where your 0 fee non-priority transaction will get processed unless you have a pre-arranged agreement with some pool or have a sufficient amount of mining power yourself to find a block What if the .0003 BTC really becomes worth something some day? Then the standard fee would be lowered, I'm sure |
|
|
|
The blocks are just rolling in this morning.
bitmeme's first place was beginning to look secure - that hash had been sitting first for some time. But from out of nowhere comes KPR120, a miner with 30 GH/s hashrate, taking over the lead.
Is it the revenge of the small miners? Can a Butterfly Labs Little Single beat piles of the fastest ASIC devices in the world? Is mining just one big lottery? What's happening!?!?
500MH/s inc, everyone should be quaking in their boots |
|
|
|
The situation is usually more complicated (which is why people often don't agree here on what is enough/good for p2pool: they have widely different situations to compare).
getblocktemplate latency isn't much of an issue if you have a multi-core CPU and your system workload leaves at least one core free for p2pool even when bitcoind is hogging one core.
It's clearly a problem when you don't have this free core (p2pool slows down and your efficiency dives).
A 512k DSL is clearly enough, but this assumes you don't use it for anything else that makes your link latency rise.
If you can setup QoS on your DSL and eliminate the influence of other traffic then clearly you can use p2pool on a DSL link. Unfortunately it's often not simple to do: some routers actively shape the traffic the way they want without letting users have much to tune or making the rest of the traffic too unreliable.
Even with a decent knowledge and control of the QoS settings you can have problems. For example I shot myself in the foot once, my QoS settings were perfect for bitcoind and p2pool but they caused timeouts repeatedly in my irc client.
I made my statement based on my observations. I have roughly 3mb down/768kb up connection. I found from observation of using my own p2pool node over a period of a few weeks that my lowest stales occurred when I had no port forwarding turned on for bitcoin or for p2pool. Even then it wasn't acceptable to me, as this isn't a dedicated link. Download something and watch your stales/dead rate go through the roof. I tried turning on qos, it made everything else unacceptable. Now with the newer version of p2pool and ridiculous difficulty, for someone like me with ~12gh/s hash power, having that one share I get in an 18 hour period go stale is awful. Probably wouldn't be so bad if you had 10x my hashrate, so I probably should have clarified my statement. I thought I was responding to someone using about the same hashpower as me. M I have 25/2 bonded DSL and even uploading at 50KB/s on this piece of shit slows my connection down. I have a server up right now that I'm not mining on, so I don't really care about it (and it gets shut off when I'm doing anything important). QoS is PoS |
|
|
|
|
Show Posts
