Recommended Max Duet Modules Running On An AMX Master
DigiMe
Posts: 59
I know this is a bit of a loaded question with a lot of unknown variables like:
1. Which AMX Master: NI-700, NI-2100, NI-3100 w/256, etc....
2. What Duet Modules: Tandberg, Extron, etc....
3. Any other code running?
So, let us just use an example of:
NI-2100 running only Tandberg Duet Modules with some code to gather data from several connected CODECs as well as basic control.
PS - Sure, I could just a write my own Non-Duet Tandberg module using telnet for the method of control, but lets say time is an issue and the Tandberg Duet Module is already developed and working.
1. Which AMX Master: NI-700, NI-2100, NI-3100 w/256, etc....
2. What Duet Modules: Tandberg, Extron, etc....
3. Any other code running?
So, let us just use an example of:
NI-2100 running only Tandberg Duet Modules with some code to gather data from several connected CODECs as well as basic control.
PS - Sure, I could just a write my own Non-Duet Tandberg module using telnet for the method of control, but lets say time is an issue and the Tandberg Duet Module is already developed and working.
0
Comments
Some issues that make it really difficult to know.
is this a case where you're going to have to put in multiple instances of the module to deal with multiple panel control/feedback or do you have a UI for it that deals with multiple panels? Are there multiple CODECs being controlled by multiple panels? etc....
I know I could start loading up Tandberg Duet Comm modules and see the memory usage and performance. I just just seeing if I could find a rough number so I would know how many AMX masters I would need.
PS - I know I could just write all the code in C# and not use any AMX masters. It is just I have been programming AMX for about 8 years. but C# for about 2 months or so. I actually have written a DLL file for controlling a Tandberg CODEC which works fine. I just did not want to rely on a "Windows" based box for everything.
When running multiple instances of the same duet module, please ensure that your firmware is at least 3.6.454 or higher because an issue was discovered and resolved pertaining to multiple instances of some modules.
Several Helpful Telnet Commands for your master:
cpu usage (reports the current processor load of your master)
show mem (reports the current memory usage on your master)
get duet (reports the current memory allocation for duet applications)
set duet (sets the memory allocation for duet applications)
show buffers (see if anything is hung in your java que)
Unfortunately, you probably will not arrive at an answer to your question until you code the job and connect to physical devices. That will be the true test with polling and parsing. Not ideal, but probably the only true measure of performance given the high number of variables that go into determining system performance outside of the duet modules themselves.
It appears to always return a value it measured during boot. That is, no matter when I type CPU USAGE, I get exactly the same result...
>cpu usage
CPU usage = 99.99% (30 sec. average = 90.68%, 30 sec. max = 99.99%)
This is no matter if the system is idle or processing intensely.
I believe we've been told it has to be preceded with a REBOOT HEAP WATCH command, but others say this is superstitious and meaningless.
It appears to do something:
>reboot heap watch
(0328457937) ConfigMgr::SetHeapWatchOn -Setting heap watch on and saving config
(0328458112) Memory Available = 8469528 <10392>
Rebooting in heap watch mode...
However, after the reboot, CPU USAGE continues to give precisely the same result (to the 100th of a percent) anytime, idle or busy.
Running firmware v3.60.447 on the unit I'm looking at now, but this has been the case anytime we've tried.
Can you share the real answer?
I can not speak to the number reported with the command and what the key drivers of this number are, but I see it spike at boot while things are loading and then it returns to a lower level after a few minutes.
For instance, right now, the 3100 at my desk is running 7 duet modules at (duet mem at 16mb)-no gear hooked up:
CPU usage = 14.94% (30 sec. average = 14.55%, 30 sec. max = 17.93%)
a residential system running 9 duet modules at (duet mem at 10mb) - all devices connected and running:
CPU usage = 15.63% (30 sec. average = 18.69%, 30 sec. max = 44.36%)
The same residential project was running at 99% until I discovered two modules were using the same virtual device. When I resolved that, it dropped to the 15%. No other code change needed.
Examples like this are why I say that there is a lot happening outside of the duet module that plays into big picture on how the system will run. I have never used the 'reboot heap watch' command. Just Friday I was testing a system and checked on the cpu usage and I too got the 99%, but just seconds later I looked again and it had dropped to around 20% and it stayed there once the boot processes were finished.
Ultimately, the system will run at 99%. In many cases, that is sufficient. However, if you are experiencing lag, cpu usage and buffers can tell more of the story of what is going on under the hood. If your system is operating at 99%, it may be nothing to worry about.
For me, the values are updating with firmware 3.60.454 and the number reported does not appear to be storing the highest level like the 'show max buffers' command would show for buffers.
Here is the same command issued in one second intervals:
>cpu usage
CPU usage = 11.84% (30 sec. average = 18.70%, 30 sec. max = 41.34%)
>cpu usage
CPU usage = 37.81% (30 sec. average = 18.06%, 30 sec. max = 37.81%)
>cpu usage
CPU usage = 12.55% (30 sec. average = 18.05%, 30 sec. max = 37.81%)
>cpu usage
CPU usage = 31.41% (30 sec. average = 18.45%, 30 sec. max = 37.81%)
>cpu usage
CPU usage = 12.78% (30 sec. average = 18.44%, 30 sec. max = 37.81%)
>cpu usage
CPU usage = 12.60% (30 sec. average = 18.44%, 30 sec. max = 37.81%)
I had a situation where I found code maxing out a processor by entering a button-push infinite cycle that was executing code over and over again and locking up the processor. I fixed it by deleting the circular reference.
This from a non-CineTouch system
>cpu usage
CPU usage = 99.87% (30 sec. average = 99.10%, 30 sec. max = 99.87%)
This from a CineTouch system
cpu usage
CPU usage = 95.12% (30 sec. average = 96.64%, 30 sec. max = 99.98%)
Days later, load or no, these numbers are identical on a new CPU USAGE.
Somehow, we are doing things differently. It would be great to understand this.
UPDATE:
I rebooted, and did the CPU USAGE during boot. It varied widely during the boot. Once the system went to idle, the usage locked at a number it now reports every time, just as before.
With no program loaded, it shows about 8% and does vary every time I look.
Huh.
Update 2:
The report is obviously false on its face.
>cpu usage
CPU usage = 99.99% (30 sec. average = 93.33%, 30 sec. max = 99.99%)
It has been at 99.99% every time (several a second) for the last 5 minutes. It's mathematically impossible for the 30 second average to remain at 93.33%.
I just ran it on my home system and I got this
CPU usage = 0.52% (30 sec. average = 0.86%, 30 sec. max = 2.67%)
I'm pretty happy about it. It's a good sized program
Pretty efficient, not bad.
is everything 100% event driven with no queries unless some one is actively using the system? Even then how do you get numbers so low?
I just used my iPad to connect to my home system and 2 remote jobs and one job was mid 50 with a 30s avg of 80 but my system and the other had all numbers in the high 90s. My system is a mess but I expected the other high average system to be much lower.
Duet modules are not some magical sorcery formed by crushing newborn unicorns and injecting the resulting rainbow coloured goop into a *.jar. They are simply OSGi bundles, lumps of code whose efficiency is completed and utterly dependent on how well they are written. Unfortunately as almost every module is closed source finding that out is a matter of experimentation.
Regarding CPU usage, we have no problems with the command reporting constantly high figures here. Its monitored and 30 second average sent back to our RMS server. This is across a number of firmware versions and a couple of years of historical data.
Really amazing that you have a program that actually uses LESS CPU than no program at all.
My test on 2 systems show about 8% CPU use idle with no program loaded at all. And with the dip#1 set to prevent anything from running... just the OS, the web server, the FTP server, duet, the clock, the I/O handlers... easily 8%. Your program somehow suspends all that and works too?
It seems to me that the ruler is broken.
We had come to that conclusion several years ago, and concentrate on function and performance rather than this number. But when Chris brought it up as a tool to use in diagnosis, I thought I'd ask about the clearly arbitrary results.
I'm make lot of system, but normal CPU Usage is never more than 15-20%!
Example complete Tandberg modul with together 2-3 other DUET module:
>cpu usage
CPU usage = 0.41% (30 sec. average = 1.50%, 30 sec. max = 2.64%)
USED Duet Modues:
1 pc HitachiCPX3010N Projector
2 pc LG monitor
1 pc Cisco TC
1 pc Somfy RTS
The number 1 culprit I have experienced with CPU usage is code (feedback) running in Define_Program. I had seen several systems go from 95-99% to 30% or less, just by moving ALL Feedback code into a timeline event. That was the only change made to the program, and it would consistently stay below 50%.
Agreed.
Similar topic - any good source of information for what exactly all the different elements shown by the spy command represent?
0
Just my 0.02usd, I have jobs with huge amount of modules, code, rooms, constant streaming unsolicited feedback back, and cpu usage stays under 60%, I tested the same system with adding 2 duet modules for new components, and ui processing of page flips, feedback, everything was delayed and cpu usage was maxed 99.99, I commented the duet modules out and everything dropped back to normal. Before you say its a freak incident, this is > 5th time trying to give AMX duet modules a shot.
..... Why AMX..... WHY???
ET TU AMX???
James
Please only use JAR file. All other modules just small demo GIU!
Same times use tom much processor time, FB is not optimal time runing!
Communication feedback parse function is not working every time!
EVENTS use to much times from the processor: BAD Algorithm! Not buffer parsing etc.
If you like use other AXS files (UI, etc) all times is need check the complete program function.
Very important point the DEFINE_PROGRAM part:
If you use this part the program section, will running more than 6000 times/second!
You make to FOR and other long time function, you will investigate lot of CPU times!
Best way you make TIMELINE for all feedback!
Good FB philosophy:
- Not need all feedback! Only need actual view in the panel etc!
- Not feedback every msec! Hand is pushing one button 250-350 msec. FB us enough about 400-1000 msec.
Very important point is the STRING or COMMAND style feedback. This is use more traffic, buffers and CPU times!
STRING and COMMAND Feedback is only need:
- Device is come ONLINE. You need refresh the all information on the panel.
- FB DATA is changed and PANEL is view the active page!
To say when and where feedback should be use is at best the result of cognitive bias, a concept and/or belief as the result of one's own experience and ideology. No one programmer can say the best way to write a given program and what should or should not be used.
I am just having a little fun......ha ha.
Either way, the point of this post was to ask a simple question. Of course, I knew it was very unlikely that any one person could provide me with an adequate answer, especially with the lack of required information on my part.
Realistically, I knew that what I wanted to accomplish was very unlikely given that fact that I need to provide basic control of over 200+ Tandberg CODECs via an international IP infrastructure not to mention the Cisco Telepresence Codecs that can only be controlled over a SSH connection.
Thanks all for you time....and down to DUET...
In a post of mine a few months back, I actually posted a screenshot comparing what a Duet & NetLinx Nuvo tuner module looked like. It was quite frightening to say the least. Keep in mind, not all Duet modules are written the same. They are the same on the outside, but deep inside their differences show. Let's just say some programmers are better than others up at AMX.
From what I've gleaned about VxWorks and the "advanced" debug console, there is VxWorks specific software capable of interfacing with the OS at the lowest level. In comparison, the CPU USAGE and SPY commands are "helper" tools, much like SEND_STRING 0 is for most of us.
One other thing, not related to this, is that I wish multi-display on/off is specified in SNAPI. Or is it?
You can allocate more memory to Duet by telnet ting into the master and typing SET DUET MEM. I typically do this from the get-go since the default setting is a little choky anyway.
DUET MEM was already set to the highest possible on this master at 36M. Does the new firmware allows more memory to be allocated to duet?
although you can set it for 36mb, you are now taking memory resources away from your other non duet memory items.. your total memory is static, from what i understand, unless you know what your volitile and non volitile memory requirements, its not recommened to use more then half of your available memory allowcations. AMX recommend 50/50 split, dont forget sockets use up netlinx memory too..
FWIW, I added a Duet Cisco codec module to a system the other night. The system failed to operate afterwards. After updating to v4 firmware everything worked fine but now takes around 3 times as long for the control system to boot to the point where the system is operational (~6 - 8 minutes if I had to guess). Unfortunately I haven't timed the before and after boot times and this is only based on my observations.
To answer the OP's question, based on my (bad) experiences using AMX provided Duet modules in systems, I would have to say that the max recommended Duet modules running on a master = 0.
Just my $0.02