View Full Version : v3 release initial results
lonnie
02-21-2006, 06:07 AM
I want a new thread with the results that people are finding about the upgrade and the new code. Please let us know how it went and what you are experiencing with reliabilty and throughput.
I am not too interested in reports of missing features, since we already know about that. I do want to know how the provided features work. Is this stable and ready to start building added features upon?
anne1
02-21-2006, 06:56 AM
Have a WAR4 linking to a WRAP, after upgrade if I reboot I see wpci1, wpci2, wpci3 & wpci4 all scanning.
Problem is if I login to the WRAP I can see the WAR has associated to the WRAP 34Qual / -61 Signal and is passing traffic. But the WAR still shows no link on main screen only if I press "F3" I can see the link.
This is only a problem if I select "any" in the SSID on the WAR once I enter the SSID of the WRAP that is the AP the problem goes away.
Hope this helps.
Anne
Thank you for the message.
The 'any' ssid has never been implemented in the WAR as it is designed for windows style systems that roam from system to system. To associate to a system, you will need to enter the correct essid like you have found.
The association you are seeing in the WAR board is actually not an association at all if it has a 'H' in the 'T' (type) column. Each card has one, and represents the host card. The throughput and data counters that it represents are totals from all associated clients. This information should be the same as on StarVX.
anne1
02-21-2006, 08:16 AM
Ok thanks, just another thing, in V3 you don't have all the channels listed for Ireland like you do in V2.
Anne
This is something we can investigate. Did the WAR have all the channels before you upgraded?
Update - Frequencies 5745 - 5825 have been added to V3 for Ireland and other EU countries to match that of V2.
anne1
02-21-2006, 08:46 AM
Yes I think so, but not 100% sure.
I think these are the ones we can use:-
36 - 5180
40 - 5200
44 - 5220
48 - 5240
52 - 5260
56 - 5280
60 - 5300
64 - 5320
100 - 5500
104 - 5520
108 - 5540
112 - 5560
116 - 5580
120 - 5600
124 - 5620
128 - 5640
132 - 5660
136 - 5680
140 - 5700
149 - 5745
153 - 5765
157 - 5785
161 - 5805
165 - 5825
As I said "I think we can use" You better check to be sure.
Anne
nelson05
02-21-2006, 11:31 AM
Add another successful upgrade report to your list.... I upgraded one of our WAR4s last night and everything went very well.
The IP of Ether1 under StarVX was 192.168.250.1 and this did come across after the upgrade though it took a bit of work to get everything talking afterward which is no fault of the upgrade procedure. I had been running the DHCP server service on the WAR and of course had to reset my PC's IP address statically (192.168.250.2) after the upgrade to access the WAR. However, after doing so I was still not able to communicate with the WAR at 192.168.250.1, even after waiting five minutes to be sure everything updated. I was about to give up and power cycle the board as I had read Lonnie's post beforehand, but decided to clear my laptop's ARP table first. Bingo- once I did that, the WAR was accessible with no power cycle required.
Testing beyond this point was rather limited as we use WEP on all parts of our production network. I did place one of the cards in the WAR into station mode and had it associate to an uprotected access point at home (a cheapie Linksys WRT54GS), configured NAT and DNS on the WAR, and let the laptop bang away with FTP transfers, radio streaming, and pings all night. Didn't miss a beat.
I know some people will miss apconfig, but I have to admit that I'm pretty happy to see the good old StarOS SSH interface riding on the WAR. I did notice that the CPU usage jumped around quite a bit compared to what I am used to with StarOS on the WRAP. It was a little surprising to see 100% pop up on several occassions given the WAR's 533mhz processor and the fact that there wasn't any significant traffic or interface navigation. It may be cosmetic since I didn't notice any real lag other than after saving changes by going to the menu option and then going back and applying changes soon after (I know you are prompted to save changes if you activate now...I am not used to that option yet, I guess), I received a message stating the system was already busy processing another request. Going back to the menu a second time and clicking activate changes worked fine and of course I could just select the activate changes option and click save when prompted....I just never ran across the issue under StarOS on the WRAP as it seemed to save immediately and then be ready for more.
Nice to see the system console option. I'd like to vote for the ability to be able to use the up arrow to recall the last command entered. Also, though it may be a configuration issue on my end, I can't seem to get traceroute to work on any address outside of the subnets that the interfaces have their addresses in. I have a default route and know DNS and the Internet are working as pings to www.yahoo.com and other sites succeed. Any ideas? The traceroute just times out with only asterisks on the first hop again and again (even though I can ping it directly). Also, will we be able to specify different parameters for the commands? For example, I tried -n to see if name resolution was the issue, but received a "parameter not recognized" message.
Also, its good to see the serial port interface already in place and since I had to dig for the info in a past post, here is a reminder to set bits per second to 115200.
Finally, in playing around with the wireless options, it appears that B mode might not be working or at least is not working in the way I'd expect. When explicitly setting 802.11b in the operating mode, I still see the associated rate as 'G' speeds under r-tx and r-rx. This is with the WAR in station mode and the transmit rate set to auto. B rates do seem to work when hard coded, at least on r-tx where after I set the transmit rate to 11, r-tx displays this rate (though r-rx still shows G rates).
Sorry for the book, but I wanted to give you everything I had while it was fresh. I realize I'm not doing anything really sophisticated or pushing the unit very hard- I'll upgrade a couple of the WAR2s tonight, though I won't be able to do any testing with our production network until WEP makes it in. I am very impressed at the stability of the software for your first beta release and know you're in a great position to start adding all of the features of V2 back in and then some. Congrats on the hard work- it should be fun from here!
Thank you for your feedback.
The history option in the system console is lacking, however we are working on adding this.
The system save option take a little while as it deals with a flash device as opposed to faster ATA and will peak the CPU meter in the process, as will "activate changes".
Thank you for your client-side 11b observations, we will investigate this.
Without WEP I can only bench test, but I left an iperf -d running (throughput test both ways simultaneously) and maxed out the CPU on the WAR2 for 14 hours straight and I didn't drop a single ping during. Not even one.
^H doesn't work as backspace, only ^?.
GUI needs higher priority, while maxing out CPU the GUI doesn't respond.
That's it so far. Can't wait to be able to put it up as one of my real APs.
lonnie
02-21-2006, 03:09 PM
What were the numbers you tease? Did you use TCP or UDP?
Yes I think so, but not 100% sure.
I think these are the ones we can use:-
36 - 5180
40 - 5200
As I said "I think we can use" You better check to be sure.
Anne
Hello,
regarding ETSI recommendations, the following freqs are
unlicenced (erc70-03):
5150-5250, 5250-5350 - 200mw eirp, only indoors (meaning, you can use it outdoors too :)
5470-5725 1w eirp, outdoors ok
5725-5875 - 25mw eirp annex 1
I suppose most or probably all EU countries meet this recommendation.
Well keep in mind this is both ways simultaneously! The test is tcp and I believe the test payload is compressible. This is a 266MHz WAR2, bridged ethernet/atheros, atheros is 802.11a turbo AP mode.
I was using connection tracking right up until now, with it on I was seeing 17.1Mbit up and 20.5 down simultaneously.
With connection tracking off like it should be, two ways simultaneously using tcp I am seeing 23.4 up, 30.6 down. Both ways, same time! That result only seems to vary by about half a mbit or so.
One-way tests give me 42.9Mbit up, 34.7Mbit down pretty much every time with only tiny variations (42.7, 42.8.. 34.6...)
All of these tests are hitting the WAR's 266MHz CPU as the bottleneck which at the moment I can confirm because the StarOS v3 GUI becomes non-responsive. I can't really explain it (maybe someone with deeper knowledge can) but it seems to use a bit less CPU when the WAR receives traffic in via atheros rather than transmitting out through atheros. That's the only reason the up/down numbers are so far apart.
lonnie
02-21-2006, 04:20 PM
Thanks for the numbers. Not bad for TCP, eh? Transmit does take more code, thus more CPU.
Any chance you can try the tests in routed mode? I'd be curious to know the difference.
Yeah that's great TCP throughput for that CPU. I should also mention that the TCP buffer size on both sides is 8KB and that's relatively small but it doesn't make too much difference when your latency is a steady 0.8ms - 3ms the whole time.
In routed mode with no connection tracking, 802.11a turbo on 266MHz WAR2. TCP test using iperf, compressible data.
One-way tests: 42.9Mbit up, 37.7Mbit down.
Both ways simultaneously in routed mode is giving me varied results up and down which is more what one would expect when doing a test both ways simultaneously. Here is a sample of the results:
26.0Mbit up, 30.8Mbit down
30.5Mbit up, 25.9Mbit down
25.9Mbit up, 30.9Mbit down
In summary, compared to bridged, routed traffic seems to be slightly more CPU-efficient when transmitting out through the atheros card, receive speed in through atheros is the same.
nelson05
02-21-2006, 07:22 PM
Just uploaded Beta4 which I noticed had a couple of improvements listed regarding 'B' compatibility.
I didn't notice a change in behavior when associating to my Linksys AP as a Station. After changing the Operating Mode to 802.11b in StarV3, the rates reported still were 'G' speeds.
I went a step further and modified the operating mode on the Linksys AP. First I changed from mixed to 'G' only. Even though the WAR was programmed for 802.11b, it re-associated and continued to transmit at 'G' data rates. After changing the mode to 'B' only on the Linksys, the WAR finally shifted to 'B' data rates when set on 802.11b and 802.11g. From what I can tell, at least as a station, there is no difference between 802.11b and 802.11g. The WAR using both settings was able to associate to whatever mode the Linksys was set.
Thank you for the feedback. The 802.11b updates in beta-4 are related to ap-mode, however there are more to come.
nelson05
02-21-2006, 07:51 PM
Thanks. It is great to see the releases keep coming.
I guess I should say that the 'B' mode issues aren't a huge deal for me....just thought you'd like to know early on before you start bolting on things. I'll be really excited when WEP makes an appearance.
On the subject of WEP and the new Atheros configuration dialog. Will it be similar to V2's advanced security and access control option? I really grew to like that interface's flexibility.
Thank you for your test results.
Yes, the v2 advanced security interface was quite flexible and as such, will more than likely be re-implemented (with appropriate enhancements) for the war platform.
bminish
02-22-2006, 01:18 AM
Hello,
regarding ETSI recommendations, the following freqs are
unlicenced (erc70-03):
5150-5250, 5250-5350 - 200mw eirp, only indoors (meaning, you can use it outdoors too :)
5470-5725 1w eirp, outdoors ok
5725-5875 - 25mw eirp annex 1
I suppose most or probably all EU countries meet this recommendation.
Ireland actually has some additional privileges above and beyond ETSI
5725 to 5875 2W EIRP outdoors, subject to a notification requirement and a maximum power 'density' of 100mW EIRP per Mhz of occupied bandwidth. I.e running 2W EIRP on a 5 or 10 Mhz 'Stealth' channel is not ok
http://www.comreg.ie/5_8GHzRegistration.asp?S=4&NavID=198&M=
5470 to 5725 1W EIRP outdoors.
You are supposed to do Dynamic transmit power control and DFS (Dynamic Frequency Selection ) as well as radar avoidance in ETSI but it appears that these are not presently requirements in Ireland. Nor is there a notification requirement presently for this segment.
Presumably however in V3 country code ## and making one's own frequency selection also still works in V3?
.brendan
The outdoor 2W band in Ireland is actually 5725 – 5875MHz
bminish
02-22-2006, 04:17 AM
The outdoor 2W band in Ireland is actually 5725 – 5875MHz
You are quite right, slippy fingers on my part this morning!
lonnie
02-22-2006, 02:02 PM
Everyone should do some reading on these two links.
http://www.olsr.org/docs/olsrd.8.html
http://www.olsr.org/docs/olsrd.conf.5.html
We are setting defaults so you will only have to enter the IP addresses in the
Hna4 {[sub-options]} section.This will release this afternoon. We hope you have fun.
A piece of software geared towards wireless "mesh" networking?
simcor23
02-22-2006, 05:46 PM
This sounds awesome, I'm going to have to do a lot of studying. I smell VOIP!!!! saweeet.
aziraphale
02-24-2006, 09:54 AM
Update - Frequencies 5745 - 5825 have been added to V3 for Ireland and other EU countries to match that of V2.
actually, Ireland has 5725 - 5875, but the current atheros radios may not support that.
The atheros radios supported by the WAR do have support for this range, and it is now available to use in the latest release.
nelson05
02-26-2006, 01:03 PM
Been playing with olsr and so far it is looking really good. It was amazingly simple to setup. I am having having a couple of issues where when I break a link between two boxes (by changing the SSID to a bogus value on one side of the link and then applying changes), the systems do not always route around the issue. Most of the time they do and I'm trying to gather more information on the symptoms when they don't, but I'm at a loss so far. Restarting oslr on one of the routers usually seems to make things right though this obviously shouldn't be required and sounds a bit like the ospf drama that has been discussed previously.
I'm wondering if I'm missing what Lonnie said here:
We are setting defaults so you will only have to enter the IP addresses in the
Hna4 {[sub-options]} section.This will release this afternoon. We hope you have fun.
In reading the documentation and examining the config file comments, IP addresses don't seem to be required here, subnets and masks do. Am I missing something? Also, when entering multiple subnets in this section, should each go on a separate line with no commas or other delimiters separating the entries (ask long as they are in the brackets)? Are these entries required or does the system automatically look at each interface and the subnet assigned to build the routing table?
lonnie
02-26-2006, 08:46 PM
Sorry, I meant subnets of the IP on the devices you want announced. We put one per line.
The system should recognize the down radio and go around it since it is always talking to its neighbours. Let me know what you find.
knolan
03-07-2006, 12:22 PM
Yes I think so, but not 100% sure.
I think these are the ones we can use:-
36 - 5180
40 - 5200
44 - 5220
48 - 5240
52 - 5260
56 - 5280
60 - 5300
64 - 5320
100 - 5500
104 - 5520
108 - 5540
112 - 5560
116 - 5580
120 - 5600
124 - 5620
128 - 5640
132 - 5660
136 - 5680
140 - 5700
149 - 5745
153 - 5765
157 - 5785
161 - 5805
165 - 5825
As I said "I think we can use" You better check to be sure.
Anne
In Ireland the Bands allowed to be used "Unlicensed" are
2.400 GHz --> 2.483.5 GHz
5.150 GHz --> 5.350 GHz (200 mW max output, Indoor use only)
5.470 GHz --> 5.725 GHz (1 W max output)
5.725 GHz --> 5.875 GHz (2 W max output)
Will we see Star OS allowing all these bands?
Thanks
Keith
The band is already supported, however the frequency list uses ieee channel alignment for compatibility with other countries.
SSh/Ping/tcp throughput seems to be broken in beta10 .. switched back to 9 and it was fine ..
ping & tcp thruput definitely broken in beta 10, but I am able to use ssh client
Thank you. I have reproduced the issue and will get a new release out early next week.
Thanks!
The ping and tcp throughput test facilities have been fixed for the upcoming beta-11 release. Thank you very much for pointing this out.
Alfa - You mention ssh, ping, and tcp throughput is broken. I have been able to replicate and fix the ping and tcp throughput facilities, however I am unable to find anything wrong with ssh (client or server). Can you please explain in detail the issue you are encountering with the beta-10 release regarding ssh?
Thank you for your assistance.
I was configuring p2p links at the weekend and could not connect to another node using the beta10 on both side ( ip addresses setup correct etc ) however i quickly downgraded and everything worked .. I cannot reproduce this as I now have connected clients on that link....
It may be however that ssh is fine, I just didn’t have time to test it extensively. Sorry I cant be of more help.
Thank you for the update.
Bossman
03-13-2006, 10:35 PM
I was configuring p2p links at the weekend and could not connect to another node using the beta10 on both side ( ip addresses setup correct etc )
I'm seeing the same thing and noticed the Beta11 release... I think the ping and throughput issue is NOT just from the GUI. I can't ping it from a V3 windows WAR box or my PC either.
Will go for a drive tomorrow and see if the Beta11 fixes this.
On a positive note.... 18.5 miles and the GUI in Beta10 tells me I'm hooked up at 48Mbps.. no amps. The only bad thing is I have about $10,000 of amps that I have no use for now.
mp3turbo
03-15-2006, 12:33 PM
you should have NEVER bought those amps. You can do 19miles on 5.8GHz with 29dB dishes and still have -65dB signal which is excellent for 48Mbps operation.
The math is so simple...
5.8GHz free space loss : 137.4dB (any calculator will tell you this)
CM9 radio card output : ~14dB
antenna1 gain : 29dB
antenna2 gain : 29dB
result: +14 - 137.4 + 29 + 29 - something for cable/pigtail loss (let's say 4dB) = -70dB.
-70dB is EXCELLENT SIGNAL. WITHOUT ANY AMPS and on 5.8GHz!!!!!
people, I still don't get why the heck you need amps. WHY? WHY? WHY?
You have never tried to do proper 20mile shot. You just buy amps because it is "easy". And I was calculating 5.8GHz link, situation is much better for you on 2.4GHz !!
bye, mp3turbo.
kbldawg
03-17-2006, 08:44 PM
I know it's a little late, but I thought I would go ahead and show my WAR results.
Distance = 6.5 Miles
Hardware = Quad WARs on both ends
Radio = CM9s
Network = Routed
Conn Track. = off
Super A/G = On
Signal = -68
Noise = -95
Qual = 27
Rate = Locked at 48
Up = 33.8Mb/s
Down = 32.8Mb/s
This was using the onboard throughput utility.
Btw, I haven't even fined tuned the antennas yet. ha!
Thanks for a great product!!
Bossman
03-21-2006, 08:47 PM
you should have NEVER bought those amps. You can do 19miles on 5.8GHz with 29dB dishes and still have -65dB signal which is excellent for 48Mbps operation.
-70dB is EXCELLENT SIGNAL. WITHOUT ANY AMPS and on 5.8GHz!!!!!
people, I still don't get why the heck you need amps. WHY? WHY? WHY?
You have never tried to do proper 20mile shot. You just buy amps because it is "easy". And I was calculating 5.8GHz link, situation is much better for you on 2.4GHz !!
bye, mp3turbo.
Well, in my defence (feel like I'm on trial here), I bought these many years ago... a few from lonnie too.... before 5.8 was available for under $4000 per side.
We've been pulling them all out but they are still functional.
We now have lots of 15+ mile shots with no amps, so you're preaching to the converted.