TL-WR842ND & SECN1.1
187 views
Skip to first unread message
Costas Gargerakis
May 8, 2012, 11:33:05 AM5/8/12
to village-...@googlegroups.com
Hello,
I've managed to get my hands on some tl-wr842nd devices(4) and i've been doing some tests with the experimental secn 1.1 firmware.
I'm using ip addresses 10.130.1.20-23 for the nodes and 192.168.178.0/24 for my lan that contains an adsl router with dhcp/dns activated.
At first, i only changed the 'IP Address' and the mesh seemed to work pretty well, but i soon noticed that the pings were highly inconsistent, and sometimes when the network usage was a bit above zero, i was even getting a slight packet loss.
In an attempt to fix this problem, i changed the wireless channel to 2(completely empty) with no noticeable effect and then i tried to set the 'MP Gateway Mode' from OFF to server/client depending on each AP's LAN connectivity(or lack of).
The result was even higher ping fluctuations, very high packet loss and a download speed never getting above 20k/s.
Also, i tried enabling VIS following the instructions from http://dev.villagetelco.org/trac/browser/spud/trunk/INSTALL.VIS.MP and while it works, the spud server always lists 0 links in all added nodes and doesn't show the 'MP firmware' at all.
Are there any known solutions for these issues, or should i attribute them to the fact that I'm dealing with an experimental firmware?
PS: Most of the tests were done with all the nodes in the same room, at a pretty short distance from each other.
I've managed to get my hands on some tl-wr842nd devices(4) and i've been doing some tests with the experimental secn 1.1 firmware.
I'm using ip addresses 10.130.1.20-23 for the nodes and 192.168.178.0/24 for my lan that contains an adsl router with dhcp/dns activated.
At first, i only changed the 'IP Address' and the mesh seemed to work pretty well, but i soon noticed that the pings were highly inconsistent, and sometimes when the network usage was a bit above zero, i was even getting a slight packet loss.
root@cgar:/var/www/spud/app/config# ping 10.130.1.20 -c 100 -i 0.1 -q -s 1400
PING 10.130.1.20 (10.130.1.20) 1400(1428) bytes of data.
--- 10.130.1.20 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 10196ms
rtt min/avg/max/mdev = 2.216/597.459/2996.424/904.130 ms, pipe 26
In an attempt to fix this problem, i changed the wireless channel to 2(completely empty) with no noticeable effect and then i tried to set the 'MP Gateway Mode' from OFF to server/client depending on each AP's LAN connectivity(or lack of).
The result was even higher ping fluctuations, very high packet loss and a download speed never getting above 20k/s.
Also, i tried enabling VIS following the instructions from http://dev.villagetelco.org/trac/browser/spud/trunk/INSTALL.VIS.MP and while it works, the spud server always lists 0 links in all added nodes and doesn't show the 'MP firmware' at all.
root@cgar:/var/www/spud/app/tmp/logs# telnet 10.130.1.20 2005
Trying 10.130.1.20...
Connected to 10.130.1.20.
Escape character is '^]'.
{ "router" : "92:f6:52:2d:8e:73", "neighbor" : "fa:d1:11:b9:aa:a1", "label" : "1.108" }
{ "router" : "92:f6:52:2d:8e:73", "neighbor" : "92:f6:52:2d:8e:0b", "label" : "1.049" }
{ "router" : "92:f6:52:2d:8e:73", "gateway" : "90:f6:52:2d:8e:71", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:73", "gateway" : "7a:be:16:2f:d4:67", "label" : "TT" }
{ "primary" : "92:f6:52:2d:8e:73" }
{ "router" : "fa:d1:11:b9:aa:a1", "neighbor" : "92:f6:52:2d:8e:73", "label" : "1.015" }
{ "router" : "fa:d1:11:b9:aa:a1", "neighbor" : "92:f6:52:2d:8e:3f", "label" : "1.015" }
{ "router" : "fa:d1:11:b9:aa:a1", "neighbor" : "92:f6:52:2d:8e:0b", "label" : "1.011" }
{ "router" : "fa:d1:11:b9:aa:a1", "gateway" : "62:93:0f:e6:a0:4c", "label" : "TT" }
{ "primary" : "fa:d1:11:b9:aa:a1" }
{ "router" : "92:f6:52:2d:8e:3f", "neighbor" : "fa:d1:11:b9:aa:a1", "label" : "1.020" }
{ "router" : "92:f6:52:2d:8e:3f", "neighbor" : "92:f6:52:2d:8e:73", "label" : "1.000" }
{ "router" : "92:f6:52:2d:8e:3f", "neighbor" : "92:f6:52:2d:8e:0b", "label" : "1.053" }
{ "router" : "92:f6:52:2d:8e:3f", "gateway" : "b2:2c:0e:4a:26:d6", "label" : "TT" }
{ "primary" : "92:f6:52:2d:8e:3f" }
{ "router" : "92:f6:52:2d:8e:0b", "neighbor" : "fa:d1:11:b9:aa:a1", "label" : "1.053" }
{ "router" : "92:f6:52:2d:8e:0b", "neighbor" : "92:f6:52:2d:8e:73", "label" : "1.032" }
{ "router" : "92:f6:52:2d:8e:0b", "neighbor" : "92:f6:52:2d:8e:3f", "label" : "1.000" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:1c:68:01:a3:f6", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:21:b7:a4:49:40", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:04:00:ed:dd:dc", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:21:5a:11:84:d5", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:15:56:cf:ec:a0", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "8a:0d:4c:2b:e1:4f", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:19:99:12:d6:e9", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:02:d1:12:4d:28", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "52:54:00:b6:2c:a4", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "52:54:00:5f:bb:c7", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:14:7c:b6:97:be", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "3c:4a:92:6f:e5:ef", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:02:44:4b:a6:70", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "52:54:00:42:23:ba", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:21:5a:11:85:b5", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:0e:08:dd:ce:35", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:0e:08:d2:18:ca", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "52:54:00:43:2f:81", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:21:5a:11:85:ba", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:0e:08:d2:85:40", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:0e:08:d2:da:32", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:0c:f1:55:ae:a9", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:0e:08:d2:85:3f", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:16:e6:36:79:b8", "label" : "TT" }
{ "router" : "92:f6:52:2d:8e:0b", "gateway" : "00:21:5a:11:85:a7", "label" : "TT" }
{ "primary" : "92:f6:52:2d:8e:0b" }
Connection closed by foreign host.
root@cgar:/var/www/spud/app/tmp/logs# /usr/bin/wget -O - -q -t 1 http://localhost/spud/nodes/update
root@cgar:/var/www/spud/app/tmp/logs# tail error.log
root@cgar:/var/www/spud/app/tmp/logs# tail node.log
2012-05-08 18:18:22 Node: INFO missing nodes update
2012-05-08 18:18:22 Node: INFO No links found
2012-05-08 18:18:22 Node: INFO missing nodes update
2012-05-08 18:18:35 Node: AJAX details
2012-05-08 18:24:07 Node: INFO missing nodes update
2012-05-08 18:24:07 Node: INFO No links found
2012-05-08 18:24:13 Node: INFO missing nodes update
2012-05-08 18:24:15 Node: INFO No links found
2012-05-08 18:24:48 Node: INFO missing nodes update
2012-05-08 18:24:48 Node: INFO No links found
Are there any known solutions for these issues, or should i attribute them to the fact that I'm dealing with an experimental firmware?
PS: Most of the tests were done with all the nodes in the same room, at a pretty short distance from each other.
T Gillett
May 8, 2012, 5:49:54 PM5/8/12
to village-...@googlegroups.com
Hi Costas
Good to hear you are working with the 842 devices.
The SECN firmware for these devices is *very* experimental and a
little ahead of the mainstream SECN-1.1 development on Mesh Potatoes
and the TP Link 703 and 3020 devices. It uses a later revision of
OpenWrt and Linux kernel, as well as a later version of batman-adv.
Mea culpa, I'm afraid. I should have put note on the site to that effect.
For historical reasons, we have until recently been restricted with
updating the kernel on the MeshPotato due to compatibility issues with
the drivers for the telephony sub-system. Elektra has now fixed this
and the plan is to finalise SECN-1.1 on the existing kernel and
batman-adv versions, then move to SECN-2 which will put all devices on
the same software basis.
All that said, I have been using an 842 and some 703 devices running
the later software for some experimental OLPC work and haven't seen
the issues you have noted. (However that does not mean there isn't a
problem...)
A couple of points to watch however.
Firstly channel separation. The wifi channels overlap significantly,
so for separation you need to operate nominally three channels apart.
For an 11 channel system, the convention is to use only channels 1, 3,
6, 9.
Secondly, if you have other VT or SECN devices operating nearby they
may be causing issues with your 842 devices running the new software
which is not compatible with the mainstream SECN software at the
batman-adv layer. I have seen this issue in my work.
If this is the case in your situation, try getting as much channel
separation as possible, and you can also change the BSSID on the mesh
interface to create a separate batman-adv mesh 'cell'. Note that the
first part of the BSSID must be an even number eg 02, 04, 06 etc.
This is an OpenWrt restriction.
Let us know if any of this helps, and if there is still a problem I
can do some tests here also to help out.
Regards
Terry
> --
> You received this message because you are subscribed to the Google Groups
> "village-telco-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/village-telco-dev/-/AZJ6y1TQSUEJ.
> To post to this group, send email to village-...@googlegroups.com.
> To unsubscribe from this group, send email to
> village-telco-...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/village-telco-dev?hl=en.
Good to hear you are working with the 842 devices.
The SECN firmware for these devices is *very* experimental and a
little ahead of the mainstream SECN-1.1 development on Mesh Potatoes
and the TP Link 703 and 3020 devices. It uses a later revision of
OpenWrt and Linux kernel, as well as a later version of batman-adv.
Mea culpa, I'm afraid. I should have put note on the site to that effect.
For historical reasons, we have until recently been restricted with
updating the kernel on the MeshPotato due to compatibility issues with
the drivers for the telephony sub-system. Elektra has now fixed this
and the plan is to finalise SECN-1.1 on the existing kernel and
batman-adv versions, then move to SECN-2 which will put all devices on
the same software basis.
All that said, I have been using an 842 and some 703 devices running
the later software for some experimental OLPC work and haven't seen
the issues you have noted. (However that does not mean there isn't a
problem...)
A couple of points to watch however.
Firstly channel separation. The wifi channels overlap significantly,
so for separation you need to operate nominally three channels apart.
For an 11 channel system, the convention is to use only channels 1, 3,
6, 9.
Secondly, if you have other VT or SECN devices operating nearby they
may be causing issues with your 842 devices running the new software
which is not compatible with the mainstream SECN software at the
batman-adv layer. I have seen this issue in my work.
If this is the case in your situation, try getting as much channel
separation as possible, and you can also change the BSSID on the mesh
interface to create a separate batman-adv mesh 'cell'. Note that the
first part of the BSSID must be an even number eg 02, 04, 06 etc.
This is an OpenWrt restriction.
Let us know if any of this helps, and if there is still a problem I
can do some tests here also to help out.
Regards
Terry
> You received this message because you are subscribed to the Google Groups
> "village-telco-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/village-telco-dev/-/AZJ6y1TQSUEJ.
> To post to this group, send email to village-...@googlegroups.com.
> To unsubscribe from this group, send email to
> village-telco-...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/village-telco-dev?hl=en.
Costas Gargerakis
May 9, 2012, 9:45:21 AM5/9/12
to village-...@googlegroups.com
Hi Terry,
I was already aware of the experimental state of the 842 firmware - the note is already there, and a bit of searching reveals the difference(s) in batman-adv.
There are no other VT/SECN devices nearby, or any other mesh network - just some common wifi enabled adsl routers.
I tried changing the wifi channels and i got better results on channel 6(channels 2 to 10 are completely empty).
Furthermore, reducing the number of SECN devices in the vicinity to 2 resulted in much lower ping fluctuation, but i'm
afraid it still doesn't look too good.
I'm a complete newbie in mesh networks in general and i might be misinterpreting my results, so let me explain my setup.
LAN: 192.168.178.0/24
PC1: eth0-192.168.178.112, eth0:1-10.130.1.10
MESH: WR842N-v1 1.1RC2 (r31137), only changed : county code(GR), channel(6), tx-power(20)
TP20: 10.130.1.20, no LAN connection
TP23: 10.130.1.23, connected to the LAN
PC2: 192.168.178.65, connected to VT-SECN-AP
Simple pings(all ran at the exact same time):
PC2: ping pc1 : min/avg/max = 26 / 95 / 442
PC1: ping pc2 : min/avg/max = 2 / 53 / 391
PC1: ping tp20: min/avg/max = 2 / 917 / 4549
I didn't bother to do bandwidth tests with that much ping fluctuation.
Since you've been testing the same devices as well, can you tell me if they should work without messing
with any configuration options other than tx-power, country and channel # , in the case that no other mesh
devices are in the vicinity?
Regards,
Costas
I was already aware of the experimental state of the 842 firmware - the note is already there, and a bit of searching reveals the difference(s) in batman-adv.
There are no other VT/SECN devices nearby, or any other mesh network - just some common wifi enabled adsl routers.
I tried changing the wifi channels and i got better results on channel 6(channels 2 to 10 are completely empty).
Furthermore, reducing the number of SECN devices in the vicinity to 2 resulted in much lower ping fluctuation, but i'm
afraid it still doesn't look too good.
root@cgar:~# ping 10.130.1.20 -c 100 -i 0.1 -q -s 1400
PING 10.130.1.20 (10.130.1.20) 1400(1428) bytes of data.
--- 10.130.1.20 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 10089ms
rtt min/avg/max/mdev = 2.220/82.481/353.622/83.814 ms, pipe 4
I'm a complete newbie in mesh networks in general and i might be misinterpreting my results, so let me explain my setup.
LAN: 192.168.178.0/24
PC1: eth0-192.168.178.112, eth0:1-10.130.1.10
MESH: WR842N-v1 1.1RC2 (r31137), only changed : county code(GR), channel(6), tx-power(20)
TP20: 10.130.1.20, no LAN connection
TP23: 10.130.1.23, connected to the LAN
PC2: 192.168.178.65, connected to VT-SECN-AP
Simple pings(all ran at the exact same time):
PC2: ping pc1 : min/avg/max = 26 / 95 / 442
PC1: ping pc2 : min/avg/max = 2 / 53 / 391
PC1: ping tp20: min/avg/max = 2 / 917 / 4549
I didn't bother to do bandwidth tests with that much ping fluctuation.
Since you've been testing the same devices as well, can you tell me if they should work without messing
with any configuration options other than tx-power, country and channel # , in the case that no other mesh
devices are in the vicinity?
Regards,
Costas
T Gillett
May 9, 2012, 6:49:28 PM5/9/12
to village-...@googlegroups.com
Hi Costas
I have done a test with a similar setup to yours
I have one WR842 device which is connected to my LAN via Ethernet.
It has an IP of 192.168.1.50 which is in the same subnet as my LAN.
I have one laptop connected to the WR842 via the SECN wifi.
I have one WR703 device meshed with the WR842, and a second laptop
connected to it via ethernet. It has an IP of 192.168.1.50 which is in
the same subnet as my LAN.
The laptops are running Ubuntu 10.04 and 11.04 and have IPs in the LAN
subnet range.
From either laptop I can ping the other, and any other devices on the
LAN, with ping times of no more that 3mSec. I can ping Google with
consistent 30mSec responses.
I can download 10MB files from my ISP at 4Mb/s rate sustained over my
5Mb/s ADSL link.
I also started up another WR703 device so that there were three
devices on the mesh, and that did not change the results.
So that all seems to be working fine in my test set up.
The differences to your set up that I can see, and that might be worth
looking at to help locate, the problem are:
1. You are running two IPs on the eth0 card on your PC1 which is where
you are also seeing the changing ping times. Try just using a single
IP and see if this changes the results. (What OS are you using on the
PCs?)
2. You have your WR842 devices on a separate IP subnet range to the
LAN, whereas mine are all in the same range. Try putting the devices
in the same range and see if that affects the results.
Neither of these things is an immediately obvious cause of the
problem, but would be worth eliminating in order to isolate the
problem.
And to answer your other question, I am using the WR842 SECN firmware
with no changes other than the IP address.
Regards
Terry
I have done a test with a similar setup to yours
I have one WR842 device which is connected to my LAN via Ethernet.
It has an IP of 192.168.1.50 which is in the same subnet as my LAN.
I have one laptop connected to the WR842 via the SECN wifi.
I have one WR703 device meshed with the WR842, and a second laptop
connected to it via ethernet. It has an IP of 192.168.1.50 which is in
the same subnet as my LAN.
The laptops are running Ubuntu 10.04 and 11.04 and have IPs in the LAN
subnet range.
From either laptop I can ping the other, and any other devices on the
LAN, with ping times of no more that 3mSec. I can ping Google with
consistent 30mSec responses.
I can download 10MB files from my ISP at 4Mb/s rate sustained over my
5Mb/s ADSL link.
I also started up another WR703 device so that there were three
devices on the mesh, and that did not change the results.
So that all seems to be working fine in my test set up.
The differences to your set up that I can see, and that might be worth
looking at to help locate, the problem are:
1. You are running two IPs on the eth0 card on your PC1 which is where
you are also seeing the changing ping times. Try just using a single
IP and see if this changes the results. (What OS are you using on the
PCs?)
2. You have your WR842 devices on a separate IP subnet range to the
LAN, whereas mine are all in the same range. Try putting the devices
in the same range and see if that affects the results.
Neither of these things is an immediately obvious cause of the
problem, but would be worth eliminating in order to isolate the
problem.
And to answer your other question, I am using the WR842 SECN firmware
with no changes other than the IP address.
Regards
Terry
> --
> You received this message because you are subscribed to the Google Groups
> "village-telco-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/village-telco-dev/-/Z4Lwsc1nE5IJ.
> You received this message because you are subscribed to the Google Groups
> "village-telco-dev" group.
> To view this discussion on the web visit
T Gillett
May 10, 2012, 7:47:16 AM5/10/12
to village-...@googlegroups.com
Small correction:
The WR703 device has an IP of 192.168.1.41, and the second one is .43
The WR703 device has an IP of 192.168.1.41, and the second one is .43
Costas Gargerakis
May 10, 2012, 9:18:17 AM5/10/12
to village-...@googlegroups.com
Hi Terry,
For my tests, PC1 is a hp-xw6400 workstation with ubuntu 12.04 and PC2 is a dell inspiron 910 netbook with windows xp.
I tried changing the ips of the TP devices to be inside my lan's subnet, but i didn't notice any difference, and now the only
difference between our test setups should be that i'm using >1 842 devices.
I tried isolating the lan to just PC1 and a switch, on which i connected TP23 and now i'm getting consistent 2-4ms
pings(5ms avg) from PC2 to TP23, except some short and infrequent spikes that are probably due to network traffic.
The problem is that when i try pinging TP20 from PC2 in the same scenario, i'm getting 4-213ms pings(43ms avg), and
of'course if i connect that 'reduced' lan to a real lan network, the pings get much, much higher.
So, to recap...
PC1(tp23)<->TP23 & PC2<->PC1(on tp23) = low pings
PC1(on tp23)<->TP20 & PC2(lan)<->TP20 = high/inconsistent pings
PC1<->PC2 = low pings when close to TP23, high pings close to TP20
So, i'm guessing the problem is in the connection between TP20 and TP23...?
Has anyone tried setting up a mesh with more than one 842, or just with 842 devices?
Are there any known issues that could be affecting the mesh's performance, or a way to debug/monitor it?
By the way, if you would like to debug whatever is going on in my test setup, i could provide ssh/openvpn access easily.
Regards,
Costas
For my tests, PC1 is a hp-xw6400 workstation with ubuntu 12.04 and PC2 is a dell inspiron 910 netbook with windows xp.
I tried changing the ips of the TP devices to be inside my lan's subnet, but i didn't notice any difference, and now the only
difference between our test setups should be that i'm using >1 842 devices.
I tried isolating the lan to just PC1 and a switch, on which i connected TP23 and now i'm getting consistent 2-4ms
pings(5ms avg) from PC2 to TP23, except some short and infrequent spikes that are probably due to network traffic.
The problem is that when i try pinging TP20 from PC2 in the same scenario, i'm getting 4-213ms pings(43ms avg), and
of'course if i connect that 'reduced' lan to a real lan network, the pings get much, much higher.
So, to recap...
PC1(tp23)<->TP23 & PC2<->PC1(on tp23) = low pings
PC1(on tp23)<->TP20 & PC2(lan)<->TP20 = high/inconsistent pings
PC1<->PC2 = low pings when close to TP23, high pings close to TP20
So, i'm guessing the problem is in the connection between TP20 and TP23...?
Has anyone tried setting up a mesh with more than one 842, or just with 842 devices?
Are there any known issues that could be affecting the mesh's performance, or a way to debug/monitor it?
By the way, if you would like to debug whatever is going on in my test setup, i could provide ssh/openvpn access easily.
Regards,
Costas
> To post to this group, send email to village-telco-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> village-telco-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/village-telco-dev?hl=en.
> To post to this group, send email to village-telco-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> village-telco-dev+unsubscribe@googlegroups.com.
T Gillett
May 10, 2012, 5:50:45 PM5/10/12
to village-...@googlegroups.com
Hi Costa
I am not aware of anyone else using this firmware on the 842 devices as yet and I only have one device. So it is the bleeding edge for us I think.
Since you suspect the link across the mesh is the issue, let's test just that element.
What happens if you connect a pc to the 842 devices via Ethernet and ssh in to the 842 command line, then run ping tests between the 842 devices?
You could try this with just two devices then add the others to the mesh to see what happens.
Another useful test is to scp files of a few MB between devices. Copy the test file into the /tmp directory so that it is in ram for fast access. The sysupgrade image file is 4MB so is useful for this test.
You can also make a couple of copies and scp them with a single command to get a sustained throughput for a few seconds. The scp command will give you the transfer stats and you should see rates above 1 Mb/sec.
Regards
Terry
Costas Gargerakis
May 14, 2012, 9:34:13 AM5/14/12
to village-...@googlegroups.com
Hi Terry,
I did some quick tests by transferring a 10mb(urandom) file and the results showed the
same thing - 1.4M/s transfer rate from a pc to an 842, 50-100k/s between two 842s.
Then i tried repositioning the 842s and found out that if they are more further apart from
each other, the problems that i've been noticing started going away.
Now, with stock antennas and about 10 meters between them, i'm up to 800k/s with some
spikes of 1M/s.
If i leave them on the same spot and replace their antennas with 8dbi ones, the transfer
rates drop down to 200-400k/s, but if i move them even further apart, the speed goes up again.
Is this behavior normal, or am i doing something wrong?
Regards
Costas
I did some quick tests by transferring a 10mb(urandom) file and the results showed the
same thing - 1.4M/s transfer rate from a pc to an 842, 50-100k/s between two 842s.
Then i tried repositioning the 842s and found out that if they are more further apart from
each other, the problems that i've been noticing started going away.
Now, with stock antennas and about 10 meters between them, i'm up to 800k/s with some
spikes of 1M/s.
If i leave them on the same spot and replace their antennas with 8dbi ones, the transfer
rates drop down to 200-400k/s, but if i move them even further apart, the speed goes up again.
Is this behavior normal, or am i doing something wrong?
Regards
Costas
Wayne Abroue
May 14, 2012, 9:47:23 AM5/14/12
to village-...@googlegroups.com
On Mon, May 14, 2012 at 3:34 PM, Costas Gargerakis <cog...@gmail.com> wrote:
> Hi Terry,
>
> I did some quick tests by transferring a 10mb(urandom) file and the results
> showed the
> same thing - 1.4M/s transfer rate from a pc to an 842, 50-100k/s between two
> 842s.
>
> Then i tried repositioning the 842s and found out that if they are more
> further apart from
> each other, the problems that i've been noticing started going away.
> Now, with stock antennas and about 10 meters between them, i'm up to 800k/s
> with some
> spikes of 1M/s.
>
> If i leave them on the same spot and replace their antennas with 8dbi ones,
> the transfer
> rates drop down to 200-400k/s, but if i move them even further apart, the
> speed goes up again.
>
> Is this behavior normal, or am i doing something wrong?
>
> Regards
> Costas
>
>
>
Hi Costas
> Hi Terry,
>
> I did some quick tests by transferring a 10mb(urandom) file and the results
> showed the
> same thing - 1.4M/s transfer rate from a pc to an 842, 50-100k/s between two
> 842s.
>
> Then i tried repositioning the 842s and found out that if they are more
> further apart from
> each other, the problems that i've been noticing started going away.
> Now, with stock antennas and about 10 meters between them, i'm up to 800k/s
> with some
> spikes of 1M/s.
>
> If i leave them on the same spot and replace their antennas with 8dbi ones,
> the transfer
> rates drop down to 200-400k/s, but if i move them even further apart, the
> speed goes up again.
>
> Is this behavior normal, or am i doing something wrong?
>
> Regards
> Costas
>
>
>
I was going to suggest, moving them apart, as your problem did sound
like interference related. Not knowing your specific equip but
ordinarily, yes close up interference is expected.
Wayne
T Gillett
May 15, 2012, 2:55:16 AM5/15/12
to village-...@googlegroups.com
Ho Costas
I have not seen this problem, but I have only one 842. The other devices eg 703 have only simple internal aerials. You may well be seeing the result of rf overload.
Try reducing the TX Power setting to the minimum of 10 on the Adv config page. You should do this uniformally on all nodes.
Also try removing the aerials completely and see what test results you get.
I will check my figures but I think you should see 1Mb/s tfer rates between 842 devices with scp of files in /tmp.
Terry
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/village-telco-dev/-/bBjKl9yq5YQJ.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
T Gillett
May 15, 2012, 8:38:33 AM5/15/12
to village-...@googlegroups.com
Hi Costa
I did some tests transferring files between an 842 device (.50) and a
703 device (.41) with scp as follows:
root@TP-41:/tmp# scp ./test*.bin ro...@192.168.1.50:/tmp
ro...@192.168.1.50's password:
test1.bin 100% 3840KB 960.0KB/s 00:04
test2.bin 100% 3840KB 960.0KB/s 00:04
root@TP-50:/tmp# scp ./test*.bin ro...@192.168.1.41:/tmp
ro...@192.168.1.41's password:
test1.bin 100% 3840KB 768.0KB/s 00:05
test2.bin 100% 3840KB 960.0KB/s 00:04
I then tried transferring the files from the laptop to the two devices
as follows:
The test set up is my laptop connected to the 842 via Ethernet, and
the 703 meshed.
tgillett@T43:~/tmp$ scp ./test*.bin ro...@192.168.1.50:/tmp
ro...@192.168.1.50's password:
test1.bin 100% 3840KB 1.9MB/s 00:02
test2.bin 100% 3840KB 1.9MB/s 00:02
tgillett@T43:~/tmp$ scp ./test*.bin ro...@192.168.1.41:/tmp
ro...@192.168.1.41's password:
test1.bin 100% 3840KB 1.3MB/s 00:03
test2.bin 100% 3840KB 1.3MB/s 00:03
So you can see that adding the mesh link reduces the speed from
1.9MB/s to 1.3MB/s
I then reversed the direction of transfer as follows:
root@TP-50:/tmp# scp ./test*.bin tgil...@192.168.1.95:/home/tgillett/tmp
tgil...@192.168.1.95's password:
test1.bin 100% 3840KB 1.9MB/s 00:02
test2.bin 100% 3840KB 1.9MB/s 00:02
root@TP-41:/tmp# scp ./test*.bin tgil...@192.168.1.95:/home/tgillett/tmp
tgil...@192.168.1.95's password:
test1.bin 100% 3840KB 1.9MB/s 00:02
test2.bin 100% 3840KB 1.3MB/s 00:03
Again the mesh link doesn't seem to add a significant overhead to the
transfer rate.
The devices were in close proximity for these tests, and I also
repeated tests with the aerials from the 842 with no obvious change to
the speeds.
I then separated the units by 15 metres with two walls in between with
these results:
tgillett@T43:~/tmp$ scp ./test*.bin ro...@192.168.1.41:/tmp
ro...@192.168.1.41's password:
test1.bin 100% 3840KB 1.3MB/s 00:03
test2.bin 100% 3840KB 1.3MB/s 00:03
I used iw command to get some link stats for the mesh link between the
two devices when separated as follows:
root@TP-41:~# iw dev wlan0-1 station dump
Station fa:d1:11:b9:a4:81 (on wlan0-1)
inactive time: 10 ms
rx bytes: 26104742
rx packets: 26644
tx bytes: 1071214
tx packets: 10155
tx retries: 36085
tx failed: 4
signal: -56 [-56] dBm
signal avg: -58 [-58] dBm
tx bitrate: 57.8 MBit/s MCS 5 short GI
rx bitrate: 57.8 MBit/s MCS 5 short GI
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
Hope this helps.
regards
Terry
I did some tests transferring files between an 842 device (.50) and a
703 device (.41) with scp as follows:
root@TP-41:/tmp# scp ./test*.bin ro...@192.168.1.50:/tmp
ro...@192.168.1.50's password:
test1.bin 100% 3840KB 960.0KB/s 00:04
test2.bin 100% 3840KB 960.0KB/s 00:04
root@TP-50:/tmp# scp ./test*.bin ro...@192.168.1.41:/tmp
ro...@192.168.1.41's password:
test1.bin 100% 3840KB 768.0KB/s 00:05
test2.bin 100% 3840KB 960.0KB/s 00:04
I then tried transferring the files from the laptop to the two devices
as follows:
The test set up is my laptop connected to the 842 via Ethernet, and
the 703 meshed.
tgillett@T43:~/tmp$ scp ./test*.bin ro...@192.168.1.50:/tmp
ro...@192.168.1.50's password:
test1.bin 100% 3840KB 1.9MB/s 00:02
test2.bin 100% 3840KB 1.9MB/s 00:02
tgillett@T43:~/tmp$ scp ./test*.bin ro...@192.168.1.41:/tmp
ro...@192.168.1.41's password:
test1.bin 100% 3840KB 1.3MB/s 00:03
test2.bin 100% 3840KB 1.3MB/s 00:03
So you can see that adding the mesh link reduces the speed from
1.9MB/s to 1.3MB/s
I then reversed the direction of transfer as follows:
root@TP-50:/tmp# scp ./test*.bin tgil...@192.168.1.95:/home/tgillett/tmp
tgil...@192.168.1.95's password:
test1.bin 100% 3840KB 1.9MB/s 00:02
test2.bin 100% 3840KB 1.9MB/s 00:02
root@TP-41:/tmp# scp ./test*.bin tgil...@192.168.1.95:/home/tgillett/tmp
tgil...@192.168.1.95's password:
test1.bin 100% 3840KB 1.9MB/s 00:02
test2.bin 100% 3840KB 1.3MB/s 00:03
Again the mesh link doesn't seem to add a significant overhead to the
transfer rate.
The devices were in close proximity for these tests, and I also
repeated tests with the aerials from the 842 with no obvious change to
the speeds.
I then separated the units by 15 metres with two walls in between with
these results:
tgillett@T43:~/tmp$ scp ./test*.bin ro...@192.168.1.41:/tmp
ro...@192.168.1.41's password:
test1.bin 100% 3840KB 1.3MB/s 00:03
test2.bin 100% 3840KB 1.3MB/s 00:03
I used iw command to get some link stats for the mesh link between the
two devices when separated as follows:
root@TP-41:~# iw dev wlan0-1 station dump
Station fa:d1:11:b9:a4:81 (on wlan0-1)
inactive time: 10 ms
rx bytes: 26104742
rx packets: 26644
tx bytes: 1071214
tx packets: 10155
tx retries: 36085
tx failed: 4
signal: -56 [-56] dBm
signal avg: -58 [-58] dBm
tx bitrate: 57.8 MBit/s MCS 5 short GI
rx bitrate: 57.8 MBit/s MCS 5 short GI
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
Hope this helps.
regards
Terry
Costas Gargerakis
May 15, 2012, 12:15:03 PM5/15/12
to village-...@googlegroups.com
Hi,
Nice tests, i'll try them tomorrow and post my results as well.
By the way, have you tried VIS with an 842 device?
Regards,
Costas
Nice tests, i'll try them tomorrow and post my results as well.
By the way, have you tried VIS with an 842 device?
Regards,
Costas
T Gillett
May 15, 2012, 4:27:24 PM5/15/12
to village-...@googlegroups.com
No I have not used Vis at all.
--
You received this message because you are subscribed to the Google Groups "village-telco-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/village-telco-dev/-/A4Js3XEsuv8J.
To post to this group, send email to village-...@googlegroups.com.
To unsubscribe from this group, send email to village-telco-...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages