Backhaul is PTP 800
2016-03-10 20:52 GMT+01:00 Mathew Howard <[email protected]>: > Yeah... but what is the backhaul? specifically, is it an ePMP in TDD mode? > > On Thu, Mar 10, 2016 at 1:25 PM, Daniel Gerlach <[email protected]> > wrote: >> >> at the Switch Port full Speed with speedtest.net..webgui speed test >> 120/50 and with speedtest from CPE 17/10 with MCS 14-15 >> >> 2016-03-10 20:21 GMT+01:00 Josh Luthman <[email protected]>: >> > Mind if I ask what you're using for backhauls? I've got no issues. I'm >> > seeing fantastic speeds all the way around. >> > >> > >> > Josh Luthman >> > Office: 937-552-2340 >> > Direct: 937-552-2343 >> > 1100 Wayne St >> > Suite 1337 >> > Troy, OH 45373 >> > >> > On Thu, Mar 10, 2016 at 2:21 PM, Daniel Gerlach >> > <[email protected]> >> > wrote: >> >> >> >> we have the same Problem with the epmp Stuff..only problems and bugs >> >> from the beginning! >> >> >> >> 2016-03-07 17:00 GMT+01:00 Darren Shea <[email protected]>: >> >> > We had seen some issues with ePMP customers on high-speed plans >> >> > getting >> >> > poor speedtest results - we found that changing the customer's >> >> > router's MTU >> >> > from Auto to 1480 helped immensely. Another factor was to make sure >> >> > that all >> >> > backhauls in the path were running at full connection speed (in other >> >> > words, >> >> > a backhaul whose Ethernet port can run at 1000M should be running at >> >> > 1000M, >> >> > even if the traffic never approaches 100M) all the way out to the >> >> > internet. >> >> > >> >> > -- Darren >> >> > >> >> > -----Original Message----- >> >> > From: Af [mailto:[email protected]] On Behalf Of Justin Wilson >> >> > Sent: Sunday, March 06, 2016 10:27 AM >> >> > To: [email protected] >> >> > Subject: [AFMUG] Poor throughput on ePMP AP >> >> > >> >> > Sp I have an issue. Tower is a 4 sector ePMP setup and two backhauls. >> >> > We are seeing poor throughput when connected to the APs (all of >> >> > them). >> >> > Signals are great. Quality and capacity are great. When going >> >> > through the >> >> > AP we are consistently seeing 4-5 megs of download out to a known >> >> > speedtest >> >> > server. If we plug into the same wired port on which the AP, which >> >> > gave us >> >> > the poor throughput, we can max out the 100 meg uplink. Issue only >> >> > happens >> >> > when going through the wireless. Here is what I know: >> >> > >> >> > >> >> > 1.APs are set to 75/25. SM can do a link test and get 50meg x 12meg >> >> > on >> >> > the link test. So RF is good. Isolated AP to where only one client >> >> > was on. >> >> > Same great results. >> >> > >> >> > 2.Firmware does not seem to be a factor. Can reproduce this on >> >> > 2.6.1, >> >> > 2.5.1, and 2.4.3. >> >> > >> >> > 3.Have replaced POE injectors 3 times with different manufactures. >> >> > >> >> > 4.Does not matter if it is DHCP or PPPoE. Hard wired is fine. >> >> > Wireless >> >> > stinks. >> >> > >> >> > >> >> > The AP is plugged into a POE which then plugs into a Mikrotik 2011. >> >> > If >> >> > I plug into the same exact port the aps plug into speeds are great. >> >> > The only >> >> > thing that is left is patch cable to POE, Cable to AP, or AP. I >> >> > refuse to >> >> > think 6 cables on the tower do the exact same thing. The odds for >> >> > that are >> >> > Powerball winning crazy. Speediest from a laptop hooked to an SM to >> >> > the 2011 >> >> > are poor. 4-5 megs consistent with spikes up to 10-13, but all over >> >> > the >> >> > place. Acts like negotiation. Have set Mikrotik to Auto, to 100 meg >> >> > full, >> >> > only accepted 100 meg on auto. >> >> > >> >> > Customers who have 5 meg packages or below don’t see this. Those >> >> > with >> >> > 10 meg packages are the ones seeing 4-5 meg speeds. 10 meg packages >> >> > did >> >> > work. >> >> > >> >> > Clients are mainly at 2.6.1, but we can reproduce this with a 2.5 and >> >> > 2.4.x SMs. Nothign has changed in the network, which tests out just >> >> > fine up >> >> > to the point it gets handed off to the ePMP. >> >> > >> >> > Anyone ran into this? Any thoughts? >> >> > >> >> > Justin >> >> > >> >> > >> > >> > > >
