V3 nightmare

[Skaught]

We have been fighting with a link on V2 with PCs for some time. Our main feed no less.

We had 5% packet loss and as many as 8 system lockups a day regardless of hardware (we tried several differnet PCs with different chipsets)

So I was told that using wireless cards in a pc under star-os was a bad plan. A WRAP is not even remotely powerfull enough to handle the traffic, a PC was powerfull enough but far to unstable.

So we tried V3/WAR. For the first 2 hours it looked pretty good. It now alternates between 20 minutes of 108mbit, great speed, low latency, then an hour of absolute crap, slow speeds (it goes down to 12mbit despite a signal of -60something).

We have tried every channel we can imagine all with the same result.

This is VX all over again. I am really very choked as this has been just a continuation of issues we have been having for some time. I get told I am doing things all wrong and that I should have read some obscure thread hidden someplace on this board that warned me that the way I am doing things is flawed.

I specifically asked if there would be a problem with my config and followed the reccomendations to the letter and it is still not working correctly.

I am very upset as I cannot get V2 to work as advertised and WAR is proving to be super unstable.

I am loyal to a product and it only seems to equate to being backed into a corner. I have far to many clients to be messing with beta or unstable products. This product is not free and the attitude that prevails of it being some sort of freeware/public release product is really wearing thin.

My last email to Lonnie has gone ignored so maybe there are others who can share their experiences. I had tried to deal with it privately.

I feel am being perfectly polite and reasonable but I cannot operate this way.

[go.fast]

I feel for you Skaught. Sounds like a serious problem that would make me lose sleep.

But you have to give more details to the board to get some help.
Can you give us the complete details of what you've got up there, what frequencies your using how many ap's distance etc etc etc .

I've had pc's with cards in them, wrap boards, and now war boards and I don't have any ongoing issues. Maybe a box that has to get rebooted now and then.

Give us the details and lets see what we can do to help.

George

[Skaught]

The link will run at 54mbit in non-turbo mode but the second I put any traffic on it, it drops to 6mbit and I get dial-up speed. It will not jump back up to 54 unless I reboot or activate changes.

Turbo mode will not associate at any channels below 5.5ghz. Non-turbo mode associates no problem.

I tried hard coding the speed to 54 mbit at -60 and it seems a bit better so far but I am only getting 2000KB/s and I need more speed than that to support our Ethenet 100mbit Internet feed.

I really am wondering if anyone else is loading up their WAR this much. We transfer well over a TB a day.

I would spread the load over several links but OSPF was collosally unstable and make things much worse.

I am really at a loss here.

[Skaught]

I am not sure what to say, they are 2 WARs with the latest firmware on 32 dbi antennas over about 4 miles. CM9 cards. Perfect LOS. 18v power supplies, both runs about 100 feet.

I am trying my very best to do this the VNC way. it is totally routed, nothing strange that I can think of.

Before I ran out of WRAP processor power, the wraps ran great on this link and really nothing has changed aside from our customer base growth and need for more bandwidth.

[Skaught]

Matt here in our office thinks it is possibly an issue with packet queues. If the queues get full it is supposed to open more queues not drop the data rate?

So far it has been good for halk an hour hard coded to 54mbit. But 5.3ghz in turbo mode still does not work at all. I have it in 5.3 right now in non-turbo.

Since I hard coded it, it has not dropped a ping. But then we are also as far from peak traffic time as is possible.

[tog]

I guess I have to start by saying I've got enough WARs running v3 deployed that I know it's pretty sturdy and I have done 4000+ packets per second and 10+ mbit consistently. The little bit that I messed with StarVx, it was terrible, it crashed a lot. StarV3 is definitely not StarVx, StarV3 is more sturdy than StarOS v2 and has been generally better in every way since the bugs in v3 have been worked out and the beta tag was removed. StarV3 v1.0.0 build 1090 has been nice and solid.

Ok, concentrating on your problem's specifics, I'm going to start asking some seemingly random questions about your setup to feed my various theories as I form them:

You are running a point to point link (one AP, one client) with StarV3 build 1090 on both sides?

It sounds like you have too much traffic for a non-turbo link so you really need to get turbo running. First turbo-related question, did you set the distance really high? In v2 when you enable turbo, you have to set your distance to actual x2. I do not actually know if this still holds true for v3, would have to ask tony.

