This problem started after the 14w28-29 Updates. I will do my best to explain as its a complicated idea.
Summary
Fill clocks using 2 command blocks doing opposite fill / replace commands to run a every tick redstoneblock clock, cause local ( in game position local ) Client FPS lag, as well as severe Network bandwidth Lag ( again locally to the position of the player ).
Client Video / FPS Performance.
When you have a certain amount of command blocks running off the clocks seems to be around 50 the client starts to perform a massive amount of chunk updates per tick 300ish from my testing. When facing the opposite direction in game as the location of the fill clocks the chunk updates and FPS performance subsides. This effect happens even if Client does not have line of sight to the clocks themselves ( putting the clock in a closed space or having a wall between the user and the clocks.
Network Performance.
Running the same clocks in a pre 14w28 snapshot, and running them in current snapshot you can see a VERY clear difference. in the new snapshot there is a seemingly linear relationship to number of command blocks running on the clocks to amount of bandwidth being used. Running about 50-60 command blocks basically makes the game unplayable through a DSL connection ( If your character is in the same loaded chunk area as the clocks ). If your teleported away from the clocks the network action subsides. The direction your character faces or anything to that effect have no effect on the network bandwidth increase seen by these clocks.
The reason I am saying this is a bug is because it has changed greatly in the latest snapshots, and seems to make it nearly impossible to have any larger number of command blocks running in a multiplayer server, which is something I would suppose is not out of the realm of intended use.
Hopefully I have explained this clearly, I can provide some video evidence and statistics of the tests I have done to come to these conclusions if that is helpful.
I really hope this will get resolved as doing some multiplayer command block stuff on servers is more or less not possible anymore.
Linked issues
Comments 19
I made a post on Reddit which shows this in action: http://www.reddit.com/r/Minecraft/comments/2yoc3d/psa_do_not_have_more_than_63_clocking_blocks_in_a/
With the help of redstonehelper, I now understand what causes this. It happens when you have more than 63 clocking blocks in a single chunk. Clocking blocks are command blocks next to a fill clock and the fill clock itself. When you go over that limit, rather than sending block updates, Minecraft will just send the WHOLE chunk. This is what causes both the increase in network usage and the chunk updates. Usually when you change blocks in a chunk, just the block data for those blocks is sent, but if you happen to be changing more than 64 EVERY tick, then the whole chunk data is sent.
So this isn't really a bug as such, but more a hard limit on how chunks are updated and such. I doubt Mojang will change the way chunks are handled just to benefit larger clocks. The solution is simple, just make sure you have less than 63 clocking blocks in any one chunk. Place clocks on chunk borders to easily spread the clocking blocks across multiple chunks.
Just FYI I was the first one to bring up the whole 63 block thing. https://youtu.be/d58Ta7yg3Dc?t=13m32s You have to remember the clocking blocks on chunk borders will be counted for both chunks, so its wise to have no blocks clocking on chunk borders for this reason. On a side note I will be releasing a more updated best practices and optimizations video soon. This video will include info on this subject as well as lots of other areas.
Ahh hey Panguino,
Yeah the video you made about it doesn't seem to actually correspond with how it works in 1.8.3 which is where I did my tests. As long as the clocks are in the spawn chunks, crossing chunk borders has no effect on lag or chunk updates and as long as there are less than 63 clocking blocks in each chunk, everything is fine; they do not add together. A possible explanation for our different results may be (just guessing here) due to how chunk handling was initially multithreaded and to my knowledge in 1.8.3 it no longer is.
There are still some border anomalies which my new video will cover. In my opinion to avoid issues it is still important to avoid chunk borders.
There is no more need for excessive fill clocks running command blocks anymore with the implementation of the new command block features. Stop your fill clocks and set all the cmd blocks to always on. No more lag. Thus this "bug" is now a moot point beginning with 1.9 and there will likely be no need to address the lag issue.
Whether the bug actually bothers people doesn't affect it being a bug. Mojang did not decide "Hey, we should add some lag!". Therefor this is not intended behavior. Since it is difficult to fix, and doesn't bother people, Mojang is not going to try to fix it, but the problem still exists.
I get where you are coming from, I do, but the fact of the matter is the lag isn't necessarily a bug. Lag is a fundamental part of any game and players are going to experience lag when things like this are pushed to their limit.
A fill clock functions off taking advantage of how chunks are loaded each game tick. The lag only occurs when fill clocks are overused within the bounds of single "chunk column" (the magic 63 limit), or when extreme amounts of command blocks running off fill clocks were being used. Even then, the experience of lag was localized to the region where the command blocks exist.
Mojang recognized how fill clocks were being used almost exclusively to keep certain command blocks running every game tick. The choice then becomes to either radically modify how chunks are loaded to optimize the performance of these fill clocks (which btw, are not a feature added by Mojang, they are an exploit of the game mechanics and could even be labeled a bug all on their own), OR add a mechanic to the command block that allows them to be on all the time without needing to be powered by redstone, thus allowing the block/chunk updates to be avoided altogether.
The latter obviously wins out because it is easier to implement, it follows the natural progression of how command blocks are evolving, and it doesn't stop any previously used functionality of command blocks or fill clocks. Map makers/operators can keep doing what they are doing and the experience of lag from chunk updates is side-stepped.
So yes, this is going to be labeled as "Resolved" and "Works as Intended" because chunk updates do need to happen and Mojang has added features to the game to allow you to avoid them when using command blocks in large quantities.
I understand your point. What I'm saying is that the only time the "Works as Intended" resolution should be used is if Mojang actually wants it to be in the game. This lag, while not a huge problem, and basically unfixable, is not something that Mojang thought would be good to have. It's just a problem that isn't going to be fixed because it doesn't bother anyone anymore. That's what the "Won't Fix" resolution is for. Something that everyone agrees is a bug, but Mojang, for whatever reason, isn't going to fix it.
As it is, many bugs that Mojang has decided not to fix are labeled WAI, such as MC-1823, MC-2313, MC-10708, MC-30663, MC-50605, MC-63055, MC-63446, MC-64634, MC-77170, and MC-78797. In all of these reports, the issue is clearly not something that Mojang intended to occur. They have simply decided not to fix it, sometimes for performance reasons, sometimes because it would just take too much effort. The "Won't Fix" resolution is woefully underused, which leads to very inconsistent resolutions. WAI should only be used when it was actually intended, such as MC-11220, MC-35860, MC-48184, MC-63380, MC-78691, and MC-79609.
This bug happens also in Minecraft 1.8.1