Migrating Your Network to ePMP webinar replay

Hi Mat;

Apparently LINKPlanner doesn't show potential latency or at least readily visible to me.  But it does show predicted latency if you use the Excel spreadsheet 'ePMP Capacity Planner R2.4.3.'

Though I don't see where it offers you to do either Flexible Mode planning or GPS synch.  It appears that it defaults to just  GPS synch.  So you may want to check that document out.

So far, it is showing m:-

   Scheduling latency (ms)
      DL 6.7
      UL 27.5
      Total 34.2

Using a 2.5ms Frame Size, 20MHz channel size, 75/25 duty cycle and 3mi distance


The horizontal line is the peak RSSI.  Basically you mount the radio to the jpole/tower and then swing it around to get this value.  Once you know what the peak value is, you know what you're aiming for in an absolute real life best case situation.

You will see better TCP throughput on lower latency.  Because of this, 2.5ms is a wiser choice than 5ms frames.  Your aggregate throughput including non-TCP traffic would probably be a bit more with 5ms frames, but in a real life situation traffic is going to be much more commonly TCP (think HTTP - Facebook/Youtube/Netflix).

I'd say the main reason you see 5ms today would be due to deploying the AP before the software release of 2.5, of which introduced the 2.5ms frame feature.  I see no reason to deploy 5ms myself.


@Lincs_Chel wrote:

Hi Mat;

I was originally going to deploy our new setup using the new 2.5ms frame size.  As this seems to be what others seemingly were saying giving better results or what was being promoted as being a performance advantage. 

But now you brought another side to this.  So I guess before we start with our deployment I can probably play with the settings and results on paper.  Again, it will all be theory, but I guess it should be interesting.  I originally did all my LINKPlanner settings using the the 2.5ms frame.  But never really paid close attention to any performance differences.

On ePMP and PMP450, we've done some light testing between 2.5ms and 5ms frames. Basically, 2.5ms gives you approx. half the latency as 5ms frames at the expense of around 10% aggragate bandwidth. Flexible frames allows you the benefits of 2.5ms latency and a bit better throughput, the tradeoff being no GPS sync.


We had been originally on 5MS frames, and for that reason have not yet moved off them. As far as your comment, I suspect you’re speaking of the LFN calculation (Long Fat Network) that has to do with TCP ACK times and how much data is in flight. Sure an extra 20-30 MS will impact overall TCP streams, but if you’re running a large number of small streams you may actually get more overall aggregate traffic via a higher latency link with more downlink time.

That being said, 2.5 MS frames is on our plan for reviewed testing since 2.5 was released.

1 Like

Hello, where can I get the power point presentation for this Webinar? very good presentation by the way.

Hi Manuel,

I just sent the slides to your email