What's the frequency center on your dishes? Are they 5.3 dishes or 5.4 - 5.7 or 5.8 dishes? When running non-turbo and you are able to use any frequency you want, I assume your signal strength is still near enough to perfect at any frequency even when you're far away from the tuned frequency center of your antennas. Even with some -80 crap signal I can still at least associate when using turbo.

The first question about your distance setting would be my first best guess, turbo should associate just as easily as non-turbo from my experience.

[Skaught]

You are running a point to point link (one AP, one client) with StarV3 build 1090 on both sides?

Yes

It sounds like you have too much traffic for a non-turbo link so you really need to get turbo running. First turbo-related question, did you set the distance really high? In v2 when you enable turbo, you have to set your distance to actual x2. I do not actually know if this still holds true for v3, would have to ask tony.

We set it to ~18miles It won't let me set it any further. 54mbit may work. I will have to see. I know on the PCs I had to use turbo.

What's the frequency center on your dishes? Are they 5.3 dishes or 5.4 - 5.7 or 5.8 dishes? When running non-turbo and you are able to use any frequency you want, I assume your signal strength is still near enough to perfect at any frequency even when you're far away from the tuned frequency center of your antennas. Even with some -80 crap signal I can still at least associate when using turbo.

The dishes are officially good for 5.8 only but I actually get stronger signal lower down. 5.3 is 3dbi stronger than 5.8. And I am not allowed to use 5.7 or 5.8 at one end as it is a co-lo on a rooftop with another Wireless Carrier and they are using it extensively.

The first question about your distance setting would be my first best guess, turbo should associate just as easily as non-turbo from my experience.


I have been a few hours now with not a single dropped ping while hard coded to 54mbit. But it is also nearly 3AM.

[tog]

If the max distance you can set for turbo mode is 18 miles that sounds like tony put the calculation in the GUI and you do not need to set distance x2 like in StarOS v2.

I have not yet tried any long turbo links with v3, I am running a turbo AP on v3 for myself and my associate but we both happen to be within a few blocks of the AP.

[greg]

I don't run any links turbo so I can't assist much in that vein. You might consider putting in the U1 codes and try a frequency like 5700 (at least to test). I dunno what the status in Canada for that frequency. I've found that when using a 32db dish on either end they do NOT perform well outside of 5.8. Mine are Pacwireless and 3-4 years old. They were in place when I bought the business and I've only bought the 26db grids since. The 26db ones work well in any frequency from 5.2 to 5.8 and I've got a pair on a 14 mile link that work flawlessly at that distance. I've got several 3-4 mile links using them that link at 54 and never bounce, reboot or even flinch. My entire bb is now configured using Warboards. I don't ask that they do anything but pass data. No CBQ, NAT or FW in any of the bb connections. My ping time from end to end is 10ms avg and even the gamers are onboard.

PC's drove me nuts, I miss the HP but have found ways around that. I don't miss the 2 am lockups, engineering remote reboot devices or the random trips during the day to reset one. I still have a couple at AP's to fw and cbq but not many. Most of the survivors are in climate controlled areas, they don't last too long in small boxes exposed to the temperature variations. I had one die yesterday that performed my CBQ scripts for most of the system. It was in my server room and pampered beyond belief.

Anyway, I'd suggest you test a frequency closer to 5.8 or try a different antenna if you absolutely must stay down in the 5.3 range. What about cloaking in the 5.7? Supposedly that won't interfere with other channels, might be worth investigating.

[lonnie]

I did not get your email. This is Sunday and I have things planned, but if you see this and get me your IP and password I'll login and see what is going on.

If you have a solid signal you can always hard code the rate. Anytime the rate fluctuates it means you are getting interference or signal loss. You are aware that Turbo requires the two channels to be clear to work. I have advised it is tough to accomplish outdoors, especially since you have no assurance that they will remain clear even if they are today.

So we tried V3/WAR. For the first 2 hours it looked pretty good. It now alternates between 20 minutes of 108mbit, great speed, low latency, then an hour of absolute crap, slow speeds (it goes down to 12mbit despite a signal of -60something).

We have tried every channel we can imagine all with the same result.

My last email to Lonnie has gone ignored so maybe there are others who can share their experiences. I had tried to deal with it privately.

