Quote from: Matt Corallo on September 01, 2014, 05:07:58 AM

Quote from: hamburgerhelper on September 01, 2014, 04:39:50 AM

Ok, this was my line of thinking. But you took it waaaay further. For that, I applaud you!

I'm beefing up my peers with a slightly different strategy: sort the node list by uptime and use the oldest nodes with reasonable latency. I figure that the oldest nodes will have the deepest roots into the p2pool network. Ok, I hope we just didn't ruin our competitive advantage here...

This kind of approach rarely works. In fact, by simply decreasing peering within the relay network, relay times improved. Mostly, using this approach means your peaks (remember when a new block is found you get huge bandwidth peaks, even though amortized across even a second, you wont see all that much bandwidth) will be significantly higher, leading to strange things on the network, mostly increased packet loss. This means instead of getting a block pretty quick, you'll have to wait for the packet to timeout and get a resend. I would recommend finding only a handful of peers which are both geographically local and have high hashpower so you'll get blocks they found directly from the horse's mouth.

Matt, we're referring to p2pool peers, not bitcoin peers. I think that the p2pool blocks (the "shares") are very very small in comparison to bitcoin blocks. Since my node is the origin of the newly found share (the share is outbound to the rest of the p2pool network) it can only get out as fast as the maximum outbound bandwidth of my node - it seems to me that I want to try to hit that max (which in my case is 250 Mbps) so that there are many spokes to my hub (this seems to me to be hub/spoke topology in the first set of share transmissions, then it turns into a graph as the share gets retransmitted by my peer nodes).

Am I totally off base here? I'm not an expert on p2pool, I just read some stuff.