Inconsistent link tests

Please be gentle, I’m a new member. :slight_smile: Sorry for the length of the post, but I’m going to try to describe the situation fully in hopes it will help provide better answers.

First the background on the environment. I’ve just installed a 900MHz system for a private point-to-point link in a rural area. So this is a single AP to a single SM, no CMM involved etc. This distance is 1.34 miles with some foliage (thus the use of 900MHz) though it is not heavily wooded. Each side is on a mast at roughly 50’ and to my knowledge the fresnel zone should be relatively clear except for the foliage. Neither side is close to a satellite dish etc.

The AP came with version 7.0.7 installed, and the SM with version 6.1. Both sides use the integrated antenna with link speeds set to only use 10 Base T Full Duplex, and the SM set to only the frequency in use on the AP (924MHz, which was the optimum based on the spectrum analyzer). The AP has been set to use just one control slot since I’ll have just the one SM registered to it. Transmit power is left at the default of 24 dBm on each side because of the use of the integrated antennas.

RSSI is roughly 1400, jitter is typically 3 with an occassional 4 and a rare 5 seen, and power level hoovers around -72. Downloads efficiency is usually 96-100% and upload is usually 100% when running 2 second tests, then all of a sudden will get very low rates or messages no session is active then return to 96-100%. Sometimes it switches to Idle state and does not become active again for a minute or two.

When running link tests over the 2 second default, the efficiency is often much worse (sometimes below 40%) but sometimes is still 100% even across 10 second tests. It just doesn’t seem consistent.

It currently shows 49 re-reg count across a several hour period though I don’t see the count go up each time I have a low efficiency rate in a link test. (The session count is up to 83.)

Since there is just the one SM, I have the downlink set to 85% in hopes of maximizing throughput but am seeing only around 1700kbps downlink speeds even when the efficiency is 100%. Uplink speeds are about 150kbps at 100% efficiency.

However, those rates don’t seem to carry over to sustained throughput rates. If I try a file download from a broadband speed test site, I’m seeing more like 500kbps instead of 1700kbps. (The speed at the AP side is a solid 6000kbps available.) I suspect this is due to the lower efficiencies I’m seeing in longer link tests, and the re-reg count I’m seeing.

I think I’m still using software scheduling because I have not changed those defaults and the configuration pages show software scheduling. Yet the AP status page at the bottom says hardware scheduling and MP double rate enabled. (Actually, this section which is below the site information only appears on some refreshes of the AP status page. Most of the time the site information is the last section displayed.)

OK, so much for the environment and test restuls. Here are my questions:

1) Isn’t the re-reg count excessive? How often does a “typical” installation session drop and need to reregister? Is there something I can do to try to minimize this?

2) With only a single SM involved, shouldn’t I be able to see higher rates than 1700kbps when link tests show 100% efficiency at a 85% downlink ratio given the fact my RSSI and jitter are within tolerance?

3) What is a “typical” spread between the link test downlink bps rate and the throughput seen on fille downloads? Isn’t my spread of 1700kbps link tests to 500kbps measured throughput abnormal?

4) Why does the AP status page sometimes include a section below the site information with scheduling information but usually not? It doesn’t appear to be related to whether there is a session active.

5) Why would it show hardware scheduling when I have not yet enabled hardware scheduling on the AP and SM configuration pages?

6) On the SM configuration, I’m not seeing an option for 2x enable or disable. Is this because it is at version 6.1? Should I upgrade the firmware on the SM? The AP is at 7.0.7. Should the firmware upgrades be done ahead of trying to enable hardware scheduling?

7) With a single SM at 1.34 miles and a RSSI of 1400 and jitter of 3, should I be able to use 2x hardware scheduling and see significantly better throughput? (Please <g>)

8) Is it possible to access the SM configuration page from the AP side of the link? So far I’ve only been able to use it from the SM side.

Again, sorry for the length but this is my first install and I’m not familiar with what to expect other than by trying to peruse the manuals and these forums.

Any help would be appreciated.

Doug

Before you spend much more time trying to diagnose this, you really need to upgrade both to 7.3.6. You will see a major improvement.

After you upgrade, if you still have trouble, take screen shots of the config screens, post them to a server and link to them here.

Jerry,

Jerry Richardson wrote:
you really need to upgrade both to 7.3.6.


Since the SM is at 6.1, the sequence I need to follow is:

- Upgrade SM to 7.0
- Upgrade AP and SM to 7.2
- Upgrade AP and SM to 7.3.6

