Processing a proof of work server-side is just like mining, isn't it? In regards to the hashing operation that takes place - it just processes specified nonces and not random ones. I haven't really thought about it until now, but for a 1Thps pool, about how many nonces does it need to validate per second? I can see how a slow CPU would be a bottleneck, and I wonder if pool software could offload that processing to a video card - otherwise faster devices will trounce 'most any pool.
I haven't run the numbers, but if we assume that a dedicated server might be able to process perhaps 10mhps in a single thread (and that might be a bit high), is that enough to deal with (perhaps several) 1Thps miners flooding it with nonces to process?
Yes. Because a difficulty=1 share is approximately 2^32 hashes. Pool software likely isn't using anywhere near the optimizations that mining software uses to evaluate hashes, so lets say that it can only verify ~10 KH/s worth of hashes. That means it can verify 10,000 shares per second. This is a very rough number, since no pool has ever had to verify even close to that.
BTC Guild currently processes ~380,000 shares in 20 minutes, or 316 shares per second. If my 10,000/second number is accurate, that means BTC Guild could support ~31x the hash power it currently has, which is about 35 TH/s.
Now in this scenario, I'm starting to think sending out higher difficulty shares would be beneficial. The likely bottleneck would be DB access time (inserting 100k rows every 10 seconds in batches with my current software setup).
Historically, the biggest problems BTC Guild has had is pushing out longpoll connections quickly. When you starting having 4,000+ longpoll connections, it starts to bog things down on the server. Normally the bulk of those connections are to inefficient miners, so its very difficult to say just where the bottleneck will lie when dealing with highly efficient and very fast mining hardware.
