Options
Related

Artnet Latency/Artnet Drop Out

Have been working in previz for a couple days and noticed a stutter or hesitation at the execution of some cues. I thought it was probably just the previz suite, but after a few hours of troubleshooting it seems to be that artnet is dropping out for a fraction of a second on a select set of cues with and without command line macros, but it seems the trigger of a macro makes it worse.

Setup....

FB4 b540, internal DP to windows 8 computer running ArtNetominator (Artnet monitor software) which can be found here for free... www.lightjams.com/artnetominator/

And a H4PC b540, with internal DP to the same windows 8 computer running the same software.

Both desks were configured @ 10.0.0.101 for Artnet out, non broadcast, to the windows 8 client on 10.0.0.102 which was running the artnet sniffer.

Both the FB4 and the H4PC showed the same exact results of the Artnet Dropout on the same show file.

The show file can be found here... dl.dropboxusercontent.com/u/85195138/Share/Test_bck.hog3.shw



Here are a few screenshots.

On the left is the artnet sniffer and at the bottom of that is a graph of a monitored artnet channel.

On the right of the screenshots is windows task manager with the network graph up.



The first screen is from running list 6 on master 2. Going from cue 1 thru 3 will result dropouts at the execution of each cue. Cue 3 to 4 will not show a dropout and it will be a smooth fade. Going from cue 4 to 1 will again create a dropout. These can be seen on the graph in the artnet sniffer, as well as in the network graph as a valley.

dl.dropboxusercontent.com/u/85195138/Share/L6_Q4-1LoopLag.jpg


The next screen is the results from running cue 6-7 from list 7 on master 5. Cue 7 has a command line macro that runs list 6 Cue 4. Running from 6-7 you will see the dropout as the macro is triggered.


dl.dropboxusercontent.com/u/85195138/Share/L7_Q6-7Lag.jpg




The next screen is to demonstrate that if I make a copy of List 7 and remove the macro at cue 4, there will be almost no dropout at all.

The following is of List 8 on master 6, which is a copy of list 7 with the macro removed. Going from cue 6-7 on this list does not seem to create a network dropout.

dl.dropboxusercontent.com/u/85195138/Share/L8_Q6-7_NoLag.jpg




I looked through the cue contents of each cue that was causing the dropouts and could not find anything weird or outa place that might cause this. I also tested the same show file on two desks and saw the same results. I'm curious if this is only an artnet thing and if I will see the same thing on raw dmx outa the internal DP's. I did not get the chance to test this on an external DP, I wonder if it would show the same results.

I have included links to everything needed to duplicate the results. Please let me know if anyone can reproduce this and if there is a solution, as it has put a halt on me finishing this previz project.

Edit...

I forgot to mention two things...

One, I wanted to rule out show file coruption, so I created a new show and merged this into it. Same results.
Two, if you look closely on both the raw dmx screen within H4 and the output or levels window you will see a hesitation for the parameters to start their fade. I believe this hesitation has something to do with the network dropout I am seeing.

Thanks

JB
Parents
  • 0
    So I think I found what was causing the hickup or network dropout... Which actually doesn't look at all like it has to do with artnet or network related. It looks more like the H4 OS is stalling durring a memory or SSD read attempt..

    In the original show file, on list 6 master 2, I had set up a base cue (Cue 1) that was referencing multiple palettes, some of these palettes were standalone and a few of these palettes were referencing other palettes. Nothing in the base cue (Cue 1) on list 6 was direct, the entire cue was composed of data that lived somewhere else.

    So... this morning I copied cue 1 from list 6 in the programmer and retouched all values on all fixtures to remove the association to any palette and then re recorded to cue 1 list 6 over writing the cue. It fixed everything....

    Here's my oppinion on what might be happening...

    With too many palettes (Or code links) being referenced at once, it seems to stall the H4OS until it finished finding and reading all the data tucked away in the memory to execute the raw data needed to run the actual cue. By removing any reference to palettes, the read path for the OS is much more direct to get to the data needed, so it does not stall.

    Any chance someone from HES wants to comment?
Reply
  • 0
    So I think I found what was causing the hickup or network dropout... Which actually doesn't look at all like it has to do with artnet or network related. It looks more like the H4 OS is stalling durring a memory or SSD read attempt..

    In the original show file, on list 6 master 2, I had set up a base cue (Cue 1) that was referencing multiple palettes, some of these palettes were standalone and a few of these palettes were referencing other palettes. Nothing in the base cue (Cue 1) on list 6 was direct, the entire cue was composed of data that lived somewhere else.

    So... this morning I copied cue 1 from list 6 in the programmer and retouched all values on all fixtures to remove the association to any palette and then re recorded to cue 1 list 6 over writing the cue. It fixed everything....

    Here's my oppinion on what might be happening...

    With too many palettes (Or code links) being referenced at once, it seems to stall the H4OS until it finished finding and reading all the data tucked away in the memory to execute the raw data needed to run the actual cue. By removing any reference to palettes, the read path for the OS is much more direct to get to the data needed, so it does not stall.

    Any chance someone from HES wants to comment?
Children
No Data

www.etcconnect.com