I feel am being perfectly polite and reasonable but I cannot operate this way.

[lonnie]

Is this 4 miles or 14 miles? 4 miles with 32 dB dishes will provide better than -50 dB and 14 miles it matches my RadioMobile perfectly.

I am not sure what to say, they are 2 WARs with the latest firmware on 32 dbi antennas over about 4 miles. CM9 cards. Perfect LOS. 18v power supplies, both runs about 100 feet.

I am trying my very best to do this the VNC way. it is totally routed, nothing strange that I can think of.

Before I ran out of WRAP processor power, the wraps ran great on this link and really nothing has changed aside from our customer base growth and need for more bandwidth.

[go.fast]

I had a strange issue pop up friday that caused a huge slowdown on my busiest war 5 gig ap.
The 5 gig ap has mostly all micro pops connected to it. On one of my micro pops I have a a 2nd board there, a wrap with an agere card in it, connected to the ethernet of a war which is the radio talking to the main war AP.
Most of the time I see speeds of between 8 and 12 megs and often I will see 18 megs and even 20 megs. This is using my http://gw-wireless.oregonfast.net/ speed test that I have for my subs to check their speeds.

Anyways, we were running along just fine and all of a sudden we started getting subs calling saying the service was going extermely slow or not at all.
Sure enough connected to a micro pop that is connected to that ap I could barely get 256k to show up on that speed test. Looking in that AP I seen almost all 6 meg R TX rates. 20 connections on that AP that almost always say 54 megs now almost all say 6 megs.
I was knocked for a loop, On that AP I have almost all 54 meg data rates with very high quality. I was thinking maybe there was an interference issue, could someone be turning up a 5.3 ap in my area that was causing this?

Digging deeper, we found a lot of traffic passing across one link going to that AP. Digging into that link we traced it back to the wrap with the agere card. Looking in that board, there was one sub who must have been running some kind of p2p program, it had like 20 or more connections and the upload was like 2 megs or so.

CBQing that sub on the wrap with the agere and rebooting that wrap brought our network back to normal.

I was blown away that one sub can do this and that this one issue can take down my war ap servicing almost half my network. I have delt with p2p in the past, but have never seen this extreme degeneration. I generally don't have to get into bandwidth shaping, except in situations like this. Makes me want to rethink my stratergy.

I wonder if this is not the same issue your dealing with. You did say you had a drop to 6meg rate with high quality.

George

[tog]

