I have one 5.8 Sector with 5 clients on it. 4 of the clients are fairly close in (< 0.5 miles). One of the clients is far away (~ 7.5 miles). All of the clients have great signal strength and very low noise. Signal strength is around greater than -72 for all of them and noise is -102 throughout.

We are running an SR5 on the AP and either SR5 or CM9 on the clients.

I am seeing good performance on all of the short distance links and bad performance on the link 7.5 miles out. The 7.5 mile link remains established, but the throughput is very low (1 - 2 Mbps), while the short links are all very fast (6 - 7 Mbps).

I tried to switch on NStreme to see if this would improve performance, but the 7.5 mile client would take 2 minutes just to connect, while the close clients would connect instantly. Throughput is still marginal.

We are running 2.9.39 on all of the devices in this sector.

Any idea why I'm seeing poor performance far out, but good performance close in? Anything I can do to fix it?

Probably goes without saying, but is your ACK time set to "dynamic"?

Yes, the ack timeout is set to dynamic.

What else should I check?

7.5mi is a long shot for 5.8. Is there any way to go 2.4 on that link?

I suppose we could try, but I have another 5.8 link that is the same distance (7.5 mi) running right next to it and the throughput on that is 10 Mbps no problem.

Mikrotik Support suggested trying Dynamic Framing Policy in NStreme, but I have no idea if that will do anything. I have to bounce this link in order to try it and I would like some assurance that it is worth trying.

Do those framing policies actually make any difference?

It seems like whenever I try to switch from one to the other, it doesn't really make any difference.

Anything else to try to get this one link working?

7.5mi is a long shot for 5.8. Is there any way to go 2.4 on that link?

7.5 miles is in no way a long shot for 5.8Ghz, our experience is that 5.8Ghz is MUCH better for longer shots than 2.4Ghz - the fresnel zone is significantly smaller, and the noise is significantly lower which allows lower received signals to maintain a great SNR for good throughput!

As to the original post, it sounds like your SNR is good. What is the CCQ and SNR actually reading in the radio?

Also:

I suppose we could try, but I have another 5.8 link that is the same distance (7.5 mi) running right next to it and the throughput on that is 10 Mbps no problem.

How "right next to it"? That could be your problem. Is it on an adjacent channel? Is the polarization the same?

FYI:
The problem here ended up being that we put one of the 5.8 units into NStream mode. This caused the problem. When we disabled NStream on the one unit (so neither unit is running NStream) the performance went back to normal.

I always used to have a picture in mind of N-streme being a TDM based technology where it is only an equal wireless throughput opportunity and not equal time division. Rather say dynamic packet division multiplexing.

With the longer distance, obviously we will have more packet loss. N-stream seems to alter the frame(packet) size and not the number of packets! Correct me if I am wrong.
In other words, given all clients have the same levels of packet loss, Nstreme should distribute the AP capable bandwidth equally.
But given clients do not have the same levels of packet loss, then Nstreme doesn't really help! Don't see how setting the frame size to dynamic should help, as when a packet is lost, it is lost no matter what the size is, and retransmission is required as per the ack/nack.

What we need is a number of packets to CCQ system where we can dedicate more transmissions to clients with lower CCQ, and more receiving time for clients with lower CCQ. Or dynamic frame(packet) size with smaller for close clients and larger for further clients. This is based on the theory that if the packet is received properly by the client with the weaker CCQ, then at least that client will receive a big chunk compared to the closer clients. Unfortunately to raise the frame size, in other words lowerring the fragmentation threshold, to clients with weaker CCQ, in practice, has thresholds and usually yeilds worse results.

One question, what if a CPE replies with a nack and not an ack, does N-streme force a retransmission immediately, or does it move on to another CPE and retransmit to the first one when the first one's turn arrives in the Poll? I believe, a real proper polling protocol should be based not on the wireless ack, but a confirmed unit internal network ethernet ack on both sides of the AP and the client. Then everyone will get the exact same throughput. Yet, such a setup would cause a whole AP-client network to slow down because of one bad link. In this case, a better practice would be to set up separate APs based on different CCQ intervals which in most cases is directly related to distances - we are in the LOS domain and not NLOS. However, by doing the latter, we can still stick to Nstreme with frame(packet) throughput based polling!

As a result, it must be best to say setup different APs for different intervals of CCQ. In common practice, don't mix near clients with far clients. It is logic that a near client, unless affected by interference which can cause even worse packet loss- lower CCQ- than distance, will get better throughput than a far client.

It is all about calculations, statistics and analysis. One good practice would be, once we have two APs, one for near and one for far cleints, is to connect the near clients with bad CCQ - interference, obstacle, NLOS - to the AP with the far clients.

In other words, keep the clients grouped based on CCQ intervals and not distance or anything else. If one client is lagging in CCQ, try to enhance his/her link -many ways to do that, or simply shift them to the AP intended for distant clients. Then everyone on the same AP must get the same throughput either through Nstreme Polling or disabling CSMA-CD.

Another idea popped in mind, does Nstreme distinguish between AP and Virtual AP? If yes, then we can set virtual APs for clients with different CCQ intervals! More hardware efficiency.

Anyone's input on this is highly appreciated - Including MT!

Please comment on the post instead of deleting!

GWISA,

red your post with interest. Did you get any more info on this subject. I see no more post after your last one (june 19th 2007)?? I really would like to know more about the subject.

I´m actually wondering myself, should I use nstream or not (not talking nstream2)

I have several AP´s with each 2 to 25 clients in a all MT 5Ghz network in an urban area with relative short distances (>600mts). The whole network is routed and signals are very good with degreased radio outputs. Sns are better then -100. Connectivety is good to very good. I´ve got nstream and polling enabled
Some of the AP´s were located also to reach far clients (1 - 10 km) in the near future. After reading your comment I migth re-think my setup.

And although the ROS manual is very positive about nstream I pick lots of comments on nstream. My question (and probably lots of mediate skilled MT users) is do we use nstream or do we leave it? Reading the ROS manual and comments on this forum still doesn't distill me a clear answer.

And is polling working even when nstream is not enabled?
And how important is the type of framer policy? The network is used a lot by users of Skype and other similar VOIP software.
Recently we found the whole network suffers from regular traffic drops. Could it have someting to do with the framing policy?

Lost of questions, I know.....

rgds