Is this correct?

I’ve installed CNUT and configured my AP in the network root, but when I have it try to refresh the network list to find the SM it says there are no SMs registered to the AP. Yet if I visit the AP sessions page, logical unit 002 is active.

How can I force it to add LUID 002 into the list? When I try to add the SM into the network root manually, it seems I must give it an IP address or host name which maps to an IP address. 169.254.1.1 is of course not routeable and it is not found.

Is there a way I can add it using the LUID 002 instead?

Do I have to visit the SM site and assign a routeable address? Or use CNUT from a laptop at the SM site so it can find the SM?

Is there a way to access the SM configuration pages from the AP side of the link? My link tests still show the session as usable, but I can’t figure out how to get the SM detected in CNUT from the AP side.

Any sugestions?

TIA,
Doug

make sure you have the community string the same in cnut as in the module. Also make sure your on the same network although i am not on the same network i vpn into a computer on that network and update that way. of course i use privates not publics that why i have to be on the same network.

kmeadows

you can load 7.3.6 into both directly. no need to step up.

I have not been able to load SM’s via the AP but it can be done.

you need to put an IP in the SM in order to update it. you can get to it through the LUID select page, just click view current subscriber.

Jerry,

Jerry Richardson wrote:
you can load 7.3.6 into both directly. no need to step up.


That isn’t what the release notes say. So are you sure about this?

Jerry Richardson wrote:
you can get to it through the LUID select page, just click view current subscriber.


Ahh, that’s what I was missing. Many thanks.

My community string is still the default “Canopy” in both the AP and SM. Can you think of a reason CNUT would not find the SM which is registered and active on the AP?

I guess I can schedule a time with them to return and try to update directly from behind the SM using my laptop.

Doug

I have updated from as far back as 4.x to 7.3.6 with no issues. Maybe I got lucky…?

I don;t know why you are not able to get to the SM through the AP.

What is your network topology?

Jerry,

Jerry Richardson wrote:
I have updated from as far back as 4.x to 7.3.6 with no issues. Maybe I got lucky…?


I had no experience with the updates on these, but the release notes said not to do that. At any rate, I have both the AP and SM updated to 7.3.6 now. I think my problem with CNUT not seeing the SM was some type of personal firewall issue or something, because when I put CNUT on another computer on my LAN, it detected it right away. Since I only own one AP and one SM and they are both now at 7.3.6, I won’t worry about it again until v8 is released.

So now I’m on 7.3.6 with hardware scheduling enabled, DES disabled, transmit frame spreading disabled, and 2X enabled.

Ping times are down to 9-13ms instead of 32ms previously and link tests are just over 2000k bps down and nearly 400k bps up when the efficiency is high.

I could live with that except for one major, show stopping problem. Now the SM freezes up (evidently) after just a little bit of traffic. Even running a couple of 2 second link tests seems to be enough to make the session stop. It doesn’t seem to resume until I have the power cycled on the SM end to force a reboot and registration again.

So at this stage I’m in essence worse off for now as I can’t do much of anything including changing much SM config data without it stopping and my needing to call and have them cycle the power.

I also tried disabling 2x mode with the same results.

When it quits, the AP shows the SM as simply IDLE, not scanning or registering. I was going to try cycling the power then not do anything to cause traffic and see if stayed up all night. But it didn’t; the session still dropped. However, after several minutes of being IDLE it did register again without a power cycle.

So maybe the power cycle was never “needed” but only forced the re-registration to begin. I’d now say the session is only staying up for brief periods, then going IDLE for several minutes then coming back up again.

Any ideas???

Jerry Richardson wrote:
What is your network topology?


I’m just trying to bridge two LAN segments in a private point to point link. The LAN on the AP side is 192.168.1.x, with the AP plugged into a switch and configured as 192.168.1.210 in the same subnet. On the SM side, NAT is disabled and I am temporarily using static IPs in the same 192.168.1.x subnet. (Except the SM, which still has the default 169.254.1.1 address but a 192.168.1.1 gateway value.)

Thanks again for your help – but now what can I try to avoid the issue of sessions stopping and not even re-registering right away? Is this suspiciously like the symptoms in the recent “New 900MHz link” thread?