I have certainly seen an issue with my transmit rate from station to AP going down to minimum speed (6) on PtMP APs (even when it's only two associated stations) when one of the other stations uploads.

For example if you have an 11a backhaul AP with only two stations, one station is uploading some and it's humming along at normal speeds, but the second associated station is now performing poorly and is auto-shifting down to 6 and generally sucking in both upload and download performance. I have not done extensive controlled testing but it seems I had a v2 station that uploaded insane amounts (5 - 10mbit, 2000 - 4000pps) and all was fine, but I have some v3 stations that cause this problem. To further clarify, v3 as an AP has been fine and dandy with v2 clients, it's v3 as a station that I'm pointing to for some possible strange behavior.

So, yeah, I can confirm that I've seen this problem you speak of.

You could brush it off and say it's CSMA/CA and hidden node but the problem seems far more severe when it's a v3 station doing the uploading compared to a v2 station. As evidenced above with 4000 pps doing fine sustained for many hours at a time, I never really had this problem with v2.
http://aqua.comptek.ru/test/HiddenNode/hidden_node_en.html
(Keep in mind it is not actually nearly as severe as this demonstration when operating at 12mbit or higher OFDM data rates)

That all being said and hidden node being mentioned, the only _unexpected_ problem I have seen in v3 is this behavior occurring seemingly long before it should, that's the important point here. For example, I have caused this behavior with poor performance for one station while using only an estimated 20% total radio capacity uploading from the other station.

Again, I have not done extensive controlled testing, but it seems like there might be an actual problem with v3 stations that are transmitting that I haven't seen with v2 stations that are transmitting.

I seem to be out of WRAPs for v2 testing and making comparisons regarding this problem, I have only WARs now.

[Skaught]

I can reproduce the fallback issue no problem at any frequency I try. Hardcoding it solves it. noise is -95 or better. Hardcoding is a fix for now but once I start deploying this in more places I will need a better fallback mechanism to deal wtih fade etc.

I have a PAC 3 foot at one end and a Gabriel ~31 dbi flat panel at the other. I will be installing PAC 3 foot later as the gabriel is a loaner.

I asked my mapping software, it is 8.07 miles / 12.99 km

I get the best signal at 5.3 of -61. 5.7 is about -65. Turbo mode will not link at 5.3 at all.

54mbit seems to be holding for now. I Can wait until a new release comes out.

I will email the login to lonnie so he can see it too.

[tog]

Can you clarify, does this AP have more than one station or is it just 1 AP to 1 station?

I haven't had a problem with 1 AP to 1 station, I have only had a problem with one v3 station uploading causing this grief for the other associated station(s).

[lonnie]

He is doing a point to point using AP to Client. I have seen it peak at the AP side with 3,495 rx and 900 tx at the same time. That means it is pushing over 40 mbps peak. I have seen it average over 1,200 rx and 800 tx, so you have about 20 mbps typically flowing. This is in non Turbo.

We'll have to investigate the Turbo channels because it would not link in the 5.3 area and I had to set it up to the 5.7 area to get it linked and then turn off Turbo so it would link at 5320.

Are you getting complaints of slow, or is it handling what your users are pushing?

I just lost my link. Did you change anything on the unit I was chained through?

[Skaught]

I was in the midst of a routing change. I am done now.

I saw the changes you made but I had to put it back on 54mbit. If I did a big download over it the speed would drop to 12 mbit and I would get dial up speed and massive packet loss on my pings over it. I can kill it reproducably by running a speed test over it. Even if it is not to or from the units themselves. Just running a speed test spanning the link casues the issue.

If it is hard coded to 54 mbit it is rock solid.

I am not getitng much in the way of complaints as I told my clients we are working on it this weekend. But here at the office we sure notice it when it goes to pot.

It seems if the traffic stays under about 40mbit all is happy but as soon as I push it past that, the auto rate selection takes it down to 6 or 12 mbit.

I am a bit clamer now though as at least I have a solution that seems to be working for now. 54mbit seems to be fast enough so far for our traffic for now. I have 4 internal backhauls to upgrade to WAR as the WRAPS are getting tanked out. Once those are upgraded I will be seeing more traffic I bet. I however will wait for more testing before I switch any more links.

[sligbot]

Just to add to this thread, we just upgraded our PTP to 5GHz and tried turbo as well. We've got a routed network just FYI. We found that in standard mode (ie 22MHz) we were getting similar results as you found (40mbps). However, when we switched to turbo and did a speedtest, we were getting dial-up speeds. The internal StarOS TCP speedtest said we were getting great speeds but verification with various speedtests and just plain browsing on the internet did not support that. We don't need it so we're ok with the fact we can only run things in standard mode, but we are working to test some triple play equipment in our network which would need it (by the way there is no RF competition in the area so it's great for testing).
Rich

[lonnie]

I always recommend manual settings if there are any issues with the automatic. Auto rate takes a lot of factors into account and it does take some precious time, so you should set the speed to 1 notch below what it normals peaks at. With signal levels in the -60 dB range, and better, you can leave it set to the highest.

We are testing a new display that changes the value displayed by quality. Right now it is simply noise value - signal value. The new method takes into account signal, noise and hardware retries. It will make it easier to find the proper value and also to find clear channels.

[tog]

Ok, we've got two separate problems we're talking about.
So far regarding turbo we've got:
Turbo is working normally for me, but it's only about a thousand foot distance.

Skaught is unable to link up (4 miles) using turbo at 5.5GHz or below for some odd reason, not entirely clear but it sounds like turbo wasn't performing too well when he did get it linked up.

sligbot has a PtP link (unknown distance, unknown frequency) working fantastic with non-turbo and he can establish a link when he switches to turbo, but it performs extremely poorly.

