Quote from: eleuthria on January 21, 2014, 04:34:45 AM

Quote from: Trongersoll on January 21, 2014, 04:23:03 AM

Quote from: eleuthria on January 21, 2014, 01:41:23 AM

Quote from: jesse11 on January 21, 2014, 01:40:05 AM

Yeah, my Cubes really took a hit, there running 94-97% on my end. Down 90% Sad

I'll move them till the problem is fixed.

All problems are fixed now, every BTC Guild server (including validation server) has been reverted to the same software it was using for the last year.

And my machine is back to running at the proper rate. When the old stuff works and the new stuff doesn't... You have your work cut out for you.

It's unfortunate that the only way to find out the new stuff doesn't work is by putting it live. Every local test I can do turns out fine, but there are so many thousands of hardware configurations, software configurations, and just plain VOLUME of network activity that you can't properly test in a sterile development environment.

For now, I think I might hang up this attempt at a rewrite and fall back to what I know at least one other pool has done to get better multi-core utilization: Just run the server process multiple times on multiple ports and have a proxy split the load on the same machine over the different ports. It feels like a cop out, but I noticed during the live testing that a significant load still hit one core: The one used for the primary network IO processing, which is extremely difficult to split over multiple cores/threads without significant overhead in mutex locking. I get the feeling it wouldn't be any more efficient than just running multiple instances of the server.

When I started mining here in late October I was getting .5 BTC daily. I thought the network and diff grows to a certain rate, right? I never remember getting .3 .4 ever, it just dived to .1 and stayed there. It basically jumped from .5 to .1 pretty much skipping all the numbers in between. Where did those .3's and .4's go? I would have loved to see them.