Incidentally, while the RSSI, jitter, and dBm remain about the same as shown on the AP side (which is what I’ve always reported in this thread), now that I learned how to see the SM status page too it shows the RSSI as about 1600 with a -65 dBm signal, while the AP session page shows the same SM with about a 1400 RSSI and -74 dBm. I don’t know if the same was true prior to my software upgrades as I was only looking at the AP session status. Do the values differ because they represent the signal strengths in opposite directions?

Doug

THe values you see logged into the SM is what the SM is receiving from the AP. It is vice versa when looking at the values from the AP side.

Need screen shots of the AP and SM config screens.

Jerry,

Jerry Richardson wrote:
Need screen shots of the AP and SM config screens.


Here is the AP broken down into two segments:





And the SM broken down into two segments:





Thanks again for any suggestions.

Doug

sarnett wrote:
THe values you see logged into the SM is what the SM is receiving from the AP. It is vice versa when looking at the values from the AP side.


Thanks for that clarification. The good news here is that the stronger signal is in the direction with the most traffic though even the SM to AP levels seem within tolerance.

Jitter is the value which seems on the low end of the threshold, at 3-4 average. What are the primary causes of jitter?

Make these changes and tell me what heppens:

1. Increase Max Range to 15 miles
2. Change Downlink Data to 70%
3. Allow all ethernet speeds at both ends

Range effects power. If you set it to 3 miles you are not outputting at the max.

It’s possible that the devices your are connected to will work better at a different link speed.

What about Power up in Aim mode versus Power up in Operational Mode?

Jerry,

I had bumped from 2 to 3 miles since I was now trying 2X signaling, but thought the power output was based more on the 24 dBm level configured.

At any rate, I’ve made the changes requested. So far, every link test attemp (for 2 seconds) has resulted in no test results when refreshing the page and ultimately a message saying no session is active. When I then go to the sessions page, the SM is listed as IDLE.

The good news is it seems to re-register must faster now instead of staying in IDLE for a long time. So then I get to try it all over again, so far always resulting it it going IDLE during the test.

The status pages show both ends are now linked at 100 TX full duplex. I had originally changed that based on some old forum threads I had perused.

Actually, I was just trying one more time before submitting this message, and I got my first 2 second link test to complete:

Stats for LUID: 2 Test Duration: 2 Pkt Length: 1522
Downlink RATE: 737280 bps
Uplink RATE: 147456 bps
Downlink Efficiency: 43 Percent
Max Downlink Index: 100
Actual Downlink Index: 43
Expected Frag Count: 2880
Actual Frag Count: 6614
Uplink Efficiency: 55 Percent
Max Uplink Index: 100
Actual Uplink Index: 55
Expected Frag Count: 576
Actual Frag Count: 1037

I’m open to more suggestions…

TIA,
Doug

set max power to 28db.

msmith has a point, have the SM powerup in operational mode. this way if there is a problem with the ethernet link the radio will still register.

after this, you are going to need more elevatio or more gain. what kind of trees are you trying to penetrate

Jerry,

Jerry Richardson wrote:
set max power to 28db


I’ve changed both sides to 28dBm and got my best link test yet:

Stats for LUID: 2 Test Duration: 2 Pkt Length: 1522
Downlink RATE: 2623488 bps
Uplink RATE: 1027584 bps
Downlink Efficiency: 94 Percent
Uplink Efficiency: 100 Percent

but then another attempt at it went IDLE again. The next successful attempt was:

Downlink RATE: 1818624 bps
Uplink RATE: 1025792 bps
Downlink Efficiency: 97 Percent
Uplink Efficiency: 100 Percent

I’m not sure how 94% yields 2623k and 97% yields 1818k, except that the one test must have had a 2X signaling negotiated and the other had fallen back to 1X or something.

What I don’t understand is why the SM will remain IDLE for a variable amount of time (up to minutes) after a session drops. It never seemed to do that before the software upgrades. The aim vs operational mode doesn’t seem to be it since the 802.3 link was active the whole time I was testing immediately after the software upgrades, and I’ve changed that now too and still see the symptoms.

Jerry Richardson wrote:
after this, you are going to need more elevatio or more gain. what kind of trees are you trying to penetrate


I think it is mostly oaks with some pines. It is all over private land with no road access, so I’m not completely sure what type of trees could be included.

I guess part of what confuses me here is it seems the links actually got much worse after the software updates. I was getting more packet loss than I’d want, but the session would stay registered much longer and would seem to re-register right away if it did drop, where now I can’t seem to stay connected long and then remains IDLE for awhile.

Any chance v8 may improve on the situation when released?

Doug