Regarding the v3 station transmitting problem:
On the 11a AP I'm running in turbo as a test I just switched it and its two stations out of turbo and back to normal, then uploaded from one station. I reproduced the same problem so it had nothing to do with turbo. The second associated station performed extremely poorly in either direction while the first station uploaded. Second associated station's transmit rate instantly trained down and stayed at lowest rate, first busy station's transmit rate was staying trained around normal transmit rates.
Forcing both the stations' transmit rates to something like 36 helped, but I still get a couple packets dropped here and there on station 2 when uploading from station 1, around 0.5% - 1% packet loss using turbo.
When not using turbo, when station 1 uploads at about 1500K/sec, station 2 starts dropping 30% packets.
Also should mention the frequency I'm using is definitely 100% clear.

[tony]

Lonnie is correct. Instead of the raw signal dbm for quality, it is now a % (100% being the best) of the current rate, based on PER, amongst other things to give you a good idea as to the channel clarity. The noise is also valid in the next release, instead of being hard-coded at -95.

[tog]

That will be extremely useful information, very nice!

[Skaught]

I think I will need Turbo mode sooner rather than later:

16089.0 kbits/sec

Once I go over about 15000 kbits/s latency jumps signifigantly and VOIP and gaming drop off.

[lonnie]

How did you determine that number? When I was on your system I noted a continual 20 to 30 mbps of traffic.

I think I will need Turbo mode sooner rather than later:

16089.0 kbits/sec

Once I go over about 15000 kbits/s latency jumps signifigantly and VOIP and gaming drop off.

[Skaught]

Just watching ping plotter on one screen and the traffic on my core router on the other.

I plan to try turbo at 5660 tonight after hours.

Allthough I was trying to find the Candian rules for that band online with no luck so far.

[Skaught]

Turbo mode is definitely messed.

I set the channel to 5660 and hard coded the speed to 108. It linked at 108 for a second but immediately fell to 12 mbit (despite being hard coded).

I also tried auto and it went to 12 mbit too.

If you could release a fix to allow hard coding of rate in turbo mode it may tide me over.

It is rather high priority, I have had latency above 100ms all night so far. Killing VOIP in the process.

[tog]

The rates in turbo under v3 need to be 6, 9, 12, 18, 24, 36, 48 or 54. Don't specify 72, 96 or 108. When you specify 36 you will get 72 and so on.

This is different from v2 where you actually needed to specify 72, 96 and 108.

[sligbot]

