SBC3 Wifi Testing - Revision history

Mparadis at 14:42, 26 March 2013

2013-03-26T14:42:49Z

← Older revision		Revision as of 14:42, 26 March 2013
Line 106:		Line 106:
	\|5		\|5
	\|-		\|-
	\|No-~~name Wireless N 300M~~ Adapter		\|[{{SERVER}}/products.php?product_id=3703 3703_0 - Wi-Fi USB Adapter 802.11n]
	\|19.7		\|19.7
	\|18.7		\|18.7
Line 112:		Line 112:
	\|}		\|}

	Right away you can see that a few of the devices stand out as being better than others in terms of reliability or speed. For example, the current Phidgets wifi adapter, the Patriot adapter, and the ~~No-name 300M adapter~~ all had relatively low retransmits and zero catastrophic failures. Though, it should be noted that the Patriot wifi adapter and ~~No-name 300M Adapters~~ were considerably more reliable, only suffering an average of less than 20 retransmits per 20 minute session. The EDUP EP-MS150NW and No-name 150M adapters were notably worse, both having thousands of retransmits and multiple catastrophic failures per 20 minute session.		Right away you can see that a few of the devices stand out as being better than others in terms of reliability or speed. For example, the current Phidgets wifi adapter, the Patriot adapter, and the [{{SERVER}}/products.php?product_id=3703 3703_0] all had relatively low retransmits and zero catastrophic failures. Though, it should be noted that the Patriot wifi adapter and [{{SERVER}}/products.php?product_id=3703 3703_0] were considerably more reliable, only suffering an average of less than 20 retransmits per 20 minute session. The EDUP EP-MS150NW and No-name 150M adapters were notably worse, both having thousands of retransmits and multiple catastrophic failures per 20 minute session.

	In addition, we can see that the Patriot adapter and the ~~No-name 300M adapter~~ were easily the fastest adapters we tested, with the Edup EP-N1528 and the ASUS USB-N13 following at half the speed. The Phidgets adapter performed very poorly, achieving one-tenth the average speed of the Patriot adapter and ~~No-name 300M adapter~~.		In addition, we can see that the Patriot adapter and the [{{SERVER}}/products.php?product_id=3703 3703_0] were easily the fastest adapters we tested, with the Edup EP-N1528 and the ASUS USB-N13 following at half the speed. The Phidgets adapter performed very poorly, achieving one-tenth the average speed of the Patriot adapter and [{{SERVER}}/products.php?product_id=3703 3703_0].

	What may become immediately apparent to someone looking at these results is how vastly different they all seem to be. However, it seems that the performance of a wireless adapter is closely related to the Linux driver associated with them. By using the command "lsusb" in the terminal while we have one of our wifi adapters plugged in, we can see what driver they are using.		What may become immediately apparent to someone looking at these results is how vastly different they all seem to be. However, it seems that the performance of a wireless adapter is closely related to the Linux driver associated with them. By using the command "lsusb" in the terminal while we have one of our wifi adapters plugged in, we can see what driver they are using.
Line 144:		Line 144:
	\|RT5370		\|RT5370
	\|-		\|-
	\|No-~~name Wireless N 300M~~ Adapter		\|[{{SERVER}}/products.php?product_id=3703 3703_0 - Wi-Fi USB Adapter 802.11n]
	\|RTL8191SU		\|RTL8191SU
	\|}		\|}

	With this new information we can see that the ~~No-name 300M adapter~~ uses the same driver as the Patriot adapter, which might explain why they both have such good performance. Additionally, the No-name 150M adapter and the EDUP EP-MS150NW adapter both share the same driver, which might explain why the both have such poor performance. Finally, the ASUS adapter and the EDUP EP-N1528 adapter also share the same driver.		With this new information we can see that the [{{SERVER}}/products.php?product_id=3703 3703_0] uses the same driver as the Patriot adapter, which might explain why they both have such good performance. Additionally, the No-name 150M adapter and the EDUP EP-MS150NW adapter both share the same driver, which might explain why the both have such poor performance. Finally, the ASUS adapter and the EDUP EP-N1528 adapter also share the same driver.

	From the information above, it can be concluded that the driver has a large impact on the performance of a wireless adapter, but it does not necessarily decide it's fate. For example, the EDUP-N1528 adapter had a much lower retransmission rate than the ASUS adapter did. So although it might be worth testing several different adapters that use different drivers, it may also be worth testing devices that use the same adapter.		From the information above, it can be concluded that the driver has a large impact on the performance of a wireless adapter, but it does not necessarily decide it's fate. For example, the EDUP-N1528 adapter had a much lower retransmission rate than the ASUS adapter did. So although it might be worth testing several different adapters that use different drivers, it may also be worth testing devices that use the same adapter.

	Ultimately, if performance and reliability is important to you, it's worth testing a few different products. Because, although the tests we ran on these devices were not necessarily thorough, they helped us narrow down the list of suitable devices, letting us cut out extremely unreliable adapters such as the No-name Wireless N 150M, Dlink DWA-140, ASUS USB-N13 and EDUP-MS150NW.		Ultimately, if performance and reliability is important to you, it's worth testing a few different products. Because, although the tests we ran on these devices were not necessarily thorough, they helped us narrow down the list of suitable devices, letting us cut out extremely unreliable adapters such as the No-name Wireless N 150M, Dlink DWA-140, ASUS USB-N13 and EDUP-MS150NW.

