Yes no doubt you will now delete this post ...
You know, you're right about one thing. I did make a personal vow to ignore you and to delete your posts in this thread. Unfortunately, with my sanity on the line, I will now break that.
You're an idiot. You're a complete total and utter fool sometimes (most of the time?). You have no respect for anyone here whatsoever. You twist my words and others to fit your own mindless scenarios and your imagination of how things are actually working with little or without any real knowledge or experience with the topics you pester me about. You follow me around this forum like a stalker and there is very little I can do about it, unfortunately, and it's really f*ing old. Seriously, just crawl back into your cave and die because I'm beyond sick of this sh*t. You don't find me following you around this forum posting against everything you write regardless of merit. The fact that you feel the need to do this with me shows your true character and how your words have no value whatsoever.
Now to take out the trash by completely slaughtering your post. I've no reason to delete it while it provides me with an opportunity to bring into the light how much of a troll you really are.
but I think you need to point out to your users what your post means.
Your post means that in the past year (or very likely a lot longer but I've not directly checked this) the pool block changes have been slow.
I've pointed that out in various places on the forum and in the bitcoin git.
Both luke and you have lied about it, saying it wasn't true.
Yet your orphan rates over the past many years have been high and quite clearly stated that your block change times were slow.
In reality, it would seem the only reason you did do anything about it is coz I kept pointing it out ... and it was true.
Yes I do know who wrote the benchmarking log changes to cgminer that you are referring to above helping you see what I said was true.
Also, remember, there are pools 10 times the size of this pool, still able to send out work ... so using that as an excuse was also deception
You have something like 30 servers that should be able to send out the work of a single server only a 30th of the size of your pool ...
You "pointing out" the slow block change times from before means absolutely jack to anyone with a clue. I've repeatedly explained exactly why you and others were getting the results you were getting, but you refused to listen or accept the actual facts. For the record, again, the connection prioritization in place to mitigate the bandwidth spike on block changes was entirely the cause of this. Because kano (and one other who tested and pointed this out in a much more respectful manner) never actually mined on Eligius for any length of time with any real hash power (generally none, resulting in a zombie connection at literally negative priority) his connections were never prioritized and were obviously delayed while actual miners were given work updates. But no, the trolling had to continue despite the facts. (TLDR version: Don't call me a liar, asshole.)
Orphan rates have been on par and normal despite kano's trolling. Eligius has been around for quite a while and has mined well over 10,000 blocks through just the latest and longest running revision. Just Eligius-Ra, the revision that began at the beginning of 2012 and will have been running for four full years in a couple of months has the following stats: Confirmed blocks: 10128 blocks --- Stale blocks: 231 blocks. For those of us capable of doing math, this comes out to 2.2% stale blocks. Just looking at data I have from my own bitcoind, the network wide stale block rate is higher than 2.2% just based on stale blocks that reached my own node (and were reorged). Since it's impossible for my node to have seen every stale block from every pool and miner, it stands to reason that the network wide stale rate is much higher than 2.2%. Looking at the block change latency of some of the major pools it's pretty obvious that it would be.
Kano's own pool has been running about a year, roughly 25% of the time that the current version of Eligius has been online and has mined 368 blocks as of this writing, a whopping 3% of the blocks Eligius has mined and has data on. I don't know about you, but I'm reasonably certain Eligius has much more valid long term statistical data. So while kano's young pool may have about 0.5% stale rate over 368 blocks, let's check back in about 30 years when that total block count catches up to what Eligius's today and see where things actually stand. Kano saying Eligius's orphan rate is high is like a guy at the roulette table who is up a few % after a few hours going around telling people that this roulette table must be better. lol. Pretty sure I'll stick with legitimate long term stats on the topic when discussing it.
Why I did anything about it was to get rid of the connection prioritization method that was in use and to level the bandwidth spike that was happening on block changes. New method allows a small bandwidth spike to get all miners on the new block, followed by a staggered updating of full work and coinbase on miners spread over the next several seconds. This way latency stays as low as possible since at no point are things saturated. As an added bonus, even zombie connections with low priority get block changes pretty much instantly which makes it all the simpler to just give kano the finger. Especially since with the latest updates Eligius is getting block changes out to even the lowest priority miners a full 0.5 seconds faster than kano's pool averaged over the last several days. We'll just ignore the fact that Eligius has exponentially more miner's connected.
Overall, and as I mentioned in my post above, Eligius's block changes *are* in fact faster than they were using the previous code (mostly just Eloipool's p2p-based speedup). The issue previously was that eloipool would quickly get the new work out to some miners and immediately be trying to send full work+coinbase to miners before everyone was on the same page, resulting in a saturated outbound pipe and only prioritized connections (basically ~90% of the pool's hash rate) getting the work in the best time possible. Slower miners and zombie connections would be delayed slightly as the saturation subsided. Now the initial work change is even faster AND I stagger the second update to not cause a massive bandwidth spike. Win-win, and nothing to do with kano. So my post "means" exactly what I said it means: Improved reliability and responsiveness for all Eligius miners.
I'm still looking for these pools 10x the size of Eligius that have (or had) faster work change times... the only pools that are 10x larger than Eligius or more are the four large Chinese pools. Two (maybe three?) of these do unsafe headers-only mining. One of them has block change times that are so horrible they should be getting 10% stales. The one I thought did headers-only mining is actually 4x slower at block changes than Eligius, so... yeah, not really sure where this comment actually comes from. Let's also keep in mind that Eligius's coinbase transaction is generally about 6KB, where basically every other pool (besides p2pool, which doesn't really have bandwidth constraints) has a coinbase transaction that is less than 0.2KB. Combine that with Eligius constantly trying to mine max sized blocks and work updates start to get quite bandwidth intense when all miners need updating.
As of right now the block change benchmark stats show Eligius as the fastest non-headers-only mining pool on the list. Admittedly, kano's pool is #2 trailing Eligius by only a half-second on average. Slush is close following by about a second, and the rest are multiple seconds behind Eligius.
And I'm not sure where you get the "something like 30 servers" nonsense, either. The actual number of machines Eligius uses is not public info, for one, and it is well below 30. Imagine how awesome things would be if we did have 30 servers though.
Having thoroughly explained why your post is complete nonsense, if you post here again with anything other than, "You're right, I apologize." or something similar, I'll re-up my resolve and just revert back to my delete-on-sight tactic of maintaining my sanity.
TLDR version: kano is a troll, as always.
Edit: Apologies to those coming here for actual updates and relevant on-topic discussions. See my update above as the latest pool news:
https://bitcointalksearch.org/topic/m.13104399Edit: Deleted a response by kano without reading it. Skimmed, did not appear to be an apology. Looked like some nonsense about orphans again.