Just to clarify, I've done exactly the same thing as Skaught has. Locked the device to a fixed rate (6, 12, 24, 48) in Turbo and standard and had the exact same results. Distance is 2 km and we're using 2 Superpass 21dBi panels. I've also set the value to 4 miles in StarOS. We're also using the latest release of the software (v1.0.0.0 (build 1090)) on each board (1 x 4 port and 1 x 2 port WAR). I've taken things off of Turbo and there is the stability and speeds that one would expect with standard bu with Turbo, I'm luck to get over 500kbps on a
-72 signal (I know it's not as high as we'd like it to be but it's what works for testing).
Rich

[lonnie]

-72 dB is not enough for Turbo. You need better than that to even do 54 mbps and for Turbo you need even more than for 54 mbps. For Turbo I would not even expect decent results unless I had better than -60 dB signals.

This is made even harder because the tx output is dropping to 13 dB at 54 mbps and they do not even spec Turbo, but I would guess it is 10 dB or less.

So to sum up, if you are using Turbo the following things work against you as compared to Standard mode. TX power is reduced. RX signal must be increased. You are using TWO channels of RF bandwidth and they BOTH must be CLEAR. It all adds up to some very large antennas and potential trouble later if someone comes too close to the channel with another system.


Just to clarify, I've done exactly the same thing as Skaught has. Locked the device to a fixed rate (6, 12, 24, 48) in Turbo and standard and had the exact same results. Distance is 2 km and we're using 2 Superpass 21dBi panels. I've also set the value to 4 miles in StarOS. We're also using the latest release of the software (v1.0.0.0 (build 1090)) on each board (1 x 4 port and 1 x 2 port WAR). I've taken things off of Turbo and there is the stability and speeds that one would expect with standard bu with Turbo, I'm luck to get over 500kbps on a
-72 signal (I know it's not as high as we'd like it to be but it's what works for testing).
Rich

[Skaught]

108 mbit worked fine on V2 even on auto on this link with a weaker signal on my old antennas.

-60 at 54 mbit on non-turbo should be able to sustain some thing better than 12mbit on turbo. I did it last week on the same path on V2.

I will be putting in SR5 cards but I need to see the software work on CM9s before I move on to something else.

There is definitely a problem if I hard code the link and it runs at auto anyway. It should just not pass data if there is not enough signal, falling back would be a bug and it needs to be fixed asap. This is a production system and the software is now out of beta.

Yesterday was our first weekday on V3 and it was another disaster. I desperately need a fix for this. Fixing the rate select is the first step.

I am not asking for advanced features, just the basic ones to work.

[tony]

Please check out the latest 1.0.1 release and let me know if it helps.

[tony]

For those using '##' country code with turbo; there was a problem found that prevents the client from scanning all available turbo-enabled channels, meaning only a handful of them would work. The upcoming v1.0.2 release corrects this, and will have all the channels available for use in turbo mode.

[lonnie]

Rates are set based on normal mode rates. We do not yet have the dialog doing scaling so enter the rate at half of desired, so 108 would use 54. I suggest trying it at 36 or 48 first to see how well it performs and step it up as you are comfortable with the signal levels.

108 mbit worked fine on V2 even on auto on this link with a weaker signal on my old antennas.

-60 at 54 mbit on non-turbo should be able to sustain some thing better than 12mbit on turbo. I did it last week on the same path on V2.

I will be putting in SR5 cards but I need to see the software work on CM9s before I move on to something else.

There is definitely a problem if I hard code the link and it runs at auto anyway. It should just not pass data if there is not enough signal, falling back would be a bug and it needs to be fixed asap. This is a production system and the software is now out of beta.

Yesterday was our first weekday on V3 and it was another disaster. I desperately need a fix for this. Fixing the rate select is the first step.

I am not asking for advanced features, just the basic ones to work.

[nickwhite]

Should the signal levels change whenever you change the hardcoded rate? When I change mine from 18 to 24 or 36, my signal level goes from -54(avg) to -62, -68, etc. This is both in cloaking (2x) and non-cloaking. Could this indicate noise?

[tony]

This is normal, as transmit power is reduced with higher rates.

[tog]

I can attain full 108mbit turbo with full performance at -65, I can do 96mbit at full performance around -65 to -70.

Not that I would bother wasting the spectrum to do so, but I can also use turbo just fine with good performance at -75 to -80, it just gives 12, 24, 36, 48 and 72 mbit data rates.

It's not quite as sensitive as you make it out to be, but I don't think it's worth wasting the spectrum running turbo if you can't get 72mbit or better running at full performance. If you can't get 72 or higher, why bother? Improve your antenna setup first. Even just a marginal improvement (21dBi panel --> 25dBi grid) even just on ONE SIDE can be the difference between being stuck at 18 and flying along at 36 or 72.

I don't think I've tested it with v3, but I remember in v2 when you put something it considered invalid in for the transmit rate it would just use the lowest (6 normal or 12 in turbo) and I would expect v3 either does the same or just uses auto.

[Skaught]

Setting the speed to 54mbit gave as a very solid 108! Works great!

Thanks!

We are now running 26000kbit/s according to iptraf (which I think reads below the actual)

[Skaught]

It is running rock solid now all evening. I do not think I dropped a single ping.

. . . so now when I run out of bandwidth on this link, can I add an extra card to each WAR and run some sort of load balancing or use one link for up and the other for down?

I am just joking. I think I will be good for a few months at least on this. (I hope)

[lonnie]

I am pleased that you got it working and I hope it keeps working so well. What is the CPU load when you reach maximum?

[tog]

It is running rock solid now all evening. I do not think I dropped a single ping.

. . . so now when I run out of bandwidth on this link, can I add an extra card to each WAR and run some sort of load balancing or use one link for up and the other for down?

I am just joking. I think I will be good for a few months at least on this. (I hope)

Sure you can :)

Just use static routing to send your traffic in one direction over one link and traffic in the other direction over the other link. Nothing fancy, no voodoo. It wont give you 80mbit downloads, but it'll give you a full-duplex connection.

Although, this is more difficult if you're using a dynamic routing protocol. I setup a lab last weekend and found that you cannot convince OLSR to do asymmetric routing, but aside from that it's quite nice and I'm about to start using it.

[budi]

It is running rock solid now all evening. I do not think I dropped a single ping.

. . . so now when I run out of bandwidth on this link, can I add an extra card to each WAR and run some sort of load balancing or use one link for up and the other for down?

I am just joking. I think I will be good for a few months at least on this. (I hope)

Skaught, How many mbps you could got (maximum) in your turbo's
link ?

Thx
//Budi

[Skaught]

It is hard coded to 108mbit and I am getting at least 40mbit of throughput.

At this moment I am doing 1500 to 2000 KBytes/s But it is not peak time yet for the day.

I have not dropped a single ping on that link in 48 hours.

There is no doubt there are still bugs in ther code though. Auto rate selection does not work at all for me.

Allthough I have not tried the latest version. I have a stable link right now and I am not going to fark with it.

[Skaught]

Sure you can :)