Mwbenedi at 21:11, 28 November 2012

2012-11-28T21:11:10Z

← Older revision		Revision as of 21:11, 28 November 2012
Line 1:		Line 1:
	~~'''This page is currently a work in progress'''~~

	While our current wifi adapters do work well on the SBC, they are, unfortunately, rather slow. And though the speed, or lack thereof, of our current wifi adapter rarely has a notable impact on our projects, it does occasionally raise some issues. So after it started to negatively affect the performance and functionality of one of our recent projects, we sought to find something a little faster and, if possible, more reliable than what we had available.		While our current wifi adapters do work well on the SBC, they are, unfortunately, rather slow. And though the speed, or lack thereof, of our current wifi adapter rarely has a notable impact on our projects, it does occasionally raise some issues. So after it started to negatively affect the performance and functionality of one of our recent projects, we sought to find something a little faster and, if possible, more reliable than what we had available.

Mwbenedi at 17:52, 28 November 2012

2012-11-28T17:52:25Z

← Older revision		Revision as of 17:52, 28 November 2012
Line 38:		Line 38:

	This will run a 20 minute long test. (you can change the length of the test by increasing or increasing the number 1200 above.) At the end, it will simply tell you the bandwidth over the network. For us, however, this program fills a vital role in flooding the network with wireless signals. If the wifi adapter is going to fail, it's going to fail during a time like this, when it's maxing out it's capabilities, and we're going to be able to see it.		This will run a 20 minute long test. (you can change the length of the test by increasing or increasing the number 1200 above.) At the end, it will simply tell you the bandwidth over the network. For us, however, this program fills a vital role in flooding the network with wireless signals. If the wifi adapter is going to fail, it's going to fail during a time like this, when it's maxing out it's capabilities, and we're going to be able to see it.
			[[File:Iptraf-dstat1.gif\|561px\|right]]


	'''iptraf'''		'''iptraf'''

	~~[[File:Iptraf-dstat1.gif\|561px\|right]]~~

Mwbenedi at 17:49, 28 November 2012

2012-11-28T17:49:29Z

← Older revision		Revision as of 17:49, 28 November 2012
Line 41:		Line 41:

	'''iptraf'''		'''iptraf'''

			[[File:Iptraf-dstat1.gif\|561px\|right]]

Mwbenedi at 21:03, 27 November 2012

2012-11-27T21:03:21Z

← Older revision		Revision as of 21:03, 27 November 2012
Line 72:		Line 72:
	! scope="col" \| Catastrophic Failures		! scope="col" \| Catastrophic Failures
	\|-		\|-
	\|~~Edup~~ EP-N1528		\|EDUP EP-N1528
	\|259		\|259
	\|10.2		\|10.2
	\|0.67		\|0.67
			\|-
			\|EDUP EP-MS150NW
			\|13871
			\|3.62
			\|4
	\|-		\|-
	\|Phidgets		\|Phidgets
Line 96:		Line 101:
	\|10.0		\|10.0
	\|1.33		\|1.33
	\|-
	~~\|EDUP EP-MS150NW~~
	~~\|13871~~
	~~\|3.62~~
	\|4
	\|-		\|-
	\|No-name Wireless N 150M Adapter		\|No-name Wireless N 150M Adapter
