The current Maxelbot is quite complex when it comes to hardware. Each Maxelbot is equipped with the following components: 1 Lego robot platform equipped with Lego motors, 1 piece of plywood, 3 acoustic transducers, 3 parabolic cones, 2 minidragon microprocessor boards, 1 motor control printed circuit board (PCB), 1 trilateration PCB, and 3 XSRF acoustic sensor PCBs. Each of these components fills a vital role in the overall success of the robot.
First, the robot platform is built short so it has a low center of gravity and it will be more immune to tipping over in rough terrain. We ran into this problem early on in our testing. The trilateration platform, with all the sensors, cones, and electronics on it, was fairly heavy due mainly to the solid aluminum parabolic cones and the robot would tip over if it was on rough terrain or uneven ground. We changed the robot design, giving the robot a low center of gravity and wider wheelbase. This not only made our robots more immune to tipping, but also smaller.
Next, the square plywood board on the robot holds all of the trilateration hardware and connects the trilateration hardware to the robot platform. We have the three acoustic sensor PCBs mounted on the bottom of the plywood to reduce clutter on the top of the board and this also allows us to save space on the top of the board.
The rest of the trilateration hardware is mounted on the top of the board. The board has a parabolic cone mounted on three or its corners. Each of the two outer cones is mounted six inches away from the center cone. When all of the cones are mounted they form a 90 degree angle with a cone on the X axis and one on the Y axis. (*******This sounds bad, not explained very well*******).
1.7 inches above each cone is an acoustic transducer. We ran numerous tests to determine the optimum distance to place the cone above the transducer. We decided on a slightly higher value to optimize the transducer in receive mode and when the transducer is in transmit mode, the distance was slightly shorter, so we split the difference. This acoustic transducer is held in this spot by a piece of PCB which is attached to a piece of allthread by a couple of bolts the allthread is also attached to the plywood board by several bolts. This acoustic transducer is connected to the XSRF acoustic sensor through a twisted wire pair.
Also connected to the top of the board are the two minidragons. Each of these processors also has a PCB plugged in to it. These are also mounted to the top of the plywood board. This board also has a hole drilled in it to allow wires to connect the XSRF sensor to one of the minidragon boards through the trilateration PCB. There are several cables and many wires connecting the minidragon processors together as well as interfacing them with some other components like the acoustic sensor boards.
Next we have the acoustic sensor boards. These boards are a vital part of the trilateration process. These boards do the task of calculating the time it takes between when it receives the RF signal (the lightning) and when the acoustic pulse (the thunder) arrives. These boards send these pulses back to a minidragon where the trilateration calculations are made. Each PCB contains 7 integrated circuit chips: 2 - LMC6032 operational amplifiers, 2 - LP311 comparators, 1 – RS232 chip, 1 – PIC microprocessor, and 1 – MAX362 chip. These boards work in either transmit or receive mode. On the board there is a MAX362 chip that acts as a switch. This control chip along with 2 control lines control whether the sensor is in receive mode or in transmit mode. Transmit mode is easier, so we will explain this mode first. In transmit mode sensor receives a trigger pulse telling the sensor to start. Then the PIC microprocessor generates a 40 kHz signal for 8 pulses. Then this signal is sent to the RS232 chip where it is amplified and sent to the acoustic transducer. This generates our acoustic signal.
Receive mode is slightly more complicated. In receive mode, the trigger tells the sensor to start and the PIC microprocessor drives the echoline or timing pulse high. Then we get the signal in from the transducer and the switch will be in the right mode to route this signal to the receive part of the sensor. The signal first goes through a LMC6032 op amp, which provides two stages of amplification. Each stage will amplify the signal by 18 times. After the signal has been amplified by the first op amp, it goes through another LMC6032 op amp. This op amp provides one additional stage of amplification of 18, but this stage of amplification is also filtered. We use a 40 kHz bandpass filter to eliminate some of the noise in the signal that may have leaked through. This gives us a cleaner signal and better accuracy on our sensor. However, we had a little bit of trouble designing this filter. When we initially designed the filter to pass through 40 kHz; this is because that is the frequency of our signal. This filter was designed, built, and tested and it failed. It was passing through 36 kHz instead. In theory the filter worked, but not in practice. This problem was easily fixed though; we simply adjusted the resistors on the filter until it passed through 40 kHz. By doing this we were able to get the correct passband, but we reduced the gain of the filter from 18 to 15. This reduction is fairly insignificant so we can deal with it. Next the signal is passed to two comparators. Each comparator has a threshold voltage that it compares the voltage of the signal with. This threshold voltage is controlled by a potentiometer. One comparator is set to 2V and the other one is set to -2V. Once the signal coming in to the one of the comparators is greater than 2V or less than -2V, the comparator that saw this voltage will send a signal to the PIC microprocessor telling the processor to stop counting by driving the echoline low. This timing pulse that the PIC generated is sent to the minidragon to perform the trilateration calculations. This will happen for each of the three sensors and the minidragon will receive three pulses to do the trilateration with.
Next, we have the acoustic transducers. These transducers are sensors that are specially tuned to transmit and receive 40 kHz acoustic signals. We simply send the transducer a square wave with a frequency of 40 kHz and the transducer will transmit this signal for as long as the signal is being sent to the transducer. The transducer is also set up to receive a 40 kHz signal and all other frequencies will be ignored.
The parabolic cones also provide an important aspect of the trilateration. The parabolic cones are machined out of aluminum and they serve the purpose of sound distribution. The cones are machined so that when an acoustic signal is aimed at the parabolic cone, the cone will reflect the sound and distribute the signal out 360 degrees in a horizontal plane. This can be done because the cones are cut in the shape of a parabola so wherever the sound signal hits the cone it will be redirected along a horizontal plane. By spreading the signal out in a plane, we do not have to have the transmitting sensor pointing at the receiving sensor. We need two sensors pointed at the parabolic cones that are in the same horizontal plane. Then we can move the transmitting and receiving cones to anywhere in the same horizontal plane and we will still be able to transmit and receive the signal. The parabolic cones distribute the signal through 360 degrees so the power of the signal in the horizontal plane will be reduced. Even with this reduction, the receiver is still able to adequately pick up the signal from the transmitter at 8 feet away.
We also have two minidragon microprocessors on the robot. One of the processors is connected to the XSRF sensor boards and the I2C bus through the trilateration PCB. This processor is responsible for performing all of the trilateration calculations and sending them to the other minidragon microprocessor. The other processor takes these calculations and it uses them to control the motors on the microprocessor. This processor is also connected to the motor control PCB.
The trilateration PCB that is connected to one of the minidragons is populated with the RF transceiver. The minidragon uses the serial communications interface (SCI) to communicate with the RF module. This transceiver emits an RF signal at 315 kHz. This RF module provides the trigger signal (the lighting) for the trilateration process. The trilateration PCB was designed so that the RF module can easily switch between transmit mode and receive mode easily using a control line that we already use for the switch on the sensor boards. This RF module also handles the communication protocol between the robots. This communication protocol will be discussed later. This trilateration board also contains the pull up resistors for the I2C bus and a LED that is controlled by one of the control lines coming from the microprocessor. This LED is lit when the trilateration module is receiving data and it is off when the trilateration module is in transmit mode. The trilateration PCB is an auxiliary board that easily interfaces the sensor boards to the minidragon and provides RF communication between robots. This board has a connector that allows it to plug directly into the minidragon. This is very convenient because it makes the design less fragile and it also eliminates some of the wires.
We had only one minor problem with the trilateration PCB. The problem was that the RF signal coming from the RF module was providing a barely usable signal with lots of errors in it. We experimented with this for a while and noticed that when the minidragon is not connected to the trilateration PCB, the signal is at full strength, but when the minidragon is connected to the trilateration PCB, the signal is compressed and shifted by 2.5V. After some debugging we figured out that the problem was with the minidragon interface to the serial communications interface (SCI). The minidragon was assuming that the incoming signal was at RS232 standard level and not TTL logic levels. For this reason, the signal was getting passed through a RS232 chip and the logic levels were being compressed and shifted. We needed to bypass this RS232 chip and get our signal directly to the SCI receive pin. We were able to accomplish this by simply removing a solder bridge on the minidragon.
The last part of the robot is the motor control board that is connected to the other minidragon. This board also plugs directly in to the minidragon, making the design more durable and eliminating some wires. The motor control PCB is slightly more complicated than the trilateration PCB. This board contains two chips: a 74HC04 hex inverter and a 754410NE quad half Half-H driver. The quad half-H driver takes a supply voltage of 9.6V and it also requires 6 control lines. This chip uses a supply voltage of 9.6V because that is the voltage at which the motors have optimum performance. As for the control lines, 4 of these lines are used to control the direction of the motors. However, we do not actually need 4 control lines from the microprocessor to achieve this task. The quad half-H driver chip requires that it receive a signal and the same signal in quadrature (the opposite signal) for two different signals. This task is easily accomplished by taking only two signals from the minidragon and running them through a 74HC04 inverter. This will give us the four signals that we need; the two original signals and the two converted signals. The other two control lines for the quad half-H driver are to control the speed of the motors. One line is used to control the speed of the left wheel and the other signal controls the speed of the right wheel. We use a PWM signal to accomplish this task. The PWM will generate a square wave with a certain period and duty cycle and send this to the driver chip which in turn controls the motors. The PWM module controls the motor by turning the motor on and off really quickly. However, the motor usually cannot switch the motor on and off fast enough, so the pulse width modulation signal appears to just be providing the motors with a lower voltage and thus slowing down the motors. For example, if a 100% duty cycle is chosen, the motor will run at full speed. But if a 40% duty cycle is chosen, the motor will be on 40% of the time and off the other 60%, therefore the motor will run at 40% of full speed.
The motor control board works great now, but we ran into some problems in designing this PCB. First this PCB was designed to work with another processor board that we have. The female connectors of this PCB mate perfectly with the pins from the other processor. This is not really a problem, but the size and pinout of the PCB could have been optimized for the minidragon processor instead if the board had been designed for that. The next problem is much more significant. When we first designed this PCB, we took the breadboarded circuit and directly put this design on to a PCB and had the PCB fabricated. Then we got the PCB back and populated them. When we tested the PCBs, none of them worked properly. Only one wheel on the robot would work correctly and if both motors were plugged in, neither of the motors would work correctly. After extensive testing and debugging, we found several problems with the PCBs. First, there was no circuit protection on the circuit. We had no bypass capacitors on any supply lines and also unused inputs on the inverter were not terminated. Even without circuit protection, the PCBs would probably have worked, but it is always good to have. The other problem was the major reason that none of the boards worked. This problem was the fact that when we breadboarded up the circuit we used normal solid 24 gauge wire, which can handle more current then we required of the lines. When the PCB was designed, we failed to take into account this fact and the PCBs were designed using the default wires. These wires were not wide enough and what was happening on our PCBs is that the motors required more current then the wires could handle. The wire would then act similar to capacitor and prevent the motors from getting the required current. The PCB was then redesigned to include circuit protection and also the wires were widened to allow more than enough current to pass through to the motors. This PCB design was sent off to be fabricated and when we received the boards back and populated them, they worked very well.
When all these parts are combined together properly, we have produced one Maxelbot.
Sabtu, 15 November 2008
Telerobot Software
Description and Reference Information for Telerobot Software in Telelabs
Andrew Babbage's thesis provides useful background information on the development of the telerobot, the various software systems that were developed to provide this world famous internet site, and finally the LabVIEW robot interface routines. In particular chapter 6 provides a detailed account of functions for handling frames and calculating wrist rotation angles. Chapter 7 provides a useful outline, particularly in the first part, to show how robot movements are generated. The section on Active-X event processing needed more details – see S4EventLogger.vi description below. Chapter 8 was presented in outline only and this detailed documentation provides what is missing there. Andrew's most lasting contribution was to sort out how Active-X controls can be used to link LabVIEW with the ABB Robot S4 controller package RobComm.
I took over at the final stage of commissioning the telelabs software system that Andrew had started: Andrew was too busy with final exam preparation. I had to revise the structure of the 'run hardware' level and had a frustrating time trying to work out why some status change events were never received. Once this was resolved the rest was routine and I largely followed the telelabs templates for the hardware and remote clients.
There are several significant deficiencies that need to be remedied in the short term.
When the robot was briefly made available for public use over the weekend of 19th December, one user managed to crash the robot into the table. I am not sure how. The main issue was that we had no log files that recorded the robot movements so they could be played back for checking.
We urgently need a system to make users responsible: a registration system, so that we can track users and deny access to troublesome ones.
Andrew Babbage's thesis provides useful background information on the development of the telerobot, the various software systems that were developed to provide this world famous internet site, and finally the LabVIEW robot interface routines. In particular chapter 6 provides a detailed account of functions for handling frames and calculating wrist rotation angles. Chapter 7 provides a useful outline, particularly in the first part, to show how robot movements are generated. The section on Active-X event processing needed more details – see S4EventLogger.vi description below. Chapter 8 was presented in outline only and this detailed documentation provides what is missing there. Andrew's most lasting contribution was to sort out how Active-X controls can be used to link LabVIEW with the ABB Robot S4 controller package RobComm.
I took over at the final stage of commissioning the telelabs software system that Andrew had started: Andrew was too busy with final exam preparation. I had to revise the structure of the 'run hardware' level and had a frustrating time trying to work out why some status change events were never received. Once this was resolved the rest was routine and I largely followed the telelabs templates for the hardware and remote clients.
There are several significant deficiencies that need to be remedied in the short term.
When the robot was briefly made available for public use over the weekend of 19th December, one user managed to crash the robot into the table. I am not sure how. The main issue was that we had no log files that recorded the robot movements so they could be played back for checking.
We urgently need a system to make users responsible: a registration system, so that we can track users and deny access to troublesome ones.
Hardware Conference
Software and Complex Electronic Hardware Conference Information for Designated Engineering Representatives (DERs)
How may a Software/CEH DER meet recurrent training requirements?
To meet recurrent training requirements, all DERs must attend a DER Recurrent Seminar General Session plus a Technical Session for each of his or her engineering designation types.
There are ten engineering designation types distributed between six technical sessions:
1. Structures
2. Mechanical Equipment
3. Electrical Equipment and Radio
4. Powerplant, Engine, and Propeller
5. Flight Analyst and Flight Test Pilot
6. Acoustics
A DER may have a delegated function of Software and/or Complex Electronic Hardware approval in one or more of these designation types:
1. Electrical Equipment
2. Engines
3. Propeller
4. Mechanical Equipment
5. Powerplant
Software and CEH are not technical specialties, but rather, delegated functions in one or more of the five technical specialties.
Some DERs have only the Software and/or Complex Electronic Hardware delegated functions within one or more technical specialties. The Software/CEH Technical Session of the DER Recurrent Seminar Program was developed to specifically provide information to those DERs who have only the Software and/or Complex Electronic Hardware delegated functions, regardless of which technical specialties they hold. To meet recurrent training requirements, DERs who have authority for Software and/or Complex Electronic Hardware only may attend the Software/CEH Technical Session to fill the Technical Session requirement, but they are not required to attend this session. Otherwise, DERs with authority for Software and/or Complex Electronic Hardware only must attend a Technical Session for their technical specialty, even though Software or CEH topics may not be specifically discussed in that session. DERs with authority for Software and/or Complex Electronic Hardware only in more than one technical area, who do not attend the Software/CEH Technical Session, may attend the technical session deemed by their advisor to be the most appropriate to the work performed.
DERs who are authorized for a delegated functions in addition to Software and/or Complex Electronic Hardware (i.e., they are not a DER with authority for Software and/or Complex Electronic Hardware only) must attend a Technical Session for that technical specialty.
What is the Software and Complex Electronic Hardware Conference and how is it related to the DER Recurrent Seminar Program?
The Software and Complex Electronic Hardware Conference is sponsored by the Technical Programs Branch of the FAA (AIR-120) to address Software and Complex Electronic Hardware topics and issues. It is not part of the DER Recurrent Seminar Program. However, because it is budgeted and planned on a year-by-year basis, the conference cannot be guaranteed in any single year.
Does the Software and Complex Electronic Hardware Conference count for DER recurrent training?
To meet recurrent training requirements, DERs with authority for Software and/or Complex Electronic Hardware only may attend the Software and Complex Electronic Hardware Conference in lieu of the required DER Recurrent Seminar Program Technical Session (either the Software/CEH Technical Session or a Technical Session for their technical specialty). These DERs with authority for Software and/or Complex Electronic Hardware only must still attend a DER Recurrent Seminar General Session at one of the DER Recurrent Seminar Program locations. DERs who are authorized for a technical specialty in addition to Software and/or Complex Electronic Hardware must also attend a DER Recurrent Seminar Technical Session for that technical specialty.
How may a Software/CEH DER meet recurrent training requirements?
To meet recurrent training requirements, all DERs must attend a DER Recurrent Seminar General Session plus a Technical Session for each of his or her engineering designation types.
There are ten engineering designation types distributed between six technical sessions:
1. Structures
2. Mechanical Equipment
3. Electrical Equipment and Radio
4. Powerplant, Engine, and Propeller
5. Flight Analyst and Flight Test Pilot
6. Acoustics
A DER may have a delegated function of Software and/or Complex Electronic Hardware approval in one or more of these designation types:
1. Electrical Equipment
2. Engines
3. Propeller
4. Mechanical Equipment
5. Powerplant
Software and CEH are not technical specialties, but rather, delegated functions in one or more of the five technical specialties.
Some DERs have only the Software and/or Complex Electronic Hardware delegated functions within one or more technical specialties. The Software/CEH Technical Session of the DER Recurrent Seminar Program was developed to specifically provide information to those DERs who have only the Software and/or Complex Electronic Hardware delegated functions, regardless of which technical specialties they hold. To meet recurrent training requirements, DERs who have authority for Software and/or Complex Electronic Hardware only may attend the Software/CEH Technical Session to fill the Technical Session requirement, but they are not required to attend this session. Otherwise, DERs with authority for Software and/or Complex Electronic Hardware only must attend a Technical Session for their technical specialty, even though Software or CEH topics may not be specifically discussed in that session. DERs with authority for Software and/or Complex Electronic Hardware only in more than one technical area, who do not attend the Software/CEH Technical Session, may attend the technical session deemed by their advisor to be the most appropriate to the work performed.
DERs who are authorized for a delegated functions in addition to Software and/or Complex Electronic Hardware (i.e., they are not a DER with authority for Software and/or Complex Electronic Hardware only) must attend a Technical Session for that technical specialty.
What is the Software and Complex Electronic Hardware Conference and how is it related to the DER Recurrent Seminar Program?
The Software and Complex Electronic Hardware Conference is sponsored by the Technical Programs Branch of the FAA (AIR-120) to address Software and Complex Electronic Hardware topics and issues. It is not part of the DER Recurrent Seminar Program. However, because it is budgeted and planned on a year-by-year basis, the conference cannot be guaranteed in any single year.
Does the Software and Complex Electronic Hardware Conference count for DER recurrent training?
To meet recurrent training requirements, DERs with authority for Software and/or Complex Electronic Hardware only may attend the Software and Complex Electronic Hardware Conference in lieu of the required DER Recurrent Seminar Program Technical Session (either the Software/CEH Technical Session or a Technical Session for their technical specialty). These DERs with authority for Software and/or Complex Electronic Hardware only must still attend a DER Recurrent Seminar General Session at one of the DER Recurrent Seminar Program locations. DERs who are authorized for a technical specialty in addition to Software and/or Complex Electronic Hardware must also attend a DER Recurrent Seminar Technical Session for that technical specialty.
Hardware Sizing Recommendations
For NetScreen-Security Manager Feature Pack 3
Introduction
This document offers some guidelines on NetScreen-Security Manager hardware sizing. However, the detailed system requirements for each NSM component can vary greatly from installation to installation, depending on the size and topology of the network, the type of logging to be managed and other factors. It is advisable for customers to discuss their current and projected device management requirements with a Juniper Systems Engineer in order to ensure their needs will be met by the hardware they select.
Formulas and Guidelines
There are four basic elements involved in sizing: single vs. dual system, memory, storage space, and processor speed requirements. Specific requirements for each system will vary, but there are some general rules and formulas that can be applied.
Single or Dual System for GUI Server and Device Server
The GUI Server and Device Server are the two components of the management server. The GUI Server stores all configuration data and manages the UI connections, and the Device Server stores logs and maintains connectivity to the devices being managed.
For managing more than 1000 devices, it is recommended to use two Network Interface Cards (NIC) for both GUI Server and Device Server systems. One of the NIC cards is dedicated for the connection between GUI Server and Device Server. The other NIC card is used for GUI connections and device connections for GUI Server and Device Server respectively.
The GUI Server and Device Server may be combined if you have fewer than 200 devices, small device configuration sizes (e.g. large number of NS-5GTs with a few larger systems), and fewer than 1000 logs per second from all devices. Add at least 1GB RAM to the recommended GUI Server RAM to support this configuration.
Memory Requirements
GUI Server
Many factors are involved in determining the memory requirements for a given system, however the biggest factor is device configuration size.
First, make note of the number and type of devices that will be managed by NSM, and their configuration sizes. Configuration sizes can vary widely based on the number of rules in a policy and the number of VPN tunnels. To determine configuration size for a device look at the first line of the output of get config on the CLI. This is the size of the configuration for a device in bytes. Take the sum of the configuration sizes to be managed and refer to the table below to determine the estimated RAM required:
Total Config Size GUI Server RAM Required
Less than 2 MB 512 MB
Between 2 and 10 MB 3 GB
Between 10 and 50 MB 4 GB
More than 50 MB 8 GB
Device Server
The key factor in determining the memory requirements for the Device Server is the number of devices being managed. Use the table below to determine the requirements for a given deployment size:
Number of Devices Device Server RAM Required
Less than 200 1 GB
More than 200 2 GB
More than 500 4 GB
GUI Client
For managing more than 1000 devices, it is recommended to use PCs with 1 GB of RAM. In addition, it is recommended to make the following change in the NSM.lax file in the C:\Program Files\NetScreen-Security Manager directory on the client machines:
Change
lax.nl.java.option.java.heap.size.max=384m
to
lax.nl.java.option.java.heap.size.max=512m
Storage Space Requirements
GUI Server
Beyond the storage space required for the device configurations, there are additional items to be considered in sizing storage space. The GUI Server binaries and libraries require less than 100 MB.
Other key components that are disk space intensive are:
• Audit Log
• Error Log
• Device configuration database
• Nightly backup
The storage space requirements for each component are described in more detail below.
Audit Log
Audit log will have large impact on disk space depending upon audit log detail option configured. There are three options can be selected in guiSvr.cfg file located in /usr/netscreen/GuiSvr directory:
guiSvrManager.auditlog_flag 1 (Audit log is completely disabled if set=0)
guiSvrManager.auditlog_detail_flag 1 (Audit summary only is enabled if set=0)
Operation Audit Log Detail OFF Audit Log Detail ON
Update Device 10K 136 bytes 40 KB
Update Device 30K 136 bytes 60 KB
Update Device 300K 152 bytes 240 KB
Add Device 2 K 5 KB
Login in/out 180 bytes 180 bytes
Save Policy 25 rules 48 bytes .01 MB
Save Policy 100 rules 64 bytes 0.5 MB
Save Policy 250 rules 512 bytes 0.75 MB
Save Policy 1000 rules 1024 bytes 5 MB
Save Policy 5000 rules 2048 bytes 15 MB
For example, in a system with 100 devices with 10 KB configuration size per device and 1000 rules, 100 device updates and 5 policies saves will use (100 * 40 KB + 5 * 5 MB = 29 MB) 29 MB with the audit log detail option on, whereas it will take only (100 * 136 + 5 * 1 KB = 18 KB) 18 KB of disk space with audit log details turned off.
Error Log
The /var/netscreen/GuiSvr/errorLog directory keeps error log files (guidaemon.0). It stores up to 25 files before the oldest log files are overwritten. Each day’s file may be up to 5 MB in size. Based on these default settings, error logs can consume up to 125MB (or 250 MB if GUI Server and Device Server are on the same server).
Device Configuration Database
The size of the Device Configuration database can vary based on number of devices and types of configuration used. For every 1 MB of aggregate device configuration, NSM may need 200 MB disk space.
For example, 100 devices with 10 KB configuration may need (10 KB * 100) * 200 = 200 MB of disk space.
Nightly Backup
Nightly backup will maintain 7 copies of the GUI Server database if the default installation option is selected. The disk space requirement should be 7 * (device configuration database size calculated above).
Device Server
Storage capacity requirements are determined by the following equation:
(Retention period in days * Events per day * 200 bytes)/ 1,000,000,000 = storage size in GB.
Log events average around 200 bytes each. Following is a chart with some examples based on a retention period of 30 days:
Events Per Day Storage required in GB
1,000,000 6
10,000,000 60
25,000,000 150
50,000,000 300
If traffic logs are turned on, they generally comprise about 2/3 of all logs; so turning off traffic logs can result in a large savings in storage space.
In NSM, logs are stored in /var/netscreen directory of the Device Server by default. The /var directory should always be mounted on a separate partition or drive from / to avoid log files filling up your root partition and crashing your server. In situations calling for high volume logging, we recommend that /var be mounted on a locally attached high speed SCSI drive or similar performance storage solution. The path for log storage can be specified during initial installation.
In addition to regular logs, error logs may consume up to 125MB of storage space on the Device Server.
Processor Speed Requirements
GUI Server
A faster CPU in the GUI Server provides for a more responsive Log Viewer, and a faster feeling system overall. Our recommendation is to focus on a system that supports your storage and memory needs first, and get a mid-range to high-end processor for it. Dual processors have a negligible performance benefit for NSM, but may have additional performance benefits with future releases.
Device Server
In our testing, CPU speed had an impact on scalability on the Device Server in regard to sustained logging rates. A modern Intel or AMD CPU (i.e. 2.4GHz) or an UltraSparc III (1.2 GHz) is capable of handling sustained log rates in excess of 20,000 logs per second, while the SPARC processors in the Netra X1 that was used as a Global Pro Express appliance are able to handle fewer than 1900 logs per second.
A fast CPU on the Device Server is recommended for environments with high log volumes. For deployments using ScreenOS 4.0, maximum logging rates are approximately 1,900 events per second. For deployments using ScreenOS 5.0, maximum logging rates are approximately 20,000 events per second.
Introduction
This document offers some guidelines on NetScreen-Security Manager hardware sizing. However, the detailed system requirements for each NSM component can vary greatly from installation to installation, depending on the size and topology of the network, the type of logging to be managed and other factors. It is advisable for customers to discuss their current and projected device management requirements with a Juniper Systems Engineer in order to ensure their needs will be met by the hardware they select.
Formulas and Guidelines
There are four basic elements involved in sizing: single vs. dual system, memory, storage space, and processor speed requirements. Specific requirements for each system will vary, but there are some general rules and formulas that can be applied.
Single or Dual System for GUI Server and Device Server
The GUI Server and Device Server are the two components of the management server. The GUI Server stores all configuration data and manages the UI connections, and the Device Server stores logs and maintains connectivity to the devices being managed.
For managing more than 1000 devices, it is recommended to use two Network Interface Cards (NIC) for both GUI Server and Device Server systems. One of the NIC cards is dedicated for the connection between GUI Server and Device Server. The other NIC card is used for GUI connections and device connections for GUI Server and Device Server respectively.
The GUI Server and Device Server may be combined if you have fewer than 200 devices, small device configuration sizes (e.g. large number of NS-5GTs with a few larger systems), and fewer than 1000 logs per second from all devices. Add at least 1GB RAM to the recommended GUI Server RAM to support this configuration.
Memory Requirements
GUI Server
Many factors are involved in determining the memory requirements for a given system, however the biggest factor is device configuration size.
First, make note of the number and type of devices that will be managed by NSM, and their configuration sizes. Configuration sizes can vary widely based on the number of rules in a policy and the number of VPN tunnels. To determine configuration size for a device look at the first line of the output of get config on the CLI. This is the size of the configuration for a device in bytes. Take the sum of the configuration sizes to be managed and refer to the table below to determine the estimated RAM required:
Total Config Size GUI Server RAM Required
Less than 2 MB 512 MB
Between 2 and 10 MB 3 GB
Between 10 and 50 MB 4 GB
More than 50 MB 8 GB
Device Server
The key factor in determining the memory requirements for the Device Server is the number of devices being managed. Use the table below to determine the requirements for a given deployment size:
Number of Devices Device Server RAM Required
Less than 200 1 GB
More than 200 2 GB
More than 500 4 GB
GUI Client
For managing more than 1000 devices, it is recommended to use PCs with 1 GB of RAM. In addition, it is recommended to make the following change in the NSM.lax file in the C:\Program Files\NetScreen-Security Manager directory on the client machines:
Change
lax.nl.java.option.java.heap.size.max=384m
to
lax.nl.java.option.java.heap.size.max=512m
Storage Space Requirements
GUI Server
Beyond the storage space required for the device configurations, there are additional items to be considered in sizing storage space. The GUI Server binaries and libraries require less than 100 MB.
Other key components that are disk space intensive are:
• Audit Log
• Error Log
• Device configuration database
• Nightly backup
The storage space requirements for each component are described in more detail below.
Audit Log
Audit log will have large impact on disk space depending upon audit log detail option configured. There are three options can be selected in guiSvr.cfg file located in /usr/netscreen/GuiSvr directory:
guiSvrManager.auditlog_flag 1 (Audit log is completely disabled if set=0)
guiSvrManager.auditlog_detail_flag 1 (Audit summary only is enabled if set=0)
Operation Audit Log Detail OFF Audit Log Detail ON
Update Device 10K 136 bytes 40 KB
Update Device 30K 136 bytes 60 KB
Update Device 300K 152 bytes 240 KB
Add Device 2 K 5 KB
Login in/out 180 bytes 180 bytes
Save Policy 25 rules 48 bytes .01 MB
Save Policy 100 rules 64 bytes 0.5 MB
Save Policy 250 rules 512 bytes 0.75 MB
Save Policy 1000 rules 1024 bytes 5 MB
Save Policy 5000 rules 2048 bytes 15 MB
For example, in a system with 100 devices with 10 KB configuration size per device and 1000 rules, 100 device updates and 5 policies saves will use (100 * 40 KB + 5 * 5 MB = 29 MB) 29 MB with the audit log detail option on, whereas it will take only (100 * 136 + 5 * 1 KB = 18 KB) 18 KB of disk space with audit log details turned off.
Error Log
The /var/netscreen/GuiSvr/errorLog directory keeps error log files (guidaemon.0). It stores up to 25 files before the oldest log files are overwritten. Each day’s file may be up to 5 MB in size. Based on these default settings, error logs can consume up to 125MB (or 250 MB if GUI Server and Device Server are on the same server).
Device Configuration Database
The size of the Device Configuration database can vary based on number of devices and types of configuration used. For every 1 MB of aggregate device configuration, NSM may need 200 MB disk space.
For example, 100 devices with 10 KB configuration may need (10 KB * 100) * 200 = 200 MB of disk space.
Nightly Backup
Nightly backup will maintain 7 copies of the GUI Server database if the default installation option is selected. The disk space requirement should be 7 * (device configuration database size calculated above).
Device Server
Storage capacity requirements are determined by the following equation:
(Retention period in days * Events per day * 200 bytes)/ 1,000,000,000 = storage size in GB.
Log events average around 200 bytes each. Following is a chart with some examples based on a retention period of 30 days:
Events Per Day Storage required in GB
1,000,000 6
10,000,000 60
25,000,000 150
50,000,000 300
If traffic logs are turned on, they generally comprise about 2/3 of all logs; so turning off traffic logs can result in a large savings in storage space.
In NSM, logs are stored in /var/netscreen directory of the Device Server by default. The /var directory should always be mounted on a separate partition or drive from / to avoid log files filling up your root partition and crashing your server. In situations calling for high volume logging, we recommend that /var be mounted on a locally attached high speed SCSI drive or similar performance storage solution. The path for log storage can be specified during initial installation.
In addition to regular logs, error logs may consume up to 125MB of storage space on the Device Server.
Processor Speed Requirements
GUI Server
A faster CPU in the GUI Server provides for a more responsive Log Viewer, and a faster feeling system overall. Our recommendation is to focus on a system that supports your storage and memory needs first, and get a mid-range to high-end processor for it. Dual processors have a negligible performance benefit for NSM, but may have additional performance benefits with future releases.
Device Server
In our testing, CPU speed had an impact on scalability on the Device Server in regard to sustained logging rates. A modern Intel or AMD CPU (i.e. 2.4GHz) or an UltraSparc III (1.2 GHz) is capable of handling sustained log rates in excess of 20,000 logs per second, while the SPARC processors in the Netra X1 that was used as a Global Pro Express appliance are able to handle fewer than 1900 logs per second.
A fast CPU on the Device Server is recommended for environments with high log volumes. For deployments using ScreenOS 4.0, maximum logging rates are approximately 1,900 events per second. For deployments using ScreenOS 5.0, maximum logging rates are approximately 20,000 events per second.
WORKSTATION HARDWARE
APPENDIX E
WORKSTATION HARDWARE AND SOFTWARE STANDARDS
(1998-2001)
The following minimum standards to guide future computer hardware purchases were recommended by the Systemwide Internal Partnership in fall 1998 and incorporated into the Master Enabling Agreement with Inacom Corporation (1/21/1999). The principle behind the recommendations is that newly purchased computer hardware will be usable for three years from the date of purchase. These standards are therefore operative for the CSU Annual Campus Technology Survey for fiscal years 1999/2000 through 2000/01. Criteria for the survey covering FY 2001/02 will be based on revised recommendations made by the Commission on Technology Infrastructure in September 1999. For each survey period thereafter through the end of the reporting period, applicable standards will be those approved three years prior.
Minimum Hardware Standards for Windows Platforms
Recommended Minimum Desktop Hardware Standards (Effective FY 1998/99)
Processor Pentium® II processor 350 MHz with Intel 440 BX chipset
Cache: 512KB L2 cache integrated into the processor cartridge
Memory 64 MB of 100MHz SDRAM
Flash BIOS 2MB Flash memory
Graphics 8MB of 100MHz SGRAM, Advanced Multimedia Channel [AMC] video prot. Diamond, Matrox, or ATI 64/128 bit ABP board.
Audio Integrated full duplex audio [Sound Blaster Pro and Windows Sound System compatible]. External connectors for microphone, stereo input and stereo input and stereo-amplified output for speakers or headphones.
Hard Drive 6.4GB
EIDE EIDE Controller Integrated PCI
Floppy Disk Integrated floppy diskette drive support 3.5” 1.44MB diskette drive standard
CD-ROM: 20 x CD-ROM
Data Backup Internal
NIC 10/100Mb Fast Ethernet with ACPI and Wakup On LAN support, 10/100Base-TX, RJ45 twisted pair connector
I/O Connectors 2 USB, 2 serial, 1 high speed ECP/EPP parallel port, 1 PS/2 mourse, 1 PS/2 keyboard
Expansion Bus PCI, ISA, ACP and USB
Standards (ISO) 9002/ANSI/ASQC Q9002
Monitor 17inch FST with (0.27 dot pitch. Power consumption under 100W, 1024 x 768 resolution at 90 Hz
Sound Built-in stereo amplifier with 5 watt speakers. Bulit-in directional microphne. Low emissions, strict safety standard compliance
Operating Sys. Windows 98 or Windows NT 4.0
Recommended Minimum Laptop Hardware Standards
Processor 233 Mhz Pentium® II processor with Intel 440BX chipset
Memory 64 MB of 100MHz SDRAM
Hard Drive 4.0 GB hard drive
Display 12.1" TFT XGA display
Graphics 4MB of 100MHz SGRAM
Sound 16-bit SoundBlaster® Pro compatible voice and music functions
Operating Sys. Microsoft Windows 98, NT Workstation 4.0 (CD-ROM)
Modem 56Kbps, V.90 Upgradeable
CD-ROM: 20 x CD-ROM
External Ports Parallel, serial, VGA, PS/2, IRDA 1.1, USB, and docking port
Weight Maximum 8.0 pounds
Minimum Hardware Standards for Macintosh Platforms
Recommended Minimum Desktop Hardware Standards
Processor: 233 Mhz G3 (266 also available)
Memory: 64 MB RAM (32 MB extra memory optional)
Video RAM: 4 MB
Ethernet: 10/100BASE-T
Modem: 56 KB
Hard Drive: 4 GB (5.4 GB also available)
CD-ROM: 24 X
Monitor: 15" monitor, 800 x 600 resolution, built-in speakers, microphone
(17”, 1024 x 768 also available)
Keyboard: standard
Mouse: standard
Data Backup: Internal ZIP Drive (optional)
Recommended Minimum PowerBook Hardware Standards
Processor: 250 Mhz G3
Memory: 32 MB RAM
Ethernet: 10BASE-T
Modem: 33.6 KB
Hard Drive: 5 GB
Floppy Drive: 1.44 MB
CD-ROM: 24x CD-ROM (DVD encouraged - only in 400Mhz)
Display: 12.1”, 800 x 600 resolution
WORKSTATION HARDWARE AND SOFTWARE STANDARDS
(1998-2001)
The following minimum standards to guide future computer hardware purchases were recommended by the Systemwide Internal Partnership in fall 1998 and incorporated into the Master Enabling Agreement with Inacom Corporation (1/21/1999). The principle behind the recommendations is that newly purchased computer hardware will be usable for three years from the date of purchase. These standards are therefore operative for the CSU Annual Campus Technology Survey for fiscal years 1999/2000 through 2000/01. Criteria for the survey covering FY 2001/02 will be based on revised recommendations made by the Commission on Technology Infrastructure in September 1999. For each survey period thereafter through the end of the reporting period, applicable standards will be those approved three years prior.
Minimum Hardware Standards for Windows Platforms
Recommended Minimum Desktop Hardware Standards (Effective FY 1998/99)
Processor Pentium® II processor 350 MHz with Intel 440 BX chipset
Cache: 512KB L2 cache integrated into the processor cartridge
Memory 64 MB of 100MHz SDRAM
Flash BIOS 2MB Flash memory
Graphics 8MB of 100MHz SGRAM, Advanced Multimedia Channel [AMC] video prot. Diamond, Matrox, or ATI 64/128 bit ABP board.
Audio Integrated full duplex audio [Sound Blaster Pro and Windows Sound System compatible]. External connectors for microphone, stereo input and stereo input and stereo-amplified output for speakers or headphones.
Hard Drive 6.4GB
EIDE EIDE Controller Integrated PCI
Floppy Disk Integrated floppy diskette drive support 3.5” 1.44MB diskette drive standard
CD-ROM: 20 x CD-ROM
Data Backup Internal
NIC 10/100Mb Fast Ethernet with ACPI and Wakup On LAN support, 10/100Base-TX, RJ45 twisted pair connector
I/O Connectors 2 USB, 2 serial, 1 high speed ECP/EPP parallel port, 1 PS/2 mourse, 1 PS/2 keyboard
Expansion Bus PCI, ISA, ACP and USB
Standards (ISO) 9002/ANSI/ASQC Q9002
Monitor 17inch FST with (0.27 dot pitch. Power consumption under 100W, 1024 x 768 resolution at 90 Hz
Sound Built-in stereo amplifier with 5 watt speakers. Bulit-in directional microphne. Low emissions, strict safety standard compliance
Operating Sys. Windows 98 or Windows NT 4.0
Recommended Minimum Laptop Hardware Standards
Processor 233 Mhz Pentium® II processor with Intel 440BX chipset
Memory 64 MB of 100MHz SDRAM
Hard Drive 4.0 GB hard drive
Display 12.1" TFT XGA display
Graphics 4MB of 100MHz SGRAM
Sound 16-bit SoundBlaster® Pro compatible voice and music functions
Operating Sys. Microsoft Windows 98, NT Workstation 4.0 (CD-ROM)
Modem 56Kbps, V.90 Upgradeable
CD-ROM: 20 x CD-ROM
External Ports Parallel, serial, VGA, PS/2, IRDA 1.1, USB, and docking port
Weight Maximum 8.0 pounds
Minimum Hardware Standards for Macintosh Platforms
Recommended Minimum Desktop Hardware Standards
Processor: 233 Mhz G3 (266 also available)
Memory: 64 MB RAM (32 MB extra memory optional)
Video RAM: 4 MB
Ethernet: 10/100BASE-T
Modem: 56 KB
Hard Drive: 4 GB (5.4 GB also available)
CD-ROM: 24 X
Monitor: 15" monitor, 800 x 600 resolution, built-in speakers, microphone
(17”, 1024 x 768 also available)
Keyboard: standard
Mouse: standard
Data Backup: Internal ZIP Drive (optional)
Recommended Minimum PowerBook Hardware Standards
Processor: 250 Mhz G3
Memory: 32 MB RAM
Ethernet: 10BASE-T
Modem: 33.6 KB
Hard Drive: 5 GB
Floppy Drive: 1.44 MB
CD-ROM: 24x CD-ROM (DVD encouraged - only in 400Mhz)
Display: 12.1”, 800 x 600 resolution
A Mathematical Model of Hardware Prefetching
The time complexity of algorithms has traditionally been studied exclusively in terms of the instruction count. More recently, efforts to construct cache efficient algorithms have focused on adapting asymptotically optimal algorithms to the multiple tiers of the memory hierarchy. An additional hardware feature, though, makes several theoretically optimal cache efficient algorithms less effective in practice. The hardware prefetcher of the Intel Pentium 4 processor allows for bytes to be loaded from main memory into the L2 cache before being explicitly requested. To anticipate desired bytes, the prefetcher keeps track of previous cache misses. Its range is limited to 256 bytes ahead of current accesses and it can operate on up to eight concurrent data streams [1].
Given the magnitude of its allowed speedups, surprisingly little attention has been paid to studying the effects of the prefetcher for various algorithms. In the experiments of Pan et al., standard and cache efficient implementations of algorithms are studied with and without prefetching enabled. The prefetcher almost universally allows for significant improvement. For some of these algorithms, the prefetcher makes standard implementations faster than cache efficient ones, even when the cache efficient methods outperform standard ones without the prefetcher. This disparity implies that speedups delivered from the prefetcher are highly sensitive to memory access patterns. In order to understand these distinctions, a mathematical model of the prefetcher is developed.
Given the magnitude of its allowed speedups, surprisingly little attention has been paid to studying the effects of the prefetcher for various algorithms. In the experiments of Pan et al., standard and cache efficient implementations of algorithms are studied with and without prefetching enabled. The prefetcher almost universally allows for significant improvement. For some of these algorithms, the prefetcher makes standard implementations faster than cache efficient ones, even when the cache efficient methods outperform standard ones without the prefetcher. This disparity implies that speedups delivered from the prefetcher are highly sensitive to memory access patterns. In order to understand these distinctions, a mathematical model of the prefetcher is developed.
Bookkeeping Management System.
Hardware requirements for the LHCb Bookkeeping Management System.
Introduction
The conclusions made in this document are the result of the observations made on the server machines during the stress- test of AMGA server and while the Bookkeeping services are running for production.
The AMGA server was running on a dual processor machine (Xeon) of 2.4GHz each with 1 GB of memory. The bookkeeping production machine is a Pentium III of 850MHz with 768 MB of RAM.
Resource consumptions
AMGA has proven to be reasonably efficient in terms of resource consumption during the multi-client connections test. The memory consumption was around 10M per connection.
The only bottleneck to AMGA performance was the CPU which was fully used when 5 client where connected. ( see chart at http://www.physics.ox.ac.uk/users/cioffi/UKmetadata/Oxford/MultiClientsCon.xls). From the observation of the production system I could see that over few months very rarely three users were connected contemporaneously.
On the production machine are installed four python production servers, plus the Tomcat server. The same machine is also used as development machine with many other services running on it. All the services are supported very well by this old machine where a 33% average load is observed. None of these services is absorbing a reasonably amount of memory or CPU.
Hardware requirement
Based on the current use of the system by the Dirac developers and physicists a single dual-core machine as the one used for the AMGA testing will be enough to support the AMGA server and the other production services.
Based on the LHCb computing model where only one user will be the writer of the bookkeeping and all the others are readers, in case more than 5 contemporaneous connections are frequently exceeded, new instances of AMGA, with only read privilege, can be installed easily on separate machines.
Conclusion
It is my believe that a single dual-Xeon machine at 2.4 GHz with 1GB-1.5GB is sufficient to support all the bookkeeping Services till the real data taking from the detector.
Introduction
The conclusions made in this document are the result of the observations made on the server machines during the stress- test of AMGA server and while the Bookkeeping services are running for production.
The AMGA server was running on a dual processor machine (Xeon) of 2.4GHz each with 1 GB of memory. The bookkeeping production machine is a Pentium III of 850MHz with 768 MB of RAM.
Resource consumptions
AMGA has proven to be reasonably efficient in terms of resource consumption during the multi-client connections test. The memory consumption was around 10M per connection.
The only bottleneck to AMGA performance was the CPU which was fully used when 5 client where connected. ( see chart at http://www.physics.ox.ac.uk/users/cioffi/UKmetadata/Oxford/MultiClientsCon.xls). From the observation of the production system I could see that over few months very rarely three users were connected contemporaneously.
On the production machine are installed four python production servers, plus the Tomcat server. The same machine is also used as development machine with many other services running on it. All the services are supported very well by this old machine where a 33% average load is observed. None of these services is absorbing a reasonably amount of memory or CPU.
Hardware requirement
Based on the current use of the system by the Dirac developers and physicists a single dual-core machine as the one used for the AMGA testing will be enough to support the AMGA server and the other production services.
Based on the LHCb computing model where only one user will be the writer of the bookkeeping and all the others are readers, in case more than 5 contemporaneous connections are frequently exceeded, new instances of AMGA, with only read privilege, can be installed easily on separate machines.
Conclusion
It is my believe that a single dual-Xeon machine at 2.4 GHz with 1GB-1.5GB is sufficient to support all the bookkeeping Services till the real data taking from the detector.
Langgan:
Entri (Atom)
