uSoft Workgroup and wireless

D

davidraw 21 years ago

Is this a wireless problem or a general microsoft workgroup problem?

I have an ad-hoc workgroup of 3 computers all talking TCP/IP

wirelessly to a Linksys WRT54g (with no WINS server) and a WET54g

connected to an IP Cam.

The computers IP's are in the range 192.168.2.100 - 192.168.2.102 and

run XP Pro and 2000 Pro.

Under low network load all the computers can see each other and

everything is fine.

When the load is high (I have 6 Axis 2100 IP cams talking to the

server and using about 10-12M of the 54M bandwidth), the workgroup is

pretty much inaccessible. Somtimes the computers can see each other but

they cannot connect, sometimes they connect just fine and sometimes the

workgroup can only see its own computer.

Under very high load the computers cannot even be pinged but under low

load they are giving a 1ms ping time.

No matter what the load conditions, all computers can see the gateway

(192.168.2.254 - WRT54g) and connect to the internet fine.

Am I barking up the wrong tree? Should I run the workgroup

differently? Should I get rid of Linksys?

I am unsure how an ad-hoc workgroup actually works out what computers

are connected. I am guessing they are continually sending messages

around the network. Are they TCP/UDP or something proprietry?

Anyone else solved this problem? Thanks for any help.

- David

Vote

J

Jeff Liebermann 21 years ago

Hard to say.

Are you using Linksys firmware or alternative firmware in the WRT54G?

You don't have 54Mbits/sec bandwidth. That's the connection speed. Assuming ideal conditions, you won't get more than about 25Mbits/sec in thruput. Typical is about 1/3 to 1/2 of the connection speed. Dive into the status screen on the routers and radios and check your connection speed. My guess is that you're probably saturated at

10-12Mbits/sec.

It's failing the "windows browser election" abomination.

There you have it. You're saturated. You're at or above the available bandwidth limit and are starting to drop packets. Since the TTL is artificially short of pings, they'll be the first to disappear.

It's a matter of signal strength and distance. Some computahs are closer to each other, or closer to the WRT54G that's next to the gateway. Check the connection speed. It will give a good idea of the path quality.

Linksys WRT54G are quite good. Stay with them. There's nothing much wrong with the topology. However, you're making things difficult using ad-hoc. There's no central controller, so some things just tend to get lost. There's also no bandwidth control or traffic management.

I'm not sure switching to infrastructure is going to help. It really depends on your traffic requirements. If you're cameras are running a "push server" which send frames as fast as the traffic will bear, you will be saturated no matter how much bandwidth you give it. I'm not familiar with the Axis 2100 but there should be some kind of frame rate control on the push server. Slow it down somewhat and you'll probably be all right with the existing arrangement. Also, so some measuring of bandwidth used. Try it with a wired ethernet connection instead of wireless and see how much bandwidth it really wants.

I suggest you look into alternative firmware for the WRT54G. One of the features is a crude form of bandwidth management. You can prevent the cameras from hogging all the bandwidth. See the various releases on the Sveasoft site for details.

All these wireless networks are bridges that work on ISO layer 2. They don't know anything about TCP/UDP/ICMP/whatever that are on ISO layer 3.

I have a customer with 3ea old Axis 210 cameras. I can totally fill up his outgoing DSL bandwidth (384Kbits/sec) with these cameras using the built in push server. I forgot exactly what I did to slow them down, but they're now demand driven and no longer pose a problem.

Vote

J

Jeff Liebermann 21 years ago

Yep. Y'er right. At least DLink admits it and apparently enforces it. However, there's really no technical reason to do so except the someone forgot to add ad-hoc to the 802.11g specifications. Considering the gigantic vendor battle that was required to get

802.11g-2003 ratified, it's not suprising that something got left out. I don't do much ad-hoc networking so I don't know if there are any client radios that will do 802.11g speeds in ad-hoc mode. My astute guess is that most of the "game adapters" will do 54Mbits/sec in ad-hoc as it seems to be an advertised feature (reading between the lines). Dunno for sure.

I'm also suspicious about the original description. The stock WRT54G does not have a client mode (the WAP54G does) and therefore cannot participate in an ad-hoc network. However, alternative firmware (Sveasoft) does add a client mode to the WRT54G, thus allowing it's use in an ad-hoc network. I've never tried this so I don't know how it works. In any case, he would not be getting 10-12Mbits/sec of thruput in 802.11b mode, which is limited to about 5mbits/sec thruput under the best of circumstances.

Vote