Network Issues

[greenie95125]

I sent you the info requested. No hubs or switches here. I have devices and a router, Some devices are hard wired, the rest is wifi.

 

You say the the tracert clearly shows that your software is not the problem and that the controllers are routed correctly. Maybe I'm an idiot, but to me that shows the exact opposite. If the ips are routed correctly, and the network grinds to a halt when the listener is running, it's the software, not a mis-configured network.

 

Mike

[LOR Staff]

I sent you the info requested. No hubs or switches here. I have devices and a router, Some devices are hard wired, the rest is wifi.

 

You say the the tracert clearly shows that your software is not the problem and that the controllers are routed correctly. Maybe I'm an idiot, but to me that shows the exact opposite. If the ips are routed correctly, and the network grinds to a halt when the listener is running, it's the software, not a mis-configured network.

 

Mike

 

That would be true if and only if there were some way in an IP packet to force it to go in a particular direction.  There is not.  In this case the IP data coming out of the software is very simple:  Give this data to xxx.xxx.xxx.xxx.  We do not choose how to get the packet to the destination, Windows and the routers do that.  According to the trace, Windows is correctly sending the packet up to the router, which then sends the data back down to the E1.31 device.  That makes it 100% outside of us.

 

In this case, the differences between software are what have you hung up on blaming us vs some other program.  The listener (per the E1.31 spec) is constantly sending DMX frames out.  Yes, it is very chatty - as opposed to other software that may not be following the same rules.  BUT we don't do anything funky.

 

The test you need to perform to test your theory is this:  Run a network capture program like Wireshark.  Run a sequence with S4 that exercises every channel on your E1.31 devices at a particular rate, and then run a sequence with another E1.31 software that exercises the SAME channels at the same rate.  You will find that both should be sending the same amount of data at the same rate (as long as the other software is correctly obeying the spec).

 

In other words, just because something is different does not mean that it is wrong.  In fact, in programmer terms if I were you I would be complaining to the other E1.31 guys since their lack of idle packets is going to hang channels if packet gets lost along the way.

 

What all this data fails to show is if the router is leaking packets, which it could very well be.  The only way to catch that would be if we could investigate the traffic between the modem and the ISPs first hop.  

 

In the end, all this also shows me is that there is an issue somewhere outside of the software and outside of your configuration - which appears to be fine:  Everything you have sent shows that you are properly configured, unicast, with a proper net mask/etc.  

 

The issue is now either the router leaking packets, your testing method, or a physical problem with your network.  

[k6ccc]

Thanks for the explanation, Jim. However, in my case the computers and controllers in question are all hard wired to the router, but internet speed is grossly affected on the wifi devices as well. It also doesn't really explain why x-lights doesn't have the same hit on network performance. I know I keep bringing up x-lights, but it's the only other e1.31 software I have.

 

Mike

 

Based on that paragraph, your network has a problem.  Without seeing the Tracert that Mike did, I can see a couple possibilities:

 

1)  This assumes that the problem is that your WiFi is getting choked.  Your router may behaving like a hub and sending all network traffic to all ports on the switch.  A switch should not do that unless the source data is being broadcast (multicast), OR the target device if using unicast is not present so the switch has not learned what port it's connected to.  If you are using multicast, and your WiFi is on the same network as your E1.31, the WiFi is going to carry all your E1.31 traffic.  Solution is to use unicast, or better yet put the E1.31 traffic onto it's own network (or better yet, both).  At my house my E1.31 is unicast and is on it's own network.

 

2)  This assumes that your internet connection is being choked.  Your router is forwarding Private LAN traffic to it's default gateway (your ISP).  Your router needs to either be configured properly or replaced because it's not following the rules.  BTW, for most consumer routers, you can't configure that option (you shouldn't be able to BTW) so if it's forwarding private IP addresses, it needs to be replaced - maybe a firmware update to the router will fix that.

 

Also note that in the new 4.2.4 beta release today, there is a modification that reduces E1.31 traffic when the lights are not on.  See my post 5 in:

http://forums.lightorama.com/index.php?/topic/37346-why-is-the-lorcommportlistener-so-chatty/ for some details.  That only will affect idle times.  During your show the E1.31 is going to be chatty.

 

Also for a little bit on an explanation.  Your typical home 4 port router with WiFi is actually three separate devices in one box (and normally on the same PC board).  The first is a router that has one WAN port and one LAN port.  The router normally also functions as a DHCP server, and has a web server that is used for configuration.  The second function is a 6 port network switch.  I know you're about to say "6 ports?".  Yes .  I'll explain shortly.  The third function is a WiFi access point.  Now, you wonder why I said 6 port switch?  The 4 ports that show up on the back are obvious, but there are two more.  One connects to the LAN port of the router and the other connects to the WiFi Access point.

