Always remember that 3dB is Half Power in either direction, and the measurements are "Relative".
View the chart below and notice there is another factor of ten (10) hi-lighted in red. This chart will help you understand the back and forth conversions. Some access points show power settings in mW and some show it in dB. It is helpful to memorize the two (2) patterns.
10W = 40dBm = 10,000mW
8W = 39dBm = 8,000mW
4W = 36dBm = 4,000mW
2W = 33dBm = 2,000mW
1W = 30dBm = 1,000mW
800mW = 29dBm 27dBm = 512mW
400mW = 26dBm 24dBm = 256mW
200mW = 23dBm 21dBm = 128mW
100mW = 20dBm 20dBm = 100mW
50mW = 17dBm 18dBm = 64mW
25mW = 14dBm 15dBm = 32mW
12.5mW = 11dBm 12dBm = 16mW
10mW = 10dBm 10dBm = 10mW
6.25mW = 8dBm 9dBm = 8mW
3.125mW = 5dBm 6dBm = 4mW
1.56mW = 2dBm 3dBm = 2mW
1mW = 0dBm 0dBm = 1mW
Brett Hill, CWNE #147
Wednesday, January 27, 2016
Saturday, January 23, 2016
Understanding Milliwatt to dB conversion in the Wireless Survey
Decibel to milliwatt conversion is important in most every aspect of 802.11 wireless. We use it for antennas, cable loss, signal amplifiers, radio transmitters, etc..
One place that we do not always apply this knowledge and understanding is in the design stages of the wireless network. Particularly in the survey.
Depending on the data rate you are wanting to provide to all of your devices in the network, you will survey accordingly. We have to understand that every three (3) dB gained or lost in our rf signal is a direct result of half of our power being gained or lost.
For example: A transmitter set to 20dB power output is transmitting 100mW of power. If we transmit at 17dB, then our power output is cut in half to 50mW. That is a drastic difference to several applications and devices in 802.11 wireless based on the circumstance.
If you are using the Air Magnet or Ekahau survey tool to design your wireless network, you have to pay close attention to your measurement tools provided:
RSSI - Received Signal Strength Indicator - The signal from your transmitter
Noise Floor - Other devices in the area causing a signal to be detected on the frequency you are surveying with.
SNR - Signal - to - Noise - Ratio - The difference between the signal level your transmitter is transmitting and the signal received from the noise floor created by other devices.
The SNR is your usable signal and it is read in a positive decibel number compared to milliwatts. The RSSI and the noise floor are both read in a negative decibel number compared to milliwatts.
If you have a RSSI level of -70 and a noise floor of -92 then your SNR is the difference between the two numbers 22 and it is read in decibels compared to milliwatts (22dBm).
Where the understanding of the conversions comes into play is when your RSSI or the Noise Floor changes: -67 RSSI and a Noise Floor of -89. you still have 22dBm as a SNR. If the measurement of the RSSI is -64 on the meter, then you naturally think you have a better signal strength, but if the noise floor changes, then you have to factor in the change in the Noise Floor before believing you have a good signal for your design.
Remember, the SNR is the signal that really matters, and a 3dB difference in that effects your power by half. Sure the industry standard for Voice over wireless is a -67dB RSSI at the edge, but that is assuming a noise floor of -92dB or better. That's a minimum SNR of 25dBm.
If the Noise Floor goes from a -92dB to a -89dB then you have lost half of your power and that can have serious effects on certain applications in your network.
If your Noise Floor gains 1dB then you should increase your RSSI gain by 1dB to compensate for it. This is why most all survey engineers go ahead and survey for a RSSI of -65dB in the event that the Noise Floor fluctuates. It gives you a safety zone for your SNR because that is the number that really matters.
This is why a Spectrum Analysis is Imperative before starting your survey. You have to identify the noise floor you will be dealing with before you can provide a good design.
Remember***
3dB changes your transmit and/or receive power by half. This can lead to one way audio at times and it can lead to a downshift in data rates on either transmit, receive, or both. Keep your mind on the math as you survey.
One place that we do not always apply this knowledge and understanding is in the design stages of the wireless network. Particularly in the survey.
Depending on the data rate you are wanting to provide to all of your devices in the network, you will survey accordingly. We have to understand that every three (3) dB gained or lost in our rf signal is a direct result of half of our power being gained or lost.
For example: A transmitter set to 20dB power output is transmitting 100mW of power. If we transmit at 17dB, then our power output is cut in half to 50mW. That is a drastic difference to several applications and devices in 802.11 wireless based on the circumstance.
If you are using the Air Magnet or Ekahau survey tool to design your wireless network, you have to pay close attention to your measurement tools provided:
RSSI - Received Signal Strength Indicator - The signal from your transmitter
Noise Floor - Other devices in the area causing a signal to be detected on the frequency you are surveying with.
SNR - Signal - to - Noise - Ratio - The difference between the signal level your transmitter is transmitting and the signal received from the noise floor created by other devices.
The SNR is your usable signal and it is read in a positive decibel number compared to milliwatts. The RSSI and the noise floor are both read in a negative decibel number compared to milliwatts.
If you have a RSSI level of -70 and a noise floor of -92 then your SNR is the difference between the two numbers 22 and it is read in decibels compared to milliwatts (22dBm).
Where the understanding of the conversions comes into play is when your RSSI or the Noise Floor changes: -67 RSSI and a Noise Floor of -89. you still have 22dBm as a SNR. If the measurement of the RSSI is -64 on the meter, then you naturally think you have a better signal strength, but if the noise floor changes, then you have to factor in the change in the Noise Floor before believing you have a good signal for your design.
Remember, the SNR is the signal that really matters, and a 3dB difference in that effects your power by half. Sure the industry standard for Voice over wireless is a -67dB RSSI at the edge, but that is assuming a noise floor of -92dB or better. That's a minimum SNR of 25dBm.
If the Noise Floor goes from a -92dB to a -89dB then you have lost half of your power and that can have serious effects on certain applications in your network.
If your Noise Floor gains 1dB then you should increase your RSSI gain by 1dB to compensate for it. This is why most all survey engineers go ahead and survey for a RSSI of -65dB in the event that the Noise Floor fluctuates. It gives you a safety zone for your SNR because that is the number that really matters.
This is why a Spectrum Analysis is Imperative before starting your survey. You have to identify the noise floor you will be dealing with before you can provide a good design.
Remember***
3dB changes your transmit and/or receive power by half. This can lead to one way audio at times and it can lead to a downshift in data rates on either transmit, receive, or both. Keep your mind on the math as you survey.
Tuesday, January 19, 2016
Time Difference of Arrival
How does TDoA work?
The best way to describe TDoA is to give a reference of yourself and the way you hear things. The human ear is very remarkable by nature because it is used by the body to turn the head and eyes toward a sound that is heard. The really cool thing of this is that both ears hear the sound and process it over and over as they hear it (if it repeats or sustains). The reason why we are able to turn and look at what caused the noise is TDoA.
Time difference of arrival is math calculations that take place on frequencies heard by both ears to determine which ear is closer to the frequency, which direction the noise is coming from, and how far away the noise is.
When both ears hear the noise and the left ear heard it 5 micro seconds before the right ear heard it, then the math begins to direct the eyes to the left because TDoA determined that the noise came in to the left ear quicker than it did the right.
The TDoA calculations in 802.11 wireless location services operate similarly in the same manner. The signal from the same transmitting device is picked up from multiple access points and/or antennas and the calculations determine which access point the device is closer to as well as the direction the device is from each access point, resulting in calculating the location of a device.
There are several more cool factors in location services, but hopefully you now have an idea of what TDoA is and how it works.
The best way to describe TDoA is to give a reference of yourself and the way you hear things. The human ear is very remarkable by nature because it is used by the body to turn the head and eyes toward a sound that is heard. The really cool thing of this is that both ears hear the sound and process it over and over as they hear it (if it repeats or sustains). The reason why we are able to turn and look at what caused the noise is TDoA.
Time difference of arrival is math calculations that take place on frequencies heard by both ears to determine which ear is closer to the frequency, which direction the noise is coming from, and how far away the noise is.
When both ears hear the noise and the left ear heard it 5 micro seconds before the right ear heard it, then the math begins to direct the eyes to the left because TDoA determined that the noise came in to the left ear quicker than it did the right.
The TDoA calculations in 802.11 wireless location services operate similarly in the same manner. The signal from the same transmitting device is picked up from multiple access points and/or antennas and the calculations determine which access point the device is closer to as well as the direction the device is from each access point, resulting in calculating the location of a device.
There are several more cool factors in location services, but hopefully you now have an idea of what TDoA is and how it works.
Wednesday, January 13, 2016
Deploying Cisco WIPS - Overlay vs Integrated
When making choices about security for your wireless network, there are some ups and downs about everything you are going to have as options.
When deploying a Wireless Intrusion Prevention System, you should look into the abilities of both types of deployments to see which one is going to work for your environment.
Overlay WIPS- an overlay deployment is specifically a whole different set of access points designated to intrusion prevention only. In other words, after you have surveyed and designed the wireless coverage for client devices to access your network, you will go back to your floor plans and design a WIPS network that consist of a totally different set of access points deployed within the same area as the wireless network.
These WIPS access points will be deployed in monitor mode, then you will check the enhanced WIPS engine check box and choose WIPS in monitor mode optimization. You will then click save and you will be prompted to reboot the access point.
***Take note that you will have to disable the radio and admin status of the radio before configuring these settings. After you are done and the access point comes back up, you will need to enable both the radio and admin status.
The overlay option of deployment places the WIPS access points in a full time spectrum scan so that all channels can be scan on a continuous basis.
The Integrated option only scans part time, and that is only in between transmissions of data. If the access point is in use, the WIPS scan is not working and the network has a level of vulnerability. Also, when the access point is scanning in between transmissions, it doesn't always have a chance to scan all channels. It will only get through a few channels before it comes back to service client data again.
***Note Integrated is also often referred to as a WIPS deployment that controls its WIPS access points and its infrastructure access points all on the same controller. Many WIPS deployments (especially those for a large campus) will have separate controllers for each deployment. One for the infrastructure and one for the WIPS deployment. This is the most expensive option but is also the best approach to utilizing WIPS.
I've provided a Cisco link to the configuration of WIPS below:
http://www.cisco.com/c/en/us/td/docs/wireless/mse/3350/7-0MR1/wIPS/configuration/guide/wIPS_70MR1/msecg7x_ch6_wIPS.html
When deploying a Wireless Intrusion Prevention System, you should look into the abilities of both types of deployments to see which one is going to work for your environment.
Overlay WIPS- an overlay deployment is specifically a whole different set of access points designated to intrusion prevention only. In other words, after you have surveyed and designed the wireless coverage for client devices to access your network, you will go back to your floor plans and design a WIPS network that consist of a totally different set of access points deployed within the same area as the wireless network.
These WIPS access points will be deployed in monitor mode, then you will check the enhanced WIPS engine check box and choose WIPS in monitor mode optimization. You will then click save and you will be prompted to reboot the access point.
***Take note that you will have to disable the radio and admin status of the radio before configuring these settings. After you are done and the access point comes back up, you will need to enable both the radio and admin status.
The overlay option of deployment places the WIPS access points in a full time spectrum scan so that all channels can be scan on a continuous basis.
The Integrated option only scans part time, and that is only in between transmissions of data. If the access point is in use, the WIPS scan is not working and the network has a level of vulnerability. Also, when the access point is scanning in between transmissions, it doesn't always have a chance to scan all channels. It will only get through a few channels before it comes back to service client data again.
***Note Integrated is also often referred to as a WIPS deployment that controls its WIPS access points and its infrastructure access points all on the same controller. Many WIPS deployments (especially those for a large campus) will have separate controllers for each deployment. One for the infrastructure and one for the WIPS deployment. This is the most expensive option but is also the best approach to utilizing WIPS.
I've provided a Cisco link to the configuration of WIPS below:
http://www.cisco.com/c/en/us/td/docs/wireless/mse/3350/7-0MR1/wIPS/configuration/guide/wIPS_70MR1/msecg7x_ch6_wIPS.html
Tuesday, January 12, 2016
Can My design include signal propagation through steel grate floors to the lower level?
The $5 million question.....
Throughout the development of 802.11 wireless advancements, signal propagation has been questioned, tested, and requestioned in numerous scenarios. Fact is that in the earlier developed technologies refractions and reflections produced noise and interference against the original transmission, but now with MIMO and its abilities, reflections are used to the advantage of the transmission.
The reflected signal ultimately is out of phase and has fallen behind in time of arrival when compared to the original transmission, but now the two or more signals (main and out of phase reflections) become combined and used as multiple paths to transmit data packets on. When the reflected signal shows up at the target device say... 10 micro-seconds after the primary signal, then the primary signal is slowed down to be synchronized with the reflected signal. MIMO uses reflected paths to its advantage to transmit more data faster.
As far as the grated floors, the reflected signals work out the same way, but you do end up with a smaller RF footprint (coverage area) below due to the many unusable reflections. You should use your survey software on the lower level and measure the RSSI against the noise floor and packet losses and you will find the dependable area of coverage in a clean SNR with little to no packet loss. By no means is this area as big as the area covered on the upper floor, but it is absolutely dependable for VoIP grade coverage and can and should be incorporated into your overall design for access point placement. If you don't use this area, then you will end up with a very non-standard overlap in your cell coverage and VoIP will most likely suffer because of it.
VoIP works great at or around 20% overlap and this overlap needs to remain consistent across your design. 20% on one the 5% on another and 35% on the next will cause roaming issues for VoIP clients so any bleed through from floor to floor should be factored into the design to avoid issues.
Brett Hill, CWNE #147
Throughout the development of 802.11 wireless advancements, signal propagation has been questioned, tested, and requestioned in numerous scenarios. Fact is that in the earlier developed technologies refractions and reflections produced noise and interference against the original transmission, but now with MIMO and its abilities, reflections are used to the advantage of the transmission.
The reflected signal ultimately is out of phase and has fallen behind in time of arrival when compared to the original transmission, but now the two or more signals (main and out of phase reflections) become combined and used as multiple paths to transmit data packets on. When the reflected signal shows up at the target device say... 10 micro-seconds after the primary signal, then the primary signal is slowed down to be synchronized with the reflected signal. MIMO uses reflected paths to its advantage to transmit more data faster.
As far as the grated floors, the reflected signals work out the same way, but you do end up with a smaller RF footprint (coverage area) below due to the many unusable reflections. You should use your survey software on the lower level and measure the RSSI against the noise floor and packet losses and you will find the dependable area of coverage in a clean SNR with little to no packet loss. By no means is this area as big as the area covered on the upper floor, but it is absolutely dependable for VoIP grade coverage and can and should be incorporated into your overall design for access point placement. If you don't use this area, then you will end up with a very non-standard overlap in your cell coverage and VoIP will most likely suffer because of it.
VoIP works great at or around 20% overlap and this overlap needs to remain consistent across your design. 20% on one the 5% on another and 35% on the next will cause roaming issues for VoIP clients so any bleed through from floor to floor should be factored into the design to avoid issues.
Brett Hill, CWNE #147
Monday, January 11, 2016
Dropping calls on outdoor Mesh Deployments
This is a topic that I have dealt with for about 4 years during a government project deployment. Dealing with outdoor mesh deployments for the most part are relatively simple and hassle free, but there are some issues you will encounter and problems with VoIP is a hot topic.
Problem Encountered
When doing post installation testing of your outdoor mesh, you would typically want to use the VoIP phone and walk around the covered area, roaming from AP to AP, doing a "Can you hear me now?" commercial. By grabbing a couple of the phones (remember... designing for the devices to be used on the network is the best way) and placing a call between them, one person can walk the coverage area while the other monitors the call from an office somewhere. The non-mobile person will monitor the clarity of the call and pay attention to any moments where one side or the other cannot hear the other, and also take note of any dropped calls and where the call was dropped.
Lightweight AP design Glitch
When deploying mesh networks in a lightweight scenario, the controller sets the channels and the power just as it does for indoor deployments. Here is where the glitch is:
Indoors- the access points typically see each other in a relatively familiar pattern as the devices would pick up on them such as walls between them, high shelving, etc..
Outdoors- the access points mostly have a clear line of sight to each other because of the deployment model, while the devices themselves dwell at ground level between the buildings and other obstacles.
Why does this matter? Roaming.
Unless you are in a single channel architecture model, wireless devices will not roam across identical channels. Each access point that the device roams to has to be on a different channel than the one it is roaming from in order to hand off the connection without dropping it. This presents a problem with outdoor mesh deployments sometimes because the actual walk Path of the user varies significantly from actual coverage that the access points monitor from the roof tops.
There will come a time that calls will be dropped because your device is traveling from (scenario) say a channel 1 to a channel 1, or a channel 36 to a channel 36.
As an engineer, you will have to use something like Google maps and place all of your outdoor access points on the map, then view and even physically walk the area, locating all of the most common walk paths within the deployment coverage. This will help you identify how to manually set channels to avoid any of your walk paths containing a same channel roaming issue.
I have had to do this several times over the past few years to avoid dropped calls due to same channel roaming. I have attempted to tweak the sensitivity on the Auto channel option but it still had issues, and the best way to ensure the problem stayed away was to manually configure the channels and leave the power settings to my RF profile within the AP Group.
Note***
If you performed your survey correctly, ran a spec an of the area to identify and remove any interferers, and your power levels along with proper cell overlap is all correct, take a look at the channel situation because a controller does not take "Walk paths" into consideration when setting channels automatically.
Brett Hill, CWNE #147
Problem Encountered
When doing post installation testing of your outdoor mesh, you would typically want to use the VoIP phone and walk around the covered area, roaming from AP to AP, doing a "Can you hear me now?" commercial. By grabbing a couple of the phones (remember... designing for the devices to be used on the network is the best way) and placing a call between them, one person can walk the coverage area while the other monitors the call from an office somewhere. The non-mobile person will monitor the clarity of the call and pay attention to any moments where one side or the other cannot hear the other, and also take note of any dropped calls and where the call was dropped.
Lightweight AP design Glitch
When deploying mesh networks in a lightweight scenario, the controller sets the channels and the power just as it does for indoor deployments. Here is where the glitch is:
Indoors- the access points typically see each other in a relatively familiar pattern as the devices would pick up on them such as walls between them, high shelving, etc..
Outdoors- the access points mostly have a clear line of sight to each other because of the deployment model, while the devices themselves dwell at ground level between the buildings and other obstacles.
Why does this matter? Roaming.
Unless you are in a single channel architecture model, wireless devices will not roam across identical channels. Each access point that the device roams to has to be on a different channel than the one it is roaming from in order to hand off the connection without dropping it. This presents a problem with outdoor mesh deployments sometimes because the actual walk Path of the user varies significantly from actual coverage that the access points monitor from the roof tops.
There will come a time that calls will be dropped because your device is traveling from (scenario) say a channel 1 to a channel 1, or a channel 36 to a channel 36.
As an engineer, you will have to use something like Google maps and place all of your outdoor access points on the map, then view and even physically walk the area, locating all of the most common walk paths within the deployment coverage. This will help you identify how to manually set channels to avoid any of your walk paths containing a same channel roaming issue.
I have had to do this several times over the past few years to avoid dropped calls due to same channel roaming. I have attempted to tweak the sensitivity on the Auto channel option but it still had issues, and the best way to ensure the problem stayed away was to manually configure the channels and leave the power settings to my RF profile within the AP Group.
Note***
If you performed your survey correctly, ran a spec an of the area to identify and remove any interferers, and your power levels along with proper cell overlap is all correct, take a look at the channel situation because a controller does not take "Walk paths" into consideration when setting channels automatically.
Brett Hill, CWNE #147
Saturday, January 9, 2016
Priming your Cisco access points before deployment
Access point deployment can become a huge problem if your environment is one where an engineer designs, an admin configures, and a tech deploys, while a group of electricians pull the CAT5 or CAT6 cable. Too many hands in the deployment makes for multiple opportunities to have complications. It will also prove to take longer to resolve issues when troubleshooting.
One great way to rule out the access point itself as the problem (if problems arise) is to prime the access points before handing them off to the Tech for deployment.
When priming an access point, you take care of a lot of things up front that could go wrong in the field. One is code upgrade.
When an access point comes out of the box, it may or may not have the same code your controller is running. Once an access point comes up and finds a controller, it upgrades or downgrades its code to match the controller it has associated to. You can do this before deployment and avoid errors by handling it in a controlled lab environment.
Naming the Access Point
Another thing that is pretty cool to do ahead of time is naming the access point. Outside of placing a label on the access point, you can also name it so that when it comes up in the controller you can match it with your design document and know that that one particular deployment was successful. This will be of great help to you in large deployments. Especially those where you have multiple facilities over a large campus. Your design document should reflect access point models and names so you can reference the name latter if troubleshooting needs to take place. Quickly identifying an access point will speed up your troubleshooting process.
Redundancy
Another option is setting primary, secondary, and tertiary controllers for each access point. With the HA pairing option now, not many are using these options, but it is still a good fail safe to set in place in the event the HA pair may glitch on you. (can't have too many redundancies). I say if it's available, use it.
Type of deployment
During the priming stage, you can also pre-set an access point to a local mode access point, or several other modes available for deployment that allows an access point to monitor the network. It is good to pre-set these modes and verify they are correctly set before handing the access points off to the tech staff for deployment.
Mesh Access Points
When deploying Mesh access points, you have to pre-configure some things before the controller will recognize some access point models. The 1520, 1530, 1550, etc... all have to be added to the MAC Filtering table under the security tab before they will come up on your controller. This is a security feature that helps protect against rogue access points joining your network through your mesh deployments.
Priming the mesh access point allows you to set the AP to a root or non-root AP before sending it to the field and you can even test the bridge connectivity to verify the two will communicate.
By performing these priming steps in a lab environment, you can be confident that the access point isn't the problem once it is deployed and problems arise. You also have name comparison to help locate APs during troubleshooting sessions, and when deploying bridges, your priming stage has already verified communication between the two units before they are installed.
Ruling out Just a BAD Access Point
Not often, but sometimes an access point will come out of the box with a defect of some sort that needs to be addresses. I have wiped the flash and reloaded it in order to fix out of the box issues, but not all the issues can be fixed. You don't want to send an access point into the field and it come out of the box defective and your field tech stuck with dealing with it. You will wind up walking them through this remotely and probably still face delays by getting a replacement sent out anyway.
Priming the access points will eliminate sending defective units out for deployment.
If you don't prime, you're wasting time. Safe yourself and others a lot of headaches up front.
Brett Hill, CWNE #147
One great way to rule out the access point itself as the problem (if problems arise) is to prime the access points before handing them off to the Tech for deployment.
When priming an access point, you take care of a lot of things up front that could go wrong in the field. One is code upgrade.
When an access point comes out of the box, it may or may not have the same code your controller is running. Once an access point comes up and finds a controller, it upgrades or downgrades its code to match the controller it has associated to. You can do this before deployment and avoid errors by handling it in a controlled lab environment.
Naming the Access Point
Another thing that is pretty cool to do ahead of time is naming the access point. Outside of placing a label on the access point, you can also name it so that when it comes up in the controller you can match it with your design document and know that that one particular deployment was successful. This will be of great help to you in large deployments. Especially those where you have multiple facilities over a large campus. Your design document should reflect access point models and names so you can reference the name latter if troubleshooting needs to take place. Quickly identifying an access point will speed up your troubleshooting process.
Redundancy
Another option is setting primary, secondary, and tertiary controllers for each access point. With the HA pairing option now, not many are using these options, but it is still a good fail safe to set in place in the event the HA pair may glitch on you. (can't have too many redundancies). I say if it's available, use it.
Type of deployment
During the priming stage, you can also pre-set an access point to a local mode access point, or several other modes available for deployment that allows an access point to monitor the network. It is good to pre-set these modes and verify they are correctly set before handing the access points off to the tech staff for deployment.
Mesh Access Points
When deploying Mesh access points, you have to pre-configure some things before the controller will recognize some access point models. The 1520, 1530, 1550, etc... all have to be added to the MAC Filtering table under the security tab before they will come up on your controller. This is a security feature that helps protect against rogue access points joining your network through your mesh deployments.
Priming the mesh access point allows you to set the AP to a root or non-root AP before sending it to the field and you can even test the bridge connectivity to verify the two will communicate.
By performing these priming steps in a lab environment, you can be confident that the access point isn't the problem once it is deployed and problems arise. You also have name comparison to help locate APs during troubleshooting sessions, and when deploying bridges, your priming stage has already verified communication between the two units before they are installed.
Ruling out Just a BAD Access Point
Not often, but sometimes an access point will come out of the box with a defect of some sort that needs to be addresses. I have wiped the flash and reloaded it in order to fix out of the box issues, but not all the issues can be fixed. You don't want to send an access point into the field and it come out of the box defective and your field tech stuck with dealing with it. You will wind up walking them through this remotely and probably still face delays by getting a replacement sent out anyway.
Priming the access points will eliminate sending defective units out for deployment.
If you don't prime, you're wasting time. Safe yourself and others a lot of headaches up front.
Brett Hill, CWNE #147
Subscribe to:
Posts (Atom)