Just use static routing to send your traffic in one direction over one link and traffic in the other direction over the other link. Nothing fancy, no voodoo. It wont give you 80mbit downloads, but it'll give you a full-duplex connection.

Although, this is more difficult if you're using a dynamic routing protocol. I setup a lab last weekend and found that you cannot convince OLSR to do asymmetric routing, but aside from that it's quite nice and I'm about to start using it.

Ya, I have used that trick before. And we may be using it in the coming months unless some sort of load balancing features come out.

I am not sure how to integrate OSLR with BGP for load balanced gateways as there is no way to redestribute the routes between the two protocols as they run on separate v2 and v3.

The CPU looks the same on an idle WAR as it does on a war doing 40mbit near as I can tell. Quite impressive. But then I am not using connection tracking yet.

[lonnie]

So, do we have your seal of approval? Your thumbs up?

[Skaught]

The platform looks like it has a great deal of promise. The hardware is awesome. I think the software is definitely still a work in progress. But it is working exceptionally for us right now if I work around the caveats.

If I am going to use this in a multipoint environment I want to see auto rate select work first.

full starutil needs to be fixed/added too.

I am wondering if this could replace my PC based core router for routing and L7 shaping at some point down the road.

[tony]

Starutil support will be replaced in the near future with a new, more flexible and secure mechanism.

[go.fast]

If I am going to use this in a multipoint environment I want to see auto rate select work first.



All my links are set to auto and most all are PtMP

George

[lonnie]

I have always said to use manual settings if auto does not work as expected. When you KNOW you have enough signal for 54 mbps then simply set it to 54 mbps.

Automatic is great for establishing your link but I ALWAYS set the rate manually based on what I can reliably achieve.

The platform looks like it has a great deal of promise. The hardware is awesome. I think the software is definitely still a work in progress. But it is working exceptionally for us right now if I work around the caveats.

If I am going to use this in a multipoint environment I want to see auto rate select work first.

full starutil needs to be fixed/added too.

I am wondering if this could replace my PC based core router for routing and L7 shaping at some point down the road.

[tog]

To be honest with you I think if you want to do L7 shaping and firewalling you're better off with a heavy-duty CISC processor like an x86 PC.

If you want to sling lots of packets around without stopping to open up and inspect each one RISC/ARM is your man for the job.

I keep it as simple as I can up on the towers and do my fancy tricks on the boxes with 3GHz CPUs and the like.

You cannot directly integrate OLSR as your complete IGP with zebra/quagga's daemons. olsrd needs to be taught to speak "zclient" protocol before it'll play nice with zebra/quagga. The routes added to the kernel directly by olsrd are marked as inactive by zebra/quagga.

You can run your eBGP on your border router and then have a static route(s) back to another router running olsrd. That "another router" could be a WAR up on your tower or a Linux or FreeBSD PC running olsrd.

My little OLSR test lab included FreeBSD inside vmware and olsrd worked great so I intend to use it on my FreeBSD core router to talk directly to the two WAR4s on the tower.

Imagine a narrow land mass 120 miles long. The backbone goes northbound or southbound. :)

The next major southbound hop is about to have two WAR4s each connected back to my main site and connected to each other via crossover cable. Then I'll have two WAR4s at main site (only one right now) and each WAR4 will handle one of the two backbone links from the southern site. Bam, full redundancy!

[Skaught]

I have always said to use manual settings if auto does not work as expected. When you KNOW you have enough signal for 54 mbps then simply set it to 54 mbps.

Automatic is great for establishing your link but I ALWAYS set the rate manually based on what I can reliably achieve.

