Options
"Max Queue Count" from Max Module
TrikinCurt
Posts: 158
in MAX by AMX
Okay, I have a pretty big system (14 panels, 15 modules including a Max system). All was well until I added a small module for a Polk XRT12. The timeline wasn't firing and the buffer was always empty.
Turns out running by itself it is fine, running in the system it blows up. During bootup I notice the Max Queue Count "error" is getting all the way to 500, which can't be good. I disabled the Max module (UI module being called 14 times) and everything is fine and the timelines are running again.
Anyone know if the issue is the Max module or if it is more likely something else and the Max just puts it over the edge?
Turns out running by itself it is fine, running in the system it blows up. During bootup I notice the Max Queue Count "error" is getting all the way to 500, which can't be good. I disabled the Max module (UI module being called 14 times) and everything is fine and the timelines are running again.
Anyone know if the issue is the Max module or if it is more likely something else and the Max just puts it over the edge?
0
Comments
Is the Queue_and_Threshold_Sizes.axi include part of your project? That may fix you up if it's not.
Curt
I still have about 8 more modules to add, which seems impossible right now!
Another thing, this is a three master system, but the other two masters have no code on them, basically just being used to give more ports.
Curt
(and sorry this thread is under Max, since it seems it has nothing to do with that!)
If you have coded in a non-AMX manner, you will have made many assumptions about what is lightweight and what is heavyweight, and you may be mistaken. I've been there!
The first thing to try is to pace the startups of your modules. Give each module a number and run its startup delayed by maybe nModuleNumber x .5 second.
And sheesh, I wait long enough for it to boot already
Curt
Imagine that times 30 rooms - this is in the on-start. Is this a bad idea? I liked the readability of assigning it all there, but not at the expense of explosions in the code...
At one point, I had a serial to IP converter on the system, and that thing was enough to blow up the system. Too much processor attention was needed while it was connecting ... and it took me forever to realize that was the problem, since it generated no errors whatsoever, just took a long time.
If this is true, I would suggest to put all the parsing stuff for your serial ports to the masters where the physical devices are connected.
If you place the code all into one master, every byte from every serial port has to be transmitted over the master2master connection to ONE master and must be processed.
I think if you have 3 ni3100 (21 serial ports), this would give a high load.
If you have modules for the devices, place the com modules into the masters your serial devices are connected to and only share the virtual devices amok the masters.
Also isn't it possible to connect some of your panels to different masters and do all the processing there ? This would also give a better reliability to your over all system. If one master stops working, still a part could be controlled,
For example: you could connect 10 panels to one master and place all the UI stuff to this master. This way you will benefit from all the cpu power of all masters.
Hope this helps.
Jurgen
Curt
Curious on why? I am not doubting you, I just don't have a clue and want to understand! Jurgen mentioned moving the COMM modules to the box that the device was connected to, which seemed to make sense.
At this point I have COMM and UI split amongst the boxes, which seems to be giving me my best performance yet, at least at boot up.
Curt
Well, one reason that comes to mind is that the multiple COMM modules are maintaining multiple IP connections on the MAX server. That's a lot of work for the MAX to do. The MAX is not the quickest ship at sea for that kind of stuff. You can maintain a lot more control of network traffic if you do it from the single netlinx master.
I have some very large systems with multiple touch panels and multiple AVMs that run from a single master just fine. In fact, I've never had to break up the processing and have kept all the program in one master. I do use multiple masters as local control boxes. But the program resides on one box.
Because you now have multiple NetLinx masters controlling the same device, and every time one does something, the others are going to have to process the feedback. There is also the possibility of one telling the MAX to do something that conflicts with what another is telling the MAX to do. The MAX, as noted, will only connect to one at a time ... this is a huge bottleneck and is bound to cause issues.
With an include file, I always know what to expect. With modules, sometimes it is just a cr_pshoot as to how two modules will react with each other.
Hope this helps. Just my two cents.
Sheldon Samuels
1) Modules belong at the end of STARTUP.
2) All like modules need to be grouped together.
For both solutions you have to pay attention that you do not use two instance for the same physical device to control. This will always cause trouble !
Specially to max you should only use one comm module that talks to max at all. In seldom cases you can use two comm modules that talk to the max server so you get a better reliability of your system.
To include files: I use them when I have a "one time" solution. Also the benefit is, that you do not have the overhead of the events to get the information to and from the module. I guess this is why include files perform better.
[off topic]
But when ever I have a chance I prefer to make module files. I have a good template I always use as a start where I have a send queue and the preliminary parsing of commands and device feedback. Also I do not have to take care about variable names if the already exist in the main program.
But the best benefit is, that if I have more than one instance of a device, simply include a second instance. Also this does not blow up the code since (remember: multiple instances of a module only add the "runtime" overhead to your program). Also maintain the code is much easier. If I make a fix in the module, ALL places where it is use benefit from the fix. This is not the case for include files, at least not every time.
[/off topic]
But it is very important to place the COMM modules in the master where the physical device is connected and only share the virtual device between masters.
In case of max you should only use on instance of the comm module at all as mentioned above. If I am not mistaken, the problem comes up if you have more than 3 connections at a time (COMM module, WinMAX, MAX-MDL200).
Regarding to MAX this is my personal experience.