DvdKhl

Still happening in 1.8.1-pre3

Not sure if I can speak for the reporter. But my bug report which was merged into this one still has issues ( MC-32296 ).
All videos except the third (which seems fixed) still behave in the same (buggy) way.

The first and last video is probably the same issues as: MC-54711

Still happening with 1.8 😞

Still happening with 1.8 pre2

Well it definitely doesn't cause any bigger freezes anymore.
Only the short freeze when GCing, but that one has always been there.

So you could call it a day and mark it fixed, but optimizing memory usage could pay off though (i.e. by pooling/reusing large arrays if that isn't already done).
So it is your call.

Some stats:
Settings: VBO On; distance 16; Fancy; FOV Normal; No VSync; Smooth Lightning: Max; Alt Blocks On; Windowed (1920x1178); Clouds Off; Particles All; -Xms3G -Xmx3G
Loading the world, doing 360° lookaround (waiting for chunks to be loaded), than just standing:
Memory: 500mb-1500mb; +200mb/s; 5s until GC

Same as above but in menu (Esc)
Memory: +10mb/s

Flying forward (for previously loaded and then unloaded chunks)
Memory: 900mb-1900mb; +500mb/s; 2s until GC

(Please keep in mind that I'm not the reporter and he/she might still have issues)

With 14w30b the issue is (in my case) a lot less prominent and sometimes even unnoticeable (i.e. the freeze/stutter duration after a GC is a lot shorter), the GC frequency itself is still quite high though.

Also happens in first person view: http://youtu.be/-ldlgk6V7z8

I'm noticing the same problem more severely now with the current version (14w29b).
Probably due to the threading and the faster load of chunks (which is awesome btw).
The problem now is that GCs happen a lot more frequently.
At worst I had a GC every three seconds and the freeze + followed stuttering sometimes lasted more than a second.
Here is a video I took after standing still for ~5 minutes and then recording 30s of standing still: http://youtu.be/yAB4yME8Xtg
Please note that the actual increase rate is even faster when not recording.

Still an issue for 14w28b.
I've made a short video demonstrating various combinations where one-tick pulses are problematic:
https://www.youtube.com/watch?v=Ubq6DLk0wsA

On second thought, is this really a bug?

Since the delays are not in alignment, it sounds more like an aliasing effect, which is also an issue in the real world.
I guess the repeaters which are supposedly "out of sync", are just doing their sampling (checking their input) at different points of time, resulting in a different output sequence.
Changing that behavior to something else would probably lead to a lot of other issues and is probably hard to code in a satisfying way.

It is still happening:
http://youtu.be/jgwoGZUOEFY

Issues start at around 1:40

I did create a ticket which describe these problems ( https://mojang.atlassian.net/browse/MC-32296 ) but it got marked as duplicate and merged into this one.
So I basically share your opinion that this is a separate issue, but I don't want to annoy the mods creating yet another ticket for it.
It would be nice if a mod could clarify if this should stay merged as one ticket or if my reported issues warrant another ticket.

Henrik Lindström: Could you add 1.7.4 and 14w03b for the affected versions?
Not sure if your reported issue is still present, but the issues pointed out in my videos are still there.

Well my issue report was marked as duplicate of this one.
So going by this, it looks like repeaters are affected by this bug mentioned here too.

Since this is still the ticket to go to for one tick issues here some videos which show the "one tick physics" issues present in redstone logic:
http://www.youtube.com/watch?v=JNTTuGOqJkg
http://www.youtube.com/watch?v=Z0OsUjZXQVs
http://www.youtube.com/watch?v=CgPIavyc4ig
http://www.youtube.com/watch?v=Ac_IujHfXpw

Hi,
I don't really think that it is a duplicate (as my main problem are repeaters which its title does not mention),
but I'll respect your decision and post it there instead.

Cheers

May be related:
Place two two repeaters next to each other (facing in opposite directions) each having a one tick delay.
Connect the repeaters. Creating a clock which produces a 1010101... tick pattern.
If you now attach a "line" of repeaters to it, instead of seeing the 10101... pattern you get 111011101110...
This breaks all my contraptions :/

Please check MC-2340 which probably already describes your issue.

Yes, that might be the case, I have no way to be sure though.
I guess I will report it again when that issue is fixed but this one is not.
So feel free to mark this one as a duplicate.

After some more investigation:
Faulty behavior as described in previous comment stays the same until 13w03a.

The following changes are visible:
Pulsars which produce one tick pulses work again.

Pulses with one tick work fine (one tick on all repeater paths)
Pulses with two ticks are shortened (by one tick) on the outer repeater paths
Pulses with three ticks work fine (three ticks on all repeater paths)

The bug reoccurred with the pre1.5 (or earlier, I only checked pre1.5 for now).

I had to increase the delays for the pulsars (repeater nearer to the clock) by one tick otherwise no pulses were generated.
By increasing it by one tick, pulses of two ticks are generated.
(Bug? Already reported?)

With that change described above, the two inner repeater paths show two ticks as exprected.
The other two repeater paths on the other hand show only one tick.

Can I somehow reopen the issue or should I clone it?