Line 108:		Line 108:
	\|-		\|-
	\|No-name Wireless N 300M Adapter		\|No-name Wireless N 300M Adapter
	\|~~107~~		\|19.7
	\|18.6		\|18.7
	\|0~~.67~~		\|0
	\|}		\|}

	Right away you can see that a few of the devices stand out as being better than others in terms of reliability or speed. For example, the current Phidgets wifi adapter and the ~~Patrio~~ adapter had relatively low retransmits and zero catastrophic failures. Though, it should be noted that the Patriot wifi adapter ~~was~~ considerably more reliable, only suffering an average of ~~about 7~~ retransmits per 20 minute session. The EDUP EP-~~MS150NM was~~ notably worse ~~that the other adapters~~, ~~reaching an average~~ of ~~over ten-thousand~~ retransmits and ~~four~~ catastrophic failures per 20 minute session.		Right away you can see that a few of the devices stand out as being better than others in terms of reliability or speed. For example, the current Phidgets wifi adapter, the Patriot adapter, and the No-name 300M adapter all had relatively low retransmits and zero catastrophic failures. Though, it should be noted that the Patriot wifi adapter and No-name 300M Adapters were considerably more reliable, only suffering an average of less than 20 retransmits per 20 minute session. The EDUP EP-MS150NW and No-name 150M adapters were notably worse, both having thousands of retransmits and multiple catastrophic failures per 20 minute session.

			In addition, we can see that the Patriot adapter and the No-name 300M adapter were easily the fastest adapters we tested, with the Edup EP-N1528 and the ASUS USB-N13 following at half the speed. The Phidgets adapter performed very poorly, achieving one-tenth the average speed of the Patriot adapter and No-name 300M adapter.

			What may become immediately apparent to someone looking at these results is how vastly different they all seem to be. However, it seems that the performance of a wireless adapter is closely related to the Linux driver associated with them. By using the command "lsusb" in the terminal while we have one of our wifi adapters plugged in, we can see what driver they are using.

			{\|border="1" cellpadding="5"
			\|-
			! scope="col" \| Adapter Name
			! scope="col" \| Driver
			\|-
			\|EDUP EP-N1528
			\|RTL8192CU
			\|-
			\|EDUP EP-MS150NW
			\|RT5370
			\|-
			\|Phidgets
			\|ZD1211B
			\|-
			\|Dlink DWA-140
			\|RT3072
			\|-
			\|Patriot Wireless N 300Mbps
			\|RTL8191SU
			\|-
			\|ASUS USB-N13
			\|RTL8192CU
			\|-
			\|No-name Wireless N 150M Adapter
			\|RT5370
			\|-
			\|No-name Wireless N 300M Adapter
			\|RTL8191SU
			\|}

	~~In addition,~~ we can see that the ~~Patriot~~ adapter ~~was easily~~ the ~~fastest~~ adapter ~~we tested~~, ~~with~~ the ~~Edup EP~~-~~N1528~~ and the ~~ASUS USB~~-~~N13 following at half~~ the ~~speed~~. ~~While~~ the ~~Phidgets~~ adapter ~~performed poorly, achieving one~~-~~tenth the average speed of~~ the ~~Patriot adapter~~.		With this new information we can see that the No-name 300M adapter uses the same driver as the Patriot adapter, which might explain why they both have such good performance. Additionally, the No-name 150M adapter and the EDUP EP-MS150NW adapter both share the same driver, which might explain why the both have such poor performance. Finally, the ASUS adapter and the EDUP EP-N1528 adapter also share the same driver.

	~~What may become immediately apparent to someone looking at these results is how vastly different they seem to be. However~~, it ~~seems~~ that the ~~results~~ of a ~~test are closely related to Linux driver associated with them~~. ~~By using~~ the ~~command "lsusb" in~~ the ~~terminal while we have one of our wifi~~ adapters ~~plugged in~~, ~~we can see what driver they are using~~.		From the information above, it can be concluded that the driver has a large impact on the performance of a wireless adapter, but it does not necessarily decide it's fate. For example, the EDUP-N1528 adapter had a much lower retransmission rate than the ASUS adapter did. So although it might be worth testing several different adapters that use different drivers, it may also be worth testing devices that use the same adapter.

	~~-Talk about the possibility for anyone~~ to ~~do any of their own~~ testing ~~at home and how~~ they ~~could streamline or automate~~ the ~~process to make it perhaps a little less time consuming~~.		Ultimately, if performance and reliability is important to you, it's worth testing a few different products. Because, although the tests we ran on these devices were not necessarily thorough, they helped us narrow down the list of suitable devices, letting us cut out extremely unreliable adapters such as the No-name Wireless N 150M, Dlink DWA-140, ASUS USB-N13 and EDUP-MS150NW.