[greenie95125]

Once again, thank you for the info. I'll give the new release a try, but in the mean time, I'm frantically trying to get a grasp on x-lights.

[LOR Staff]

I smell another 'Ramblings from the help desk' post about this... 

[wmilkie]

As I told you in your ticket, the issue is a configuration problem.  I also gave you some other steps to follow to see if I can identify where the issue with YOUR configuration is.

 

The issue is not arrogance, the issue is that you are not correctly configuring your network.  Hows THAT?

 

Mike, 

does this " the issue is that you are not correctly configuring your network."  apply to the Visualizer results also? No hardware connected?

IE:  intermittent freezing/erratic dmx lighting duplicated in Visualizer, when no external network connected?

 

And I don't think it's a LOR problem, just trying to get a handle on my problems

[dgrant]

I'm not set up this year yet but last year, I created a separate wireless network for my E1.31 traffic AND during the shows, I completely disconnect the computer's internet WiFi connection which happens to be a USB transceiver. With no access to the house network/internet, it does nothing to it. The only thing I saw happen last year was one evening, line of cars outside, someone was trying to hack into my E1.31 network which slowed it down briefly. Once whomever was gone, it went back to normal.

[LOR Staff]

It will apply to EVERYTHING.

 

Remember that your pipe is only SO BIG - the pipe being your slowest network path that a data packet has to traverse.  If you have incorrectly configured a network config and your packets are traveling out onto a slow network (and your internet connection is slow compared to the rest of your net) then absolutely this will have an effect.  The packets will stack up trying to get out.  Windows will see all this data trying to get out the door and will allocate more processing time to doing it, which will slow everything else (like the Visualizer) down.  

 

Also, if I am not mistaken (and I could be because I am not an "on the metal TCP Stack guru") the Windows process that sends data out is single threaded. So even if there is IP data out there that just needs to be looped-back (IE, received by the computer sending it)- it will sit enqueued waiting for any data in front of it to be sent.

 

A lot of users are also under the impression that bandwidth is 'unlimited' when talking about E1.31 (more correctly TCP) traffic.   It is not.  As Jim has pointed out, a universe will consume 1/4 of a megabit of bandwidth (per second).  A fully loaded PixCon16 with 32 universes will therefore consume 8 Megabits.  I am sure there are people out there that are still on 10Mb network hardware.  1 board has fully saturated your LAN.

 

Or how about trying to run it wireless?  Assume for a moment that you are using G wireless (which is probably the most common one out there).  That speed is 54Mb but -- first of all it is half-duplex, meaning that 1/2 the time the wireless is not going in the direction you need.  This cuts the bandwidth by a little more than half to around 20Mb.  Second, speed is dependant on distance and noise.  You may not be getting a 54 meg link, it may only be a 32 Mb link.  Half of that is 16Mb.

 

Now extrapolate:  You are consuming 8Mb of that.  Your kid is watching a movie on Netflix, and that is consuming 5Mb.  You have several other devices that while idle are still connected wirelessly.  Your entire network is now at a crawl.

 

These are the reasons we suggest that you get your lighting stuff OFF your existing LAN and turn all the wireless stuff OFF that is on that separate network.  A separate router is only $20, and the physical segregation immediately removes ALL the issues.  Those who understand networking a little can then cross WAN to existing LAN and reap the benefits of being connected while still keeping lighting packets OFF the normal LAN.

 

I don't think it is too much to ask someone who has spent thousands of dollars on pixels to spend $20 on a separate router.  I find the argument absurd, just like I find people who spend thousands on lights yet want to pirate a $.99 MP3 absurd.

 

If you haven't seen it, please READ THIS:  http://www1.lightorama.com/PDF/IntroductionToDMXandE131.pdf

[Greg Young]

This thread certainly has been an interesting read.. to say the least!

 

Guys, it's really quite an easy fix. folks are making this too complicated.

Install a ($15 or so) second network interface card (NIC) in an open slot in your pc.

Route your display traffic there.

 

If you don't know how to do that, the simple alternative is just before your show go into the control panel -> device manager, click on network adapters.

You will find 2 network cards listed. Click on your primary NIC, the one that connects to your home system, and click disable.

Nothing will get through to your home network when running your show!

After the show, click enable, and things are back to normal operations.

 

I route my display traffic to my second NIC, but I have devices connected to that NIC.

If you try routing without devices being connected, the traffic will go out both cards, in an attempt to locate the device.

 

E1.31 is simply a method for carrying DMX data. DMX data is one way transmission, so there will be constant traffic.

It might more understandable to folks if the D in DMX stood for dumb, instead of digital (multiplexing) because that's how it handles data!