I agree on a ptp link with 10db of fade margin.

When we start doing multipoint we will be dealing much more with things like weather fade. I will also need to milk out every last mb I can on the lowest of signals. So if I do the install on a sunny day and they will support 18mbit, then we get a snowstorm, I have to manually change the rate on potenitally thousands of cpes in a 5 minite period to adapt to the fact they may only support 6mbit now. All while many of them may not be linking due to low signal.

Also I need some clients to be at 54 mbit while a residential client 30km away is perfectly fine on 12mbit. This is kinda the point of multipoint.

What would I set the AP to? It has to be on auto since many clients will have differing siganal levels and it will have to adapt. So auto just has to work if I am going to be using Star-os on thousands of CPEs.

Is it so much to ask for a feature to work as expected and advertised?

[tog]

Regarding auto-rate, have you checked out build 1115? Here are the release notes:
Change log for star-v3 v1.0.1 build 1115
May 29, 2006
...
*) atheros transmit retry is now more aggressive
...

I have not yet tested auto-rate with build 1115's tweaks in the one situation where I was having trouble with it. Auto-rate worked pretty much as expected in v2, I'm sure tony can make it work just as well in v3 if not better. A relatively recent trend for wireless driver developers has been to use improved auto-rate algorithms. I'll bet tony is doing the same. When using the FreeBSD ath driver I very much like ath_sample, it works fantastic compared to the rest.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ath/ath_rate/sample/

[lonnie]

Before I get into this -> where was it ever advertised that auto was PERFECT? I do realize you can EXPECT it to be perfect, but as in many things in life, prepare to be disappointed.

Auto takes into account many, many things and it does try to maintain the highest rate that it can reliably achieve. If it slows down it is because it is being messed up by "something TM" and it has tried to do the best it could.

I have been watching a lot of our AP units lately and it sure looks like the AP does a fine job of rate selection and typically uses a high rate. The client rate jumps around and typically uses lower settings, but since the same rate control is used by the client it has to mean the client sees something the AP does not and adjusts the rate downward.


I agree on a ptp link with 10db of fade margin.

When we start doing multipoint we will be dealing much more with things like weather fade. I will also need to milk out every last mb I can on the lowest of signals. So if I do the install on a sunny day and they will support 18mbit, then we get a snowstorm, I have to manually change the rate on potenitally thousands of cpes in a 5 minite period to adapt to the fact they may only support 6mbit now. All while many of them may not be linking due to low signal.

Also I need some clients to be at 54 mbit while a residential client 30km away is perfectly fine on 12mbit. This is kinda the point of multipoint.

What would I set the AP to? It has to be on auto since many clients will have differing siganal levels and it will have to adapt. So auto just has to work if I am going to be using Star-os on thousands of CPEs.

Is it so much to ask for a feature to work as expected and advertised?

[tog]

I have been watching a lot of our AP units lately and it sure looks like the AP does a fine job of rate selection and typically uses a high rate. The client rate jumps around and typically uses lower settings, but since the same rate control is used by the client it has to mean the client sees something the AP does not and adjusts the rate downward.

Auto-rate works pretty well at the AP side at the moment, not as well on the client/station side.

[Skaught]

For me it does not work at all. As soon as I start a throughput test on it, it drops to 12mbit on turbo or 6mbit on non-turbo and latency goes well over 400ms. So ya that is not perfect. That would be the exact oppoosite. I am aiming for something a bit higher.

The drop is distinct and reproduceable.

108mbit hard coded is nearly flawless (but not perfect and I can handle that). I had a spike of latency on it this moring for about 20 minutes, may have been airplane based radar as we are next door to an International airport.

The speed drop is also not caused by outside influnences. It runs great for a week hard coded then within 10 seconds of putting it on auto it drops to 6 mbit once my traffic starts ramp back up.

I do not know if any others have encountered the issue as I do not know if they run 20-40mbit sustained over the link 24/7.

[tony]

The algorithm used for auto-rate adjusting is quite sensitive to noise & other forms of interference. We are always improving things, and the next update will hopefully help in this area.

[Skaught]

The ability to choose an algorithm based on one's needs would be awesome. I would just use one based on SNR/signal strength. If I have trouble with noise I can change channels.

It worked fine in V2, so if something was changed, that will be it.