Mwbenedi at 20:41, 27 November 2012

2012-11-27T20:41:04Z

@@ Line 101: / Line 101: @@
 |3.62
 |4
 |}

Mwbenedi at 20:01, 27 November 2012

2012-11-27T20:01:29Z

← Older revision		Revision as of 20:01, 27 November 2012
Line 72:		Line 72:
	! scope="col" \| Catastrophic Failures		! scope="col" \| Catastrophic Failures
	\|-		\|-
	\|Edup		\|Edup EP-N1528
	\|259		\|259
	\|10.2		\|10.2
Line 82:		Line 82:
	\|0		\|0
	\|-		\|-
	\|Dlink		\|Dlink DWA-140
	\|3454		\|3454
	\|5.9		\|5.9
	\|1.33		\|1.33
	\|-		\|-
	\|Patriot		\|Patriot Wireless N 300Mbps
	\|7.33		\|7.33
	\|18.5		\|18.5
	\|0		\|0
			\|-
			\|ASUS USB-N13
			\|1064
			\|10.0
			\|1.33
			\|-
			\|EDUP EP-MS150NW
			\|13871
			\|3.62
			\|4
	\|}		\|}

	~~-About~~ the ~~final conclusion for all~~ the wifi adapters that we tested~~. (Should I include exact prices here? Probably not. Definitely don't include links to~~ the ~~devices that I tested in~~ the ~~end~~. ~~It's probably okay to include~~ the ~~actual names~~ of the ~~devices that we tested though~~. ~~That~~ is, is the ~~names actually exist~~. ~~It seems like many of~~ the ~~devices didn't even~~ have ~~proper names..~~.)		Right away you can see that a few of the devices stand out as being better than others in terms of reliability or speed. For example, the current Phidgets wifi adapter and the Patrio adapter had relatively low retransmits and zero catastrophic failures. Though, it should be noted that the Patriot wifi adapter was considerably more reliable, only suffering an average of about 7 retransmits per 20 minute session. The EDUP EP-MS150NM was notably worse that the other adapters, reaching an average of over ten-thousand retransmits and four catastrophic failures per 20 minute session.

			In addition, we can see that the Patriot adapter was easily the fastest adapter we tested, with the Edup EP-N1528 and the ASUS USB-N13 following at half the speed. While the Phidgets adapter performed poorly, achieving one-tenth the average speed of the Patriot adapter.

			What may become immediately apparent to someone looking at these results is how vastly different they seem to be. However, it seems that the results of a test are closely related to Linux driver associated with them. By using the command "lsusb" in the terminal while we have one of our wifi adapters plugged in, we can see what driver they are using.

	-Talk about the possibility for anyone to do any of their own testing at home and how they could streamline or automate the process to make it perhaps a little less time consuming.		-Talk about the possibility for anyone to do any of their own testing at home and how they could streamline or automate the process to make it perhaps a little less time consuming.

Mwbenedi at 16:36, 27 November 2012

2012-11-27T16:36:34Z

@@ Line 63: / Line 63: @@
-In the end, these were some of the results that I gathered from some of the wifi adapters that we purchased:
+In the end, these were some of the results that I gathered from some of the wifi adapters that we purchased (Each number is taken as a average of all tests):
 -About the final conclusion for all the wifi adapters that we tested. (Should I include exact prices here? Probably not. Definitely don't include links to the devices that I tested in the end. It's probably okay to include the actual names of the devices that we tested though. That is, is the names actually exist. It seems like many of the devices didn't even have proper names...)
 -Talk about the possibility for anyone to do any of their own testing at home and how they could streamline or automate the process to make it perhaps a little less time consuming.

Mwbenedi at 16:21, 27 November 2012

2012-11-27T16:21:45Z

← Older revision		Revision as of 16:21, 27 November 2012
Line 5:		Line 5:
	But finding a fast and reliable wifi adapter isn't always as simple as going to the store and picking up the first thing you see. Most wifi adapters are created to work well with Windows and have very little concern for the select few users that might purchase their product to use with a Linux based operating system, such as the one that runs on the SBC. And though many of these same wifi adapters do work on Linux , the drivers to run them are rarely a shining example of perfection. The developers don't make enough money to justify perfecting the Linux drivers, they only want to get them working, not working well. The end result almost always has a handful of cut-corners and strange bugs popping up from time to time. So, inevitably, finding a fast and reliable wifi adapter means that you're going to have to do some testing yourself.		But finding a fast and reliable wifi adapter isn't always as simple as going to the store and picking up the first thing you see. Most wifi adapters are created to work well with Windows and have very little concern for the select few users that might purchase their product to use with a Linux based operating system, such as the one that runs on the SBC. And though many of these same wifi adapters do work on Linux , the drivers to run them are rarely a shining example of perfection. The developers don't make enough money to justify perfecting the Linux drivers, they only want to get them working, not working well. The end result almost always has a handful of cut-corners and strange bugs popping up from time to time. So, inevitably, finding a fast and reliable wifi adapter means that you're going to have to do some testing yourself.

	~~-About why Wifi testing is important.~~

			== Wifi Testing Is Difficult ==


	~~-About why Wifi testing is difficult~~

	Wifi testing can be a very difficult thing to do. Wireless signals are not constrained inside a tiny wire, they fly around in the air and bump into walls, people, animals, and even each other. A simple analogy might be to think about sending data across an ethernet cable as if you put a letter on a train in Chicago destined to New York. Unless the train derails, there's a pretty good chance that letter you sent is actually going to get to New York. Whereas sending data wirelessly would be like strapping your letter to a stray dog in Chicago and telling it to go to New York. I don't have the same confidence that your letter is ever going to arrive in New York.		Wifi testing can be a very difficult thing to do. Wireless signals are not constrained inside a tiny wire, they fly around in the air and bump into walls, people, animals, and even each other. A simple analogy might be to think about sending data across an ethernet cable as if you put a letter on a train in Chicago destined to New York. Unless the train derails, there's a pretty good chance that letter you sent is actually going to get to New York. Whereas sending data wirelessly would be like strapping your letter to a stray dog in Chicago and telling it to go to New York. I don't have the same confidence that your letter is ever going to arrive in New York.
Line 15:		Line 13:
	Different wireless protocols developed over the years have come to solve a lot of the issues that you can run into with wireless data transfers, but it's never going to be as simple as sending your data through a cable. Thes protocols need to implemented properly, and the hardware to transmit and receive signals can be very advanced. Small errors can render a device completely inoperable and utterly useless. And while large companies can afford to spend a million dollars, purchase some expensive equipment, hire some professionals, and build a warehouse to properly test every aspect of the devices in question, small companies and home users can't afford to be so lavish. Luckily, we don't have to spend a lot of money to narrow down the list of promising candidates and choose a good wifi adapter.		Different wireless protocols developed over the years have come to solve a lot of the issues that you can run into with wireless data transfers, but it's never going to be as simple as sending your data through a cable. Thes protocols need to implemented properly, and the hardware to transmit and receive signals can be very advanced. Small errors can render a device completely inoperable and utterly useless. And while large companies can afford to spend a million dollars, purchase some expensive equipment, hire some professionals, and build a warehouse to properly test every aspect of the devices in question, small companies and home users can't afford to be so lavish. Luckily, we don't have to spend a lot of money to narrow down the list of promising candidates and choose a good wifi adapter.

	~~-About the tools that I used to monitor the wifi devices.~~

	When it comes to wifi testing, there are a number of different tools you can use. When it comes to wifi testing on Linux, that number shrinks... a lot... And when it comes to wifi testing on Linux using only console-based applications, you don't have a lot of options. Fortunately, we don't need a whole lot. The kind of things that I thought were important to test were all things that could be tested with three simple programs.		== Wifi Testing Tools ==


	~~== iperf ==~~		When it comes to wifi testing, there are a number of different tools you can use. When it comes to wifi testing on Linux, that number suddenly shrinks... a lot... And when it comes to wifi testing on Linux using only console-based applications, well... you don't have a lot of options. Fortunately, we don't need a whole lot of options. The kind of things that I thought were most important to test were all things that could be tested with three very basic programs.


	~~This program lets you test bandwidth between two locations over a set amount of time. For all intents and purposes, it forms the backbone of our testing suite. We~~'~~ll need to have a computer running Linux (preferably connected to our local network with an ethernet cable) in addition to our SBC. This Linux computer is going to be considered our "server".~~		'''iperf'''

	From our server, two terminal windows and use one of them to SSH into the SBC. On the server, run the command:
			This program lets you test bandwidth between two locations over a set amount of time. You can also set other variables, such as packet size, TCP delay, or TCP Maximum segment size. For all intents and purposes, this forms the backbone of our testing suite. And though we're not going to bother fiddling with some of the more complicated options, we're going to be able to get a lot of important data out of the tests we run with this software.

			To use iperf, we'll need to have a computer running Linux (preferably connected to our local network with an ethernet cable) in addition to our SBC. This Linux computer is going to be considered our "server". On the other end is our SBC connected to the wireless network via some wifi adapter you wish to test, which is going to be considered out "client".

			From our server, open two terminal windows and use one of them to SSH into the SBC. On the server, run the command:

	iperf -s		iperf -s
Line 35:		Line 37:
	(If you don't know the ip address of the server you can find it by opening a third terminal window and typing: ifconfig )		(If you don't know the ip address of the server you can find it by opening a third terminal window and typing: ifconfig )

	This will run a 20 minute long test. (you can change the length of the test by increasing or increasing the number 1200 above.) At the end, it will simply tell you the bandwidth over the network. For us, however, this program fills a vital role in flooding the network with signals. If the wifi adapter is going to fail, it's going to fail during a time like this and we're going to be able to see it.		This will run a 20 minute long test. (you can change the length of the test by increasing or increasing the number 1200 above.) At the end, it will simply tell you the bandwidth over the network. For us, however, this program fills a vital role in flooding the network with wireless signals. If the wifi adapter is going to fail, it's going to fail during a time like this, when it's maxing out it's capabilities, and we're going to be able to see it.


			'''iptraf'''


			This is one of the programs we're going to use to monitor the connection we've set up with iperf. It has a pretty, colourful interface, at least when you compare it with the other programs we're using, and lot's of nice options to monitor different parts of the connection. Personally, I found the "Detailed Interface Statistics" to be the most useful, but you may want to explore the program a bit and learn some of its features.

			You can get a lot of data out of this program, but to be totally honest, I just used it as a way of checking to make sure that the wireless adapter hadn't failed catastrophically. That is, if the numbers stopped changing for a period of time, I assumed that the connection had been completely lost and I took note of it. And while I admit that this is a very primitive way of monitoring the network, it did in fact give me the results that I needed.


	~~== iptraf ==~~		'''watch 'netstat -s \| grep retransmited' '''


	This is ~~one~~ of the ~~programs we're going to use to monitor~~ the ~~connection~~. ~~It has a pretty~~, ~~colourful interface when~~ you ~~compare~~ it ~~with the other programs we're using~~ and ~~lot's of nice options~~ to ~~monitor different parts of~~ the ~~connection~~. ~~Personally~~, I found ~~the "Detailed Interface Statistics" to be the most useful.~~		This is actually more of a hack than a real program, but it works very well for what it is. By running this command in the terminal, you can see how many packets have been retransmitted since the device has been powered on. This number will update once every two seconds, so you can simply start it up and leave it running. Pay close attention to how many packets have been retransmitted. If the number climbs unexpectedly, you may have a problem with your wifi adapter. Typically, I found that good wifi adapters had 100 or less retransmits over a 20 minute test, while bad wifi adapters had well over 1000!

	You can get a lot of data out of this program, but to be totally honest, I just used it as a way of checking to make sure that the wireless adapter hadn't failed catastrophically. If the numbers stopped changing for a period of time, I assumed that the connection had been completely lost and I took note of it.

			== Collecting Data From Your Tests ==

	~~== watch 'netstat -s \| grep retransmited' ==~~

			You can experiment by running these tests at different distances and taking note of how the performance is affected. For each wifi adapter I tested, I ran three tests at short range and then three more at the longest range I could reach without having the wireless adapter completely disconnect. During the tests I took note of three things: the average bandwidth, the number of retransmits, and the number of times that the wifi adapter failed catastrophically. (By this I mean that the wifi adapter lost connection with the server.) Depending on how much testing you want to do, you could keep track of other things too, such as minimum bandwidth and maximum bandwidth. However, it's difficult to try and keep track of too many things at once without completely automating the tests, so I tried to gather only the most important data. Though, If you're planning on doing a lot of tests, you may want to find some kind of way to automate the tests anyway.

	This is actually more of a hack than a real program, but it works very well for what it is. By running this command in the terminal, you can see how many packets have been retransmitted since the device has been powered on. This number will update once every two seconds, so you can simply start it up and leave it running. Pay close attention to how many packets have been retransmitted. If the number climbs unexpectedly, you may have a problem with your wifi adapter. Typically, I found that good wifi adapters had 100 or less retransmits over a 20 minute test, while bad wifi adapters had over 1000!

	~~-About the results that I was able to gather immediately after single and multiple tests were completed.~~		== Testing Conclusions ==

	You can experiment by running these tests at different distances and taking note of how the performance is affected. For each wifi adapter I tested, I ran three tests at short range and then three more at the longest range I could reach without having the wireless adapter completely disconnect. During the tests I took note of three things: the average bandwidth, the number of retransmits, and the number of times that the wifi adapter failed catastrophically. (By this I mean that the wifi adapter lost connection with the server.) Depending on how much testing you want to do, you could keep track of other things too, such as minimum bandwidth and maximum bandwidth. However, it's difficult to try and keep track of too many things at once without completely automating the tests, so I tried to gather only the most important data.

	In the end, these were some of the results that I gathered from some of the wifi adapters that we purchased:		In the end, these were some of the results that I gathered from some of the wifi adapters that we purchased:

Mwbenedi at 22:17, 26 November 2012

2012-11-26T22:17:45Z

← Older revision		Revision as of 22:17, 26 November 2012
Line 42:		Line 42:

	This is one of the programs we're going to use to monitor the connection. It has a pretty, colourful interface when you compare it with the other programs we're using and lot's of nice options to monitor different parts of the connection. Personally, I found the "Detailed Interface Statistics" to be the most useful.		This is one of the programs we're going to use to monitor the connection. It has a pretty, colourful interface when you compare it with the other programs we're using and lot's of nice options to monitor different parts of the connection. Personally, I found the "Detailed Interface Statistics" to be the most useful.

			You can get a lot of data out of this program, but to be totally honest, I just used it as a way of checking to make sure that the wireless adapter hadn't failed catastrophically. If the numbers stopped changing for a period of time, I assumed that the connection had been completely lost and I took note of it.


Line 50:		Line 52:

	-About the results that I was able to gather immediately after single and multiple tests were completed.		-About the results that I was able to gather immediately after single and multiple tests were completed.

			You can experiment by running these tests at different distances and taking note of how the performance is affected. For each wifi adapter I tested, I ran three tests at short range and then three more at the longest range I could reach without having the wireless adapter completely disconnect. During the tests I took note of three things: the average bandwidth, the number of retransmits, and the number of times that the wifi adapter failed catastrophically. (By this I mean that the wifi adapter lost connection with the server.) Depending on how much testing you want to do, you could keep track of other things too, such as minimum bandwidth and maximum bandwidth. However, it's difficult to try and keep track of too many things at once without completely automating the tests, so I tried to gather only the most important data.

			In the end, these were some of the results that I gathered from some of the wifi adapters that we purchased:



	-About the final conclusion for all the wifi adapters that we tested. (Should I include exact prices here? Probably not. Definitely don't include links to the devices that I tested in the end. It's probably okay to include the actual names of the devices that we tested though. That is, is the names actually exist. It seems like many of the devices didn't even have proper names...)		-About the final conclusion for all the wifi adapters that we tested. (Should I include exact prices here? Probably not. Definitely don't include links to the devices that I tested in the end. It's probably okay to include the actual names of the devices that we tested though. That is, is the names actually exist. It seems like many of the devices didn't even have proper names...)

	-Talk about the possibility for anyone to do any of their own testing at home and how they could streamline or automate the process to make it perhaps a little less time consuming.		-Talk about the possibility for anyone to do any of their own testing at home and how they could streamline or automate the process to make it perhaps a little less time consuming.