Quote from: lagster on March 26, 2014, 10:52:22 PM

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.

Quote from: Thirtybird on March 27, 2014, 12:58:59 AM

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.

Quote from: Thirtybird on March 27, 2014, 12:58:59 AM

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.

Quote from: Thirtybird on March 27, 2014, 12:58:59 AM

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.