i am probably doing something wrong, but i cant sniff anything from my datacenters.
What does tcpdump show? Run it briefly and then terminate. Take note if there are any packets filtered by the interface - this would likely indicate that there is a lot you could be sniffing but don't have your server configured correctly.
This is exactly what I am working on for YACMiner (which does scrypt, n-scrypt, and scrypt-chacha) - the server specifies the algorithm and the parameters, and the miner switches to that.
Awesome - look forward to seeing your implementation. I recall seeing a few of your github commits before.
It's a lot more complicated on the miner side as the way cgminer/yacminer et.al. are written is to initialize for an algorithm one time when the program starts. It's taking a lot more re-engineering than I anticipated to get to a point where the algorithm can be specified at the pool level even initially, let alone after the program is already running.
Ya, requires multiple kernel support, kernel loading/unloading. And very likely a re-write of the config system to support multiple card configs for different algorithms.
I've got hte details in the plan on the wiki for YACMiner, and if there are any coders who can contribute, there is a fork that has the work started, otherwise, it might still take another month with the limited time I have. The other part that needs to be addressed is the different parameters each card needs for each algorithm and the N factor as well are all going to be different.
Ya, I would say anytime you need a different kernel, you probably need a config. In an ideal system, right now I could see having a separate GPU config for scrypt(1024, 1, 1), scrypt(2048, 1, 1), scrypt(4096, 1, 1), scrypt-chacha([various n]), and sha3 kekkek. Imagine being able to hot-swap between kernels like that. Of course, a pool utilizing this would need to take into consideration the (potentially heavy) time cost of loading/unloading kernels, and a slower "shifting" pool that prefers to leave miners on the same algorithm would probably make sense.
I keep meaning to look into a buffer size implementation I saw recently - removed the need to specify thread-concurrency, and sounded beneficial/more accurate. Need to find that branch again and do some testing soon.