Hi guys!
I have a big project running with two instances of vvvv which are udp and spout connected (so won’t demo patches here :))
First instance is for UI&content and it runs quite well. It sends contollers to the second instance via udp (spread of 32 values by one port and spread of 120 values by another port) and it recieves texture via spout.
Second instance is for 3D scene and it quite slow right now.
I’m debugging it in common ways and found the following issue:
when fps of the second instance inscreased - udp slowed as hell
when fps goes slow again - upd goes back to normal
That not mean udp is always slow…
I wonder if it some mainloop issues or …
I believe you have met something like before? Any advise, please.
p.s. ZeroMQ seems has the same issue and double spread itself also, but I’m not familiar with ZMQ and dind’t dig deep.
this is because the instances are truely asynchronous, and needs some care to synchronize both instances. even though I am not completely sure what you mean by “udp slowed”, I guess that you witness some stutter and delay?
the poor patcher’s way to sync is to set both instances’ MainLoop to the same value, and making sure it never drops below. that way you will be able to receive one frame’s data of the sender in exactly one frame of the receiver. if timings deviate, you might get two (or more) sender frames’ data in one receiver frame, or even none at all - the two instances don’t run in sync.
this is true for all ways of interinstance communications, no matter if udp, tcp or zeromq, and even with sharedmem (you will not see it as easily with sharedmem, because it writes to a buffer, but its got the very same limitations - once you get the data from the buffer, you might have had no changes in the buffer, or multiple changes, depending on the way your instance timings deviate).
ps: regarding zeromq, use a watermark node with the sender to disable the default behaviour of zeromq sockets (it will try to pack a few messages together to optimize bandwidth utilisation, without watermark it might wait a little, and hence send two messages once, which makes no sense for your application)
not very intelligent solution, but solved by replacing i5 to i7 processor.
i7 even of earlier generation and lower GHz gives much better result for second instance which now runs on stable 30 fps and cause no async issues.
How about switching the UDP node to the Writer/Reader SharedMemory Node? I always had the feeling, that this is a better solution to the UDP Node - if you running multiple instances of vvvv on the same computer.