Re: [WISPA] Best system for a new WISP
Travis, Am I missing something? Yes you are. The results you are explaining are appropriate for Layer2 testing and UDP testing. (2% packet loss = 2% reduction in speed) Its different with TCP and way different with FTP. Understanding its 1:30am, my mind is shot after a 20 hour work day, and my theory may be a little weak as explanation, however the gist of it is TCP is a transmission Control Protocol, meaning it controls the flow of data when and how fast to transmit. Or in other words, detects when their is packet loss, and slows it self down when it occurs. If a PC sends data faster than the Link capacity, packet loss occurs. All TCP links have some level of packet loss. For example, common Bandwdith management programs purposely drop packets (thus packet loss) in order to slow down transmission of data to a specific speed. What keep a PC from sending 10 mbps of data across a 1 mbps link? The Answer is TCP. It slows down transmission to meet the speed of the link, determining that based on when packet loss occurs. We are talking very very low amounts of packetloss, for TCP to tune itself for error free transmission. However, when there is a large amount of packet loss (such as 2 %), it slows transmission way down, as TCP tries to resend lost packets, and instead of it getting done at the radio, it has to go all the way back to the PC to determine when data was not delivered and when needed retransmission. This is because transmission is connection based with TCP, a connection between PC and end destination. So if a packet is lost on a hop, there may be many hops of packets to determine that re-transmission is needed, adding large amounts of latency, slowing transmission to a screaching halt. Now of course Trango solves this problem with its ARQ feature. When you get 2% packetloss, the link speed goes down 2% plus a small overhead amount, and the end applications, PCs, and other OSI layers dont even know the packetloss occured, as Trango transparently corrected it. Many have argued a method of ARQ is part of the 802.11 protocol for reliable delivery, which is true, but the performance hit in terms of throughput and latency is huge. Not to mention some faster versions of 802.11 (a/g) may even get rid of some of those features in order to deliver the faster speeds. But I forget the theory on all that, so I won't go into it in this post. The second issue is how FTP operates. Beyond TCP native transmission control, my understanding is that FTP's application layer, also has routines to help control reliable delivery of data transfer. (UNless I am mistaken, and its jsut TCP doing its stuff). FTP tries to self correct transmission errors. If FTP sees any packet loss, it slows transmission, and if there is still packet loss, it slow transmission more, etc. Because packetloss on a wireless link often is not a factor of speed of transmission, (for example random interference which occurs a percentage of the time (time based) regardless of speed of data transfer), it never manages to correct errors in transmission (packet loss) by slowing down, so it keeps on slowing down more attempting to correct, until it is transfering the speed of dial UP. Layer3 and UP protocols are smart. They don't jsut accept that 2% of packets get lost. They have to do something about it, to increase reliabilty. That can come at a HUGE performance penalty. The protocols accept that as the idea is that generally there should not be packetloss of significant amount, just mild loss from congestion. However, thats not the case in Wireless applications. 2% packet loss extending back to the end user PC for correction, can DESTROY performance. How much? Depends on what application and what the thresholds are in their code. How TCP works and its thresholds are published under an RFC somewhere. There ar some charts I saw that charted how much performance is lost based on what percentage of packet loss occured. A small amount of packet loss has a small effect on packet loss, but a large amount has an exponential effect, and harms transfer at a much greater rate than the amount of inital packet loss. So back to testing... If using a TCP speed tester, it takes into account any packetloss in the link, and handles slowdown however TCP is designed to do it. So the speed tester will immulate what real world data transfer would be for a raw TCP application the end user would use. Where the problem occurs in testing speed, is when the end user application (such as FTP) uses its own criteria on what methods it uses to correct poor data transmission. It does not follow jsut the default TCP protocol code. It injects decssions from its application level code. We have noticed specifically with FTP, the rate it slows down is tremendously more than just the amount of packet loss on the radio. Thats not a bad thing, people want their data delivered in its entirety error
Re: [WISPA] Best system for a new WISP
Travis, Its real easy to demonstrate my point with Atlas PtP gear. You can hard set at various modulations, and start lowering power, until linktest shows the percentage of packetloss you want to test. Linktest is great to measure loss to tell when you got it at the right level for testing. (not nearly as easy with 802.11 gear to test, as hard to measure what the packet loss actually is at a given moment for accurate comparisons). Of course disable ARQ for testing. Then do the FTP. Just add 3-5% packet loss, and watch how slow FTP gets. The more hops you have between the Host and CLient FTP machines, the worse the performance gets affected by the packet loss. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Travis Johnson [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, April 12, 2006 9:46 PM Subject: Re: [WISPA] Best system for a new WISP Tom, I am confused about your testing. If you are testing a link, and it has 2% packet loss, then the link is going to run 2%-4% slower due to the loss, therefore the results will reflect that loss. Ever run a speed test across a link with 50% loss? If it's set to a 2Mbps connection, you get about 1Mbps when testing. It's still a 1Mbps connection, even with packet loss. Even using Trango's Linktest, it shows the maximum speed of the link BASED ON THE LOSS across the link. Am I missing something? I don't understand what you are trying to say. Travis Microserv Tom DeReggi wrote: Ok, assuming Real World Test win. How does your TCP test handle packet loss? Does it slow the test down to attempt to reduce packet loss until its gone? Thats what real world applications do, like FTP, and the real performance subscribers see, regardless of the Link's abilty to pass test traffic faster. I want to see the performance my customers experience. If your link has 2% packetloss, what impact will that have on customer's performance with various applications? Will your TCP tests show that. I'm not passing judgement, I'll let you make that judgement you wrote it. But my TCP tests (Iperf) do not get me that information. I've lost customers insisting that their link was operating perfectly based on TCP speed test, only to learn that the custoemr was right, and their performance was getting destroyed by packet loss. This is an important issue with Wireless, when packet loss is possible, due to interference and environmental condition changes. WRAP board were always in the 23 to 25 mbps range yet a UDP test would pull almost 35 mbps, Our testing never saw that. Typical numbers were always in the 1,800 to 2,000 KBytes/sec as reported by the FTP client. I don't contest that, based on a lab environemnt without packetloss. Did you repeat those tests, introducing interference/packet loss into the link? 2% packet loss with FTP, can bring your performance of a 25 mbps link down to 100 kbps. Does your test, replicate those results? I agree that TCP is a preferred test for a clean lab environment test, to test maximum obtainable speed. Butwho cares about that? What I want to know is what speed my link in the field is capable of doing, based on the conditions it is deployed in. I'm not in the business of delivering commodity Up-To Burstable Services. I am always amazed at how labels get applied. To call something a lower grade product Understand, I was not saying your product is lower grade than other, buts saying that your product is not being as good as it can be, if it had more types of testing tools. Its what, a days work, to add Iperf to OS image? Results are what count, not how pretty you look or how good you sound. But how do you know what your results are? If tests don't test accurately? It is strange to have to lie to the customer to get a high grade product rating. Maybe we don't need that, and for the most part my users don't want it either. They don't want packet loss either. Most of them prefer to have the whole file delivered intact. This is where you are loosing me. I'm not aware of anyone that lies to give a higher grade offering. My comments are based on results I see in the field with live deployments, that cost me clients and save me clients. I don't sell product or profit from what product user's select. I am not judging your test tool, I have never performed test measuring the accuracy of your testing tool. I am simply asking you the real hard question, for you to evaluate whether your test tool, method considers all the factors that need to be tested. You tell me, but prove it, with an explanation of how your tool handles it. Lonnie, its no big deal to us, we got a solution. We got Iperf running at every hop cell router, and have XP versions of Iperf to Email to our subscribers when tests need to be performed. Not all WISPs are in that position. Its to your advantage, to add the tools that
Re: [WISPA] Tech Support Call Center Interest ?
Peter, Fully agree. But much easier said than done. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Peter R. [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Thursday, April 13, 2006 12:38 AM Subject: Re: [WISPA] Tech Support Call Center Interest ? Tom, The key to growth in business is hiring the right people. You can successfully run more than one business at the same time with capable employees - as well as processes, procedures and controls in place. (This is the key to franchising and the E-Myth, btw). Three problems: 1) Finding the right people 2) Having the processes in place 3) Letting go. Regards, Peter Tom DeReggi wrote: Rick, I'm sure you'd do well at anything you put your mind to, and I'm sure you are capable. However, the only advice I can give is... The key to success is finding the time to manage your company. The only real person that can be trusted to do that well are the people that have stake in that compnay. In my company's case its me personally. There is only so much time in the day. A business owner needs to decide what business they want to be in, and then focus on that venture, its all one mortal human can handle in a competitive environment and succeed. A CALL CENTER is a Full time business, just like your WISP. Helping your WISP clients, means staff is not available to help Call Center clients at the same time, and vice versa. These problems go away, when both companies scale large enough to have their own staff. However, getting a company to that stage, of self operating, is where most business owners fail, its not easy. You are no longer able to pick up the slack on your own. Franchises often make it. But getting two businesses to that stage simultaneously is near impossible. So should your perogative to be a Call Center, go for it, thats what the American Dream is all about, you have just a good a chance as any one else. There is also a big need for a call center, where the owner has real world WISP experience to add credability to supporting WISPs. But to do a good job at a call center, be realistic that your WISP surely would sacrify to allow it to happen. Which business do you want to be in? Personally, its a struggle I face regularly. (WISP, Network integrator, Hardware reseller, router manufacturer, Software developer). Opportunity is on every corner, but you can't do it all well, which do you take? A WISP clearly is NOT the least risky of all the options out there. However, I chose to be a WISP. I am banking on reoccuring revenue, one day without requiring reoccuring work to match, and realistic about the fact I hate to be caught behind a desk 24x7. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Best system for a new WISP
agreed, VL is far from carrier grade On Apr 12, 2006, at 9:16 AM, Charles Wu wrote: snip Motorola designed Canopy specifically for the WISP market, not the carrier market. Alvarion designed VL specifically for the carrier market, not the WISP market. /snip Ah, the mis-perceptions of the rugged metal enclosure =) Steve, can you please explain why carriers would prefer a CSMA/CA over a scheduled (WiMAX-like) MAC? Thanks -Charles --- CWLab Technology Architects http://www.cwlab.com -Original Message- From: [EMAIL PROTECTED] [mailto:wireless- [EMAIL PROTECTED] On Behalf Of Steve Stroh Sent: Wednesday, April 12, 2006 11:05 AM To: WISPA General List Subject: Re: [WISPA] Best system for a new WISP Thanks, Steve On Apr 11, 2006, at 18:55, Dylan Oliver wrote: How is any product qualified as 'Carrier-Grade'? What is it about Alvarion VL that makes the cut vs. Canopy? Lord knows Motorola produces far more 'Carrier-Grade' equipment than Alvarion ever will - so where did they go wrong with Canopy? Also, I've heard lately several complaints that Waverider has trouble sustaining even 1 Mbps throughput ... what is your experience, John? Best, -- Dylan Oliver Primaverity, LLC-- --- Steve Stroh 425-939-0076 | [EMAIL PROTECTED] | www.stevestroh.com -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/ wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Best system for a new WISP
Tom, Again, I am confused. You state that TCP will correct for packet loss it detects... so in that case, FTP would never see the packet loss because TCP is already correcting for the loss. My point was, if you have a link with 2% loss, it will show up doing a TCP test by being slower than expected. Travis Microserv Tom DeReggi wrote: Travis, Am I missing something? Yes you are. The results you are explaining are appropriate for Layer2 testing and UDP testing. (2% packet loss = 2% reduction in speed) Its different with TCP and way different with FTP. Understanding its 1:30am, my mind is shot after a 20 hour work day, and my theory may be a little weak as explanation, however the gist of it is TCP is a transmission Control Protocol, meaning it controls the flow of data when and how fast to transmit. Or in other words, detects when their is packet loss, and slows it self down when it occurs. If a PC sends data faster than the Link capacity, packet loss occurs. All TCP links have some level of packet loss. For example, common Bandwdith management programs purposely drop packets (thus packet loss) in order to slow down transmission of data to a specific speed. What keep a PC from sending 10 mbps of data across a 1 mbps link? The Answer is TCP. It slows down transmission to meet the speed of the link, determining that based on when packet loss occurs. We are talking very very low amounts of packetloss, for TCP to tune itself for error free transmission. However, when there is a large amount of packet loss (such as 2 %), it slows transmission way down, as TCP tries to resend lost packets, and instead of it getting done at the radio, it has to go all the way back to the PC to determine when data was not delivered and when needed retransmission. This is because transmission is connection based with TCP, a connection between PC and end destination. So if a packet is lost on a hop, there may be many hops of packets to determine that re-transmission is needed, adding large amounts of latency, slowing transmission to a screaching halt. Now of course Trango solves this problem with its ARQ feature. When you get 2% packetloss, the link speed goes down 2% plus a small overhead amount, and the end applications, PCs, and other OSI layers dont even know the packetloss occured, as Trango transparently corrected it. Many have argued a method of ARQ is part of the 802.11 protocol for reliable delivery, which is true, but the performance hit in terms of throughput and latency is huge. Not to mention some faster versions of 802.11 (a/g) may even get rid of some of those features in order to deliver the faster speeds. But I forget the theory on all that, so I won't go into it in this post. The second issue is how FTP operates. Beyond TCP native transmission control, my understanding is that FTP's application layer, also has routines to help control reliable delivery of data transfer. (UNless I am mistaken, and its jsut TCP doing its stuff). FTP tries to self correct transmission errors. If FTP sees any packet loss, it slows transmission, and if there is still packet loss, it slow transmission more, etc. Because packetloss on a wireless link often is not a factor of speed of transmission, (for example random interference which occurs a percentage of the time (time based) regardless of speed of data transfer), it never manages to correct errors in transmission (packet loss) by slowing down, so it keeps on slowing down more attempting to correct, until it is transfering the speed of dial UP. Layer3 and UP protocols are smart. They don't jsut accept that 2% of packets get lost. They have to do something about it, to increase reliabilty. That can come at a HUGE performance penalty. The protocols accept that as the idea is that generally there should not be packetloss of significant amount, just mild loss from congestion. However, thats not the case in Wireless applications. 2% packet loss extending back to the end user PC for correction, can DESTROY performance. How much? Depends on what application and what the thresholds are in their code. How TCP works and its thresholds are published under an RFC somewhere. There ar some charts I saw that charted how much performance is lost based on what percentage of packet loss occured. A small amount of packet loss has a small effect on packet loss, but a large amount has an exponential effect, and harms transfer at a much greater rate than the amount of inital packet loss. So back to testing... If using a TCP speed tester, it takes into account any packetloss in the link, and handles slowdown however TCP is designed to do it. So the speed tester will immulate what real world data transfer would be for a raw TCP application the end user would use. Where the problem occurs in testing speed, is when the end user application (such as FTP) uses its own criteria on what methods it uses to
[WISPA] access near Shirley, WVa.
Anyone provide access in West Union, West Viriginia, near Shirley? Address: HC67 Box 197 West Union, W Va. 26456 I understand it's the backwoods. The customer is high up on a hill/mountain. Thanks. Mario --- [This e-mail was scanned for viruses by our AntiVirus Protection System] -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] FCC Sets Rules For AWS Auction
At its monthly open meeting earlier today, the Federal Communications Commission (FCC) approved plans to reallocate spectrum below 3 GHz now earmarked for new Advanced Wireless Services (AWS) and to set into motion a June 29 auction of the AWS radio frequencies for which the FCC expects to rake in more than $2 billion in license sales... http://www.telecomweb.com/news/1144871003.htm -- Regards, Peter RAD-INFO, Inc. - NSP Strategist We Help ISPs Connect Communicate 813.963.5884 http://4isps.com/newsletter.htm -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Best system for a new WISP
I was thinking I would be the devils advocate, and ask this question: Why go thru all the hassle of learning Mikrotik(Which, IMHO, Is a PITA), when You can save the learning curve, and use Tranzeo, Deliberant or even HighGain Antennas solutions that are cheap and easy to administer and a M0n0wall box at the NOC?. When You combine the assembly required for all the WRAP boards, buying the pigtails, and all of the other good stuff that goes along with being a MT shop, learning the management GUI etc., You could be up and running in no time with a M0n0wall box and gear shipped directly from the OEM's all ready assembled and ready to go. And M0n0wall is very easy compared to MT, and if You were so inclined, You could use the default settings and have a fairly decent network with an old P III and 512M of RAM, which is MUCH cheaper than any MT box. Granted, MT has a few more features, but the average WISP doesn't need half the stuff that is in there. Any thoughts? -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Best system for a new WISP
Travis, I agree my explanation is not complete regarding detail working of the protocols, and see your logic in your response, that what would FTP do if TCP already took care of it already. However, it doesn't work that way exactly. Does TCP fully take care of it? There are limits on how TCP works, and to truly understand them, I suggest you read the RFC, as its just been to long, since I read them, to explain them well. I don't need to remember the details anymore, just that the phenominon exists to watch out for. Part of it has to do with the reaction time TCP has to scale up and down speed. And when 802.11, waits for retransmission, how does TCP react to that? They have different timing rules in their decissions. I don't know the answers, why. Personally, I feel its the developer's job to figure that stuff out. My job is to sell radios. My job is to disclose real world findings, so it keeps the developers on their toes to consider everything they need to consider in doing their job. All I can tell is, create 3-5% packet loss consistently on a link, and perform an FTP, and watch the degregation escalate. And then watch and see if Iperf's TCP performance matches. Or for that matter perform a web based speed test, which can not be recognized as accurate, but regardless, the customer will through the Dial-UP speed results in your face, creating unnecessary support headache, so its relevant how the link responds to them. I have two tasks slated on my RD table. 1) Compare Alvarion and Mikrotik throughput in noisy environments. 2) Compare FTP and IPERF TCP tests over 802.11 gear, at various packet losses, and chart. (most of my real world is with TDD). But I probably won't get to it for a while, things are backed up and busy on the install front. I'd love someone to join this thread, that has detailed knowledge of the protocols, that could give a detailed explanation for us. Or step up to the plate to run the tests sooner, and report the results. Tom DeReggi RapidDSL Wireless, Inc IntAirNet- Fixed Wireless Broadband - Original Message - From: Travis Johnson [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Thursday, April 13, 2006 9:32 AM Subject: Re: [WISPA] Best system for a new WISP Tom, Again, I am confused. You state that TCP will correct for packet loss it detects... so in that case, FTP would never see the packet loss because TCP is already correcting for the loss. My point was, if you have a link with 2% loss, it will show up doing a TCP test by being slower than expected. Travis Microserv Tom DeReggi wrote: Travis, Am I missing something? Yes you are. The results you are explaining are appropriate for Layer2 testing and UDP testing. (2% packet loss = 2% reduction in speed) Its different with TCP and way different with FTP. Understanding its 1:30am, my mind is shot after a 20 hour work day, and my theory may be a little weak as explanation, however the gist of it is TCP is a transmission Control Protocol, meaning it controls the flow of data when and how fast to transmit. Or in other words, detects when their is packet loss, and slows it self down when it occurs. If a PC sends data faster than the Link capacity, packet loss occurs. All TCP links have some level of packet loss. For example, common Bandwdith management programs purposely drop packets (thus packet loss) in order to slow down transmission of data to a specific speed. What keep a PC from sending 10 mbps of data across a 1 mbps link? The Answer is TCP. It slows down transmission to meet the speed of the link, determining that based on when packet loss occurs. We are talking very very low amounts of packetloss, for TCP to tune itself for error free transmission. However, when there is a large amount of packet loss (such as 2 %), it slows transmission way down, as TCP tries to resend lost packets, and instead of it getting done at the radio, it has to go all the way back to the PC to determine when data was not delivered and when needed retransmission. This is because transmission is connection based with TCP, a connection between PC and end destination. So if a packet is lost on a hop, there may be many hops of packets to determine that re-transmission is needed, adding large amounts of latency, slowing transmission to a screaching halt. Now of course Trango solves this problem with its ARQ feature. When you get 2% packetloss, the link speed goes down 2% plus a small overhead amount, and the end applications, PCs, and other OSI layers dont even know the packetloss occured, as Trango transparently corrected it. Many have argued a method of ARQ is part of the 802.11 protocol for reliable delivery, which is true, but the performance hit in terms of throughput and latency is huge. Not to mention some faster versions of 802.11 (a/g) may even get rid of some of those features in order to deliver the faster speeds. But
Re: [WISPA] CPE's and the NEC
http://www.techexcess.net/apc-protectnet-ethernet-surge-protector-pnet1.aspx Just bumped into those the other day. Gonna try a few out. marlon - Original Message - From: Brian Rohrbacher [EMAIL PROTECTED] To: [EMAIL PROTECTED]; WISPA General List wireless@wispa.org Sent: Friday, April 07, 2006 12:12 PM Subject: Re: [WISPA] CPE's and the NEC My goal is to save my gear from static. I don't really care about lightning because I believe it cannot be stopped, but I can bleed off a little static and keep my ethernet ports working. (I hope) chris cooper wrote: On the surface it sounds like a good idea. Im no electrician, nor do I play one on television. Is it a good idea to have the ground in the same sheath as the conductors? Im thinking in a lightning strike- would it be better to shunt the surge onto the tower and tower ground asap or run it all the way down to the ground at the busbar? Does having the ground in the same sheath increase the likelihood of burning up the equipment in the enclosure/house/radio shack? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Rohrbacher Sent: Wednesday, April 05, 2006 6:52 PM To: WISPA General List Subject: Re: [WISPA] CPE's and the NEC I am currently waiting on 2 distributors who I'm contacted about getting cat5 with a grounding wire (either #10,12, or 14). They are getting a hold of the manufacturers and are going to see if they will make it and what the min commit it. I will let everyone know. Brian Jason wrote: How do all you guys in NEC enforcement areas handle the grounding issue? Details please. Currently I am not in an enforcement area, but that's about to change. Scratching head, Jason -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Anyone Hiring?
A jar head? As a WISP? What's the world coming to? ducking marlon cackle - Original Message - From: [EMAIL PROTECTED] To: wireless@wispa.org Sent: Monday, April 10, 2006 8:22 AM Subject: [WISPA] Anyone Hiring? Michael D. Lake4112 Berkshire Dr.Sarasota, FL. 34241(941) 718-0821[EMAIL PROTECTED] Objective:To establish a position within a reputable company, or city government agency, within the arena of Information Technology as one of the following,Chief Operations OfficerSenior Project ManagerProject ManagerLead Field Services Technician Work History 2003 – Present Subcontractor Alpha-Omega Communications, LLC. Accounts ManagerLead ConsultantLead Field Services TechnicianSite Surveyor/Engineer TasksRF/Wireless Engineering licensed and unlicensed networksEquipment/Network InstallationNetwork TroubleshootingComTrain Certified Safety/Rescue Tower Climber SalesEquipment Installation ServicesNetwork Trouble Shooting ServicesEngineering/Site SurveyingWired NetworkingWireless/RF NetworkingNon Physical Path Loss Calc.Customer Service 2002 – 2003 Install Guys Inc. RF/Wireless Field Services TechnicianRF Engineering/Site SurveyingEquipment Installation 1999 – 2002 Black Dog Towers Inc. Junior Project Manager turn Key raw site buildsField Services TechnicianTower ErectionSelf Supporting MonopoleGuyed Cellular CollocationSite Surveying 1998 – 1999 O’Brien Toyota Automotive Sales and Leasing Customer Service 1997 – 1998 Lake Roofing Sole Proprietor 1997 – 1998 Dick Boyd Ford Lincoln Mercury Automotive Sales and Leasing/RentalCustomer ServiceSales and Leasing professionalCar Rental Manager 1996 – 1998 Scandals Near The Lakeshore Customer ServiceBartenderWaiterGreeter/Host 1995 – 1996 Oppenhiemer Inc. Broker/Investment BankerTelemarketer 1991 – 1995 United States Marine Corps (USMC) 0351-Antitank Assault/DemolitionScout SwimmerNuclear Biological Chemical Warfare Non Commissioned OfficerCompany DriverTemporary Active Duty AssignmentsPlatoon CommanderPlatoon SergeantRecruiterU.S. State Department -- WISPA Wireless List: wireless@wispa.orgSubscribe/Unsubscribe:http://lists.wispa.org/mailman/listinfo/wirelessArchives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Best system for a new WISP
Get a 2.4 ap and a couple of cpe kits and do a small test install. If it looks good buy more. One of the first things we'd need to know in order to really help you out would be more info on what your competition is doing marlon - Original Message - From: Richard Goodin [EMAIL PROTECTED] To: wireless@wispa.org Sent: Monday, April 10, 2006 8:30 PM Subject: [WISPA] Best system for a new WISP I have been planning my WISP for about a year, and have yet to begin delivery of bandwidth to customers. My choice for service delivery was 802.11b, but with increased competition from other services nearby (about 5 miles away) I am wondering how to avoid problems. I have a 50' tower, and it is ROHN 45g. My choice for antennas would be 4 90 degree horizontal antennas. I have looked at bandwidth and shopped it to death. My best price is $400 from Lime Light. And I've built a couple of servers, acquired some switches and a router. The Router is a Cisco 1750. My questions: What CPE's and AP's would work best in this environment? I want to keep interferance to a minimum, as well as control costs. My environment includes lots of desert, and single story buildings. Lee -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Best system for a new WISP
And lets not forget about all of the really nice things that Motorola does for the WISP industry at the FCC. NOT marlon - Original Message - From: Matt Larsen - Lists [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Tuesday, April 11, 2006 12:20 PM Subject: Re: [WISPA] Best system for a new WISP As a former Canopy user, I would like to point out a couple of issues not mentioned here. 1) Canopy is limited to vertical polarity in PTMP deployments. Trango and many other systems can be deployed in horizontal polarity, pretty much avoiding any Canopy in the area. 2) Canopy systems will be more robust in comparison to other systems deployed at the same antenna gain and polarity, and they will also coexist nicely with other Canopy systems if they are all running GPS sync on the access points. HOWEVER, non-synced Canopy causes other Canopy systems all kinds of problems, and other types of systems will take a Canopy system down if the other system has higher gain and runs on the same path. Canopy will run with 3db of signal to noise separation, which is more robust than 802.11b for example which needs 5-6db - but that doesn't make it immune to noise. There are situations where the poor antenna design of the Canopy ends up getting more noise and will run worse than a better engineered 802.11b system. It is easy to build a 2000lb elephant (legally, I will add) that will kick the 500lb gorilla's butt. Been there, done that. I'm glad I don't have to deal with Canopy any more. Matt Larsen [EMAIL PROTECTED] Forrest W Christian wrote: Richard Goodin wrote: I have been planning my WISP for about a year, and have yet to begin delivery of bandwidth to customers. Since Canopy hasn't been mentioned yet, I'll mention it. You really can't go wrong with a canopy installation. It works, even in the presence of noise that would kill other systems. We swapped a dying (due to interference) Trango system with a canopy system well over a year ago and haven't looked back. As customers on our existing 802.11b network have problems we just swap them to Canopy. Some here will probably mention canopy's abusive spectrum use. Yes, Motorola uses a very agressive modulation which both provides for incredible interference robustness, but unfortunately doesn't play very well with others. Systems with marginal link budget will fail when put in the presence of a motorola radio. I have heard this referred to as the 500 pound gorilla approach - I.E. where does a 500 pound gorilla set? Anywhere he wants to. I find it hard to see this as a disavantage to the Canopy operator. After all this is business, and you need to make decisions which improve your bottom line. One more thing... you need to be very careful about FCC certification of systems. Many of the systems which people put together themselves are not legal in the eyes of the FCC. In short, buying a radio from vendor A and pairing it with an antenna from vendor B may or may not be legal, even if the EIRP limit is not exceeded. Plus, you will have vendors (distributors mostly) which will lie to you about whether or not a given pair is legal. Currently many WISP's are doing things which are definitely not legal under the rules, and count on the FCC's continued non-enforcement of the part-15 bands as part of their business plan. As being an Amateur Radio operator and seeing what happens when the FCC decides to actually pursue enforcement in a band, I wouldn't want to tie my continued business survival to illegal equipment. -forrest -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
[WISPA] Fw: Google, eBay and Amazon may build their own wireless Internet
- Original Message - From: John Oram [EMAIL PROTECTED] To: Lonnie Nunweiler [EMAIL PROTECTED]; Marlon Schafer [EMAIL PROTECTED] Sent: Thursday, April 13, 2006 6:17 PM Subject: Google, eBay and Amazon may build their own wireless Internet http://www.investors.com/editorial/IBDArticles.asp?artsec=17artnum=1issue=20060410 Internet Technology Internet, Media Outfits Could Bid For Spectrum BY REINHARDT KRAUSE INVESTOR'S BUSINESS DAILY Posted 4/10/2006 Analysts are speculating that Internet and media companies could team up to bid for radio spectrum in order to launch wireless broadband services, as a way around the phone companies. Rumors that nontelecom companies could bid for wireless spectrum have floated around for a few years. The new speculation focuses on large Internet content firms such as Google, (GOOG) Amazon.com, (AMZN) and eBay. (EBAY) Fueling the talk is a regulatory battle — the network neutrality issue — pitting Internet firms against phone companies ATT, (T) Verizon Communications, (VZ) and BellSouth. (BLS) Phone companies want to charge Internet firms for moving movies, video games, music and other bandwidth-hungry content over their networks. This is aside from the subscription fees they charge broadband subscribers. Under their plan, Internet firms would pay extra to transmit content via faster and more secure lanes on the Internet highway. Internet firms object. They want lawmakers and regulators to guarantee network neutrality. That means all Internet traffic would be treated the same, and that phone company customers couldn't get special treatment over others. Phone companies and cable TV operators provide most high-speed connections to homes. Cable firms are part of the debate, but for now phone outfits are in the forefront. By owning their own radio spectrum, Internet and media firms could deliver services to homes via their own wireless broadband pipe. But that's only if they pay the billions of dollars the spectrum is expected to garner at auction, plus build wireless networks. Few Taking Any Bets That's a big if, but phone companies are watching closely because the stakes are so high. It wouldn't shock me to find a range of unusual bidders in the upcoming spectrum auctions, said Jim Cicconi, ATT senior vice president for legislative affairs. But there's no question about his point of view. Experience has shown that some companies haven't needed a well thought-out business plan to bid (in earlier auctions), he said. The federal government has two big spectrum auctions in the works. One is scheduled for June and involves spectrum in the 1710-1755 and 2110-2155 MHz frequency bands. The second auction would involve frequency in the 700 MHz band. That auction depends on TV broadcasters returning spectrum to the government after they move to high definition. That auction might not occur until 2008. Cicconi suggests that wireless broadband might not be the best business for Internet or media firms. He says they might be better off cutting a deal with ATT or other phone companies, which are experienced network operators. Any content provider would have a build vs. buy (bandwidth) decision to make, he added. What's the cost of building out your own network as opposed to contracting for a service? Real-Time Video Isn't Easy Cicconi adds that it would be challenging for Internet firms to deliver streaming video services reliably via wireless broadband. Some methods that Internet and media firms seem to be eyeing don't involve real-time streaming. Instead, video or other content could be downloaded to a computer, digital video recorder or portable device. That's less taxing on a network. ATT and other phone companies have promised not to block network access or degrade service to companies that don't agree to pay a premium rate. And current services that gobble up bandwidth — such as Google's video store and Apple Computer's (AAPL) iTunes music service — seem to be doing fine. Internet companies are eyeing bigger bandwidth-hungry services, analysts say. Amazon, for one, is expected to launch a digital distribution service including music and movies by year-end. Phone carriers say it's unfair for them to invest more in network infrastructure to carry Internet firms' content if they can't make more money as the middleman. It's unclear whether Congress or the Federal Communications Commission will adopt any broad policies involving network neutrality. One bill in Congress would let the FCC address complaints from content firms on a case-by-case basis. Web companies that have pushed for Congress' help include Google, Amazon, eBay, Microsoft (MSFT) and Yahoo. (YHOO) Walt Disney (DIS) has said it doesn't think legislation to guarantee network neutrality is yet needed. Yahoo has kept a low profile on this issue. It has big plans to deliver on-demand content. It also is an Internet
