Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC). I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.
Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers. As you pointed out, DVC+IXC are virtually worthless. I'm not even sure if they're 0.1% actually. Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block. That will at least minimally impact bitcoind performance. How much? I can't say, and nobody else really can either. But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild.
I'm asking this because I don't know / understand not to be a pain:
Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal.
I don't know enough about the stratum protocol to know if that's even possible.
And no, I don't think it's worth the time to mine the other coins, but I do want to understand more.
-Dave
I'm not 100% sure here, but I think a lot of this comes down to just mitigating the sheer latency. To start with, it is my understanding that the second a new block is found, all the work that is currently being worked on for the old expires. So you lose clock cycles/bandwidth there, trying to send out new work to all the workers currently connected so that they are all working on the current block. Definitely don't want to be wasting clock cycles checking/updating work to worthless coins then. Also, when you find a block, you need to get this from the accepted share that found it, to the blockchain and broadcast it as fast as the server/network will allow this. Sometimes, a matter of a few fractions of a second could be the difference between a block being accepted or orphaned. Better to keep the resources available for the coins that are worth it than waste it on coins that are more or less worthless.
Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins. BTCGuild should be able to figure it out. I'd just like to see more feature parity with the biggest pool because I don't think the current system is going to get better on its own. If I were making some amount of my income based on how much market share my pool had, I would be looking for any way possible to keep that income reasonably high without exceeding a certain threshold that would endanger the network.
Pick ajax stats, split payouts, merged mining, something anything to close the gap. Just my 2 bits.
Yes, I am currently mining here because it is the most stable pool there is. I'm also mining here because I want this pool to survive. As the mining corporations gather more network share, more private miners will tend to consolidate to fewer higher hash rate pools to reduce their variance. p2pool and Eligius can survive because they don't rely on a fee to run. I'm just worried about BTCGuild eventually becoming an abandoned pool like a few others have. Maybe I'm thinking too far ahead or being alarmist, but I thought I would try to share my concerns while there is still a chance to do something about it. It really has much less to do with the income those coins would provide than it does with the perception of value the pool provides.