Greetings! Many of you have provided feedback to our questions over the past couple years and we thought you might want to know how you have helped us. Pardon the longer note, but we think you will find this very interesting! Please reply with any thoughts you have. We are always interested and willing to listen!
-----------------------------
Your Feedback
=============
In the past, we have asked you about many different topics and heard many different responses, all which are being put to good use. These include topics like:
- What are your thoughts of SAM (some good and some bad :)
- What areas of SAM do you use
- How could SAM be enhanced
- UI technologies
- General system management: how do you do things & what you would like
In doing this, we have heard various feedback including:
- Performance (needs to be faster)
- Doesn't scale
- X is too heavy on the network
- Doesn't expose commands so we don't know what "OK" will do
- Want it as a learning tool
- Needs to support more command line options
- Command line does not have some of the features SAM does
- Useful for tasks that involve multiple steps
- GUI's should do something graphical
New Tools
=========
With a lot of this feedback, we have started down a path of enhancing SAM as can be seen in 11i v1.6 (11.22) and 11i v2 (11.23). This has not only involved the GUI/TUI but very much so the CLI (so when you reply to the SAM team, it's more than just the GUI - it's system management :). It initially began with the 11.22 release and the introduction of kcweb to replace SAM's Kernel Configuration area.
The kcweb initiative took the approach of offering a new web interface, but also significantly enhancing the command line interface (CLI) to ensure everything in the GUI is available at the command line. With this in mind, there was no TUI delivered believing a new, significantly enhanced CLI would meet this need (since then, we have understood the error in our ways :)
The results of kcweb provided:
- Tunable value checking is done in commands (kmtune/kctune)
- Reduced startup time to ~10 seconds (SAM cache took about 1 minute to build)
- No need to patch SAM to get new tunable and driver information
- New html web interface w/localized messages and help
- Command line preview
- Kernel tunable man pages (outside of SAM)
- Static/dynamic kernel tuning
- DLKM support
- Kernel tunable usage charts
- Set thresholds and alarms for kernel tunables
In 11i v2 (11.23), pdweb was delivered to replace SAM Peripheral Devices and Cards areas using the same ideas/features. This tool allows you to view the I/O tree and perform PCI card online addition and replacement. Here, new things were introduced that really addressed much of your feedback (performance being one of them) and we will highlight some things below.
Note that pre-11.23, SAM was the recommended way to perform PCI OL* operations (over the rad(1m) command) because it does extra error checking with critical resource analysis (CRA) and ensures proper execution of steps. In 11.23, the SAM functionality was pushed down into a new and improved CLI called olrad(1m). This new command simplifies the number of steps and performs critical resource analysis (everything SAM does).
The pdweb tool offers command line preview and full support of command line options. Most importantly, it is fully scalable and has significant performance improvements over SAM. Here are some examples:
- SAM startup time on an 11.23 rx2600 is ~20 seconds
- In SAM, building the list of devices could take over an hour
- Pdweb startup time on an 11.23 rx2600 is ~4 seconds (including starting Mozilla and Apache)
- Pdweb auto startup time from remote PC running IE is 2 seconds
- Eliminating frames sped up page generation as compared with kcweb
- Time to run critical resource analysis on 11i V1 (11.11) SAM ranged from 10 to 1200 seconds
- Time to run critical resource analysis on 11.23 from the CLI (or pdweb) ranges from 0.2 to 5 seconds (majority of the time it is sub-second)
We have also worked with the ioscan team to improve its performance. Say you have a system with 10,000 devices. The pdweb tool will probably take about 5 seconds to show the I/O tree listing when you first enter the tool and after that, 1 second between screens. Below are some timing runs that show the performance improvement of ioscan -k (for 10,000 devices in I/O tree):
old ioscan -F 60+ minutes (what SAM used)
old ioscan -k 3 minutes (what people asked us to use)
old ioscan -kF 27 minutes (what we would have had to use)
new ioscan -kF 5 seconds (what pdweb uses)
Besides improving the performance, a new option (-t) shows when the last full scan was run so you know if you are looking at old data and we know when to refresh our cache.
User Interfaces
===============
Concerning UI technologies:
A command line interface is critical. We will never remove this.
A terminal based UI is also very important. This should be simple and lightweight so it works when a GUI cannot.
We have moved from an X/motif interface to an html web-based interface. This is light on the network and can be used from any desktop with either a web browser or an X server. The Web UI and the TUI are no longer trying to be identical, as we want to use graphs, colors and fonts that can help with visualization and are not available in a terminal.
We have been cautioned to do the web interface right:
- we do not use port 80 or interfere with other web activities (have a special management port)
- we allow Apache to start and stop on demand and have a timeout feature
- we scale back Apache to have similar memory requirements as SAM.
- our web pages are small so our apps are usable over 56k connections
- we do not use Java (minimize startup time, system resources, and dependencies)
- everything is encrypted with SSL
- we support both Mozilla and IE
- we test with other browsers as well
Whew! There are some highlights of what has been delivered based on lots of customer feedback. We hope you found this useful and please provide any feedback you see fit.
Do You Like Green Eggs and Ham? (Sam I Am)
