search

tegola-hubs / tegola

Tegola, Loch Hourn
1 stars 0 forks source link

Slow speeds at Corran #4

Open wwaites opened 11 years ago

wwaites commented 11 years ago

Investigate...

wwaites commented 11 years ago

Testing from corran-ap (10.11.13.1)

Traceroute inwards:

traceroute to 10.11.13.1 (10.11.13.1), 30 hops max, 40 byte packets
 1  172.31.0.1 (172.31.0.1)  22.588 ms  25.422 ms  22.083 ms
 2  tegola-gw.smo.uhi.ac.uk (194.35.194.252)  22.892 ms  22.944 ms  23.596 ms
 3  wlan0.smo.mhialairigh.tegola (10.11.0.50)  25.656 ms  24.285 ms  27.146 ms
 4  eth0.corran.mhialairigh.tegola (10.11.12.18)  24.056 ms  28.583 ms  24.998 ms
 5  wlan0.mhialairigh.corran.tegola (10.1.0.58)  26.488 ms  28.132 ms  25.620 ms
 6  wlan0.ap.corran.tegola (10.11.13.1)  25.650 ms  26.254 ms  33.225 ms

Traceroute outwards:

traceroute to 128.100.100.1 (128.100.100.1), 30 hops max, 38 byte packets
 1  eth0.sgritheall.corran.tegola (10.4.0.4)  0.451 ms  0.312 ms  0.292 ms
 2  wlan0.corran.sgritheall.tegola (10.1.0.61)  1.389 ms  3.298 ms  2.559 ms
 3  eth0.smo.sgritheall.tegola (10.11.12.1)  3.458 ms  1.368 ms  5.043 ms
 4  vlan106.smo-core-1.tegola (10.11.0.49)  3.107 ms  3.928 ms  3.325 ms
 5  smo-gw.uhi.ac.uk (194.35.194.1)  5.997 ms  4.218 ms  2.912 ms
  ...

So asymmetry at the moment. Inbound path via mhialairigh, outbound via sgritheall.

wwaites commented 11 years ago

Make it symmetric. Change the cost on the corran-sgritheall link (both directions)

In quagga, via vtysh:

!
interface wlan0
  ip ospf cost 20
!

default cost is 10.

Now we have:

traceroute to 128.100.100.1 (128.100.100.1), 30 hops max, 38 byte packets
 1  eth0.mhialairigh.corran.tegola (10.4.0.3)  0.561 ms  0.390 ms  0.242 ms
 2  wlan0.corran.mhialairigh.tegola (10.1.0.57)  1.493 ms  1.275 ms  1.241 ms
 3  eth0.smo.mhialairigh.tegola (10.11.12.17)  1.714 ms  1.509 ms  1.393 ms
 4  vlan106.smo-core-1.tegola (10.11.0.49)  2.772 ms  3.960 ms  2.982 ms
 5  smo-gw.uhi.ac.uk (194.35.194.1)  4.091 ms  4.911 ms  3.796 ms
 ...
wwaites commented 11 years ago

Looking at the sgritheall-corran link now, that is not carrying traffic.

Using iperf. Recall "iperf -c a.b.c.d" is source of traffic and "iperf -s" is sink.

Sending from 10.1.0.61 (sgritheall) to 10.11.13.1 (corran ap)

[  4]  0.0-14.6 sec   512 KBytes   287 Kbits/sec

Sending in the reverse direction

[  3]  0.0-10.1 sec  17.0 MBytes  14.2 Mbits/sec

Something definitely amiss, and I suspect that even the 14.2Mbps is being slowed down by the sluggish return path for the acknowledgement packets since this is using the default, TCP mode of iperf.

wwaites commented 11 years ago

Performing the same test between the radios at corran (10.1.0.62) and sgritheall (10.1.0.61) I get numbers more as expected:

inbound:

[  3]  0.0-10.0 sec  54.9 MBytes  45.9 Mbits/sec

outbound:

[  4]  0.0-10.1 sec  38.5 MBytes  32.1 Mbits/sec

It would appear that the problem is not the radio link.

wwaites commented 11 years ago

Similar tests, just over the corran lan from either the radios facing sgritheall or mhialiairgh to the access point, iperf appears to hang, or else transfers data extremely slowly.

Heavy handed approach: reboot the corran access point.

wwaites commented 11 years ago

The behaviour persists.

Furthermore, iperf between the radios facing sgritheall and mhialairigh at corran, i.e. not involving the access point, just over the switch, exhibits the same behaviour.

Suspect the switch is unhappy. Or wet. Or wet and unhappy.

Buneman commented 11 years ago

I have a strong suspicion that the switch may be at fault. Some time ago I tried to rationalise everything by plugging stuff into the switch but things didn't work properly, even after trying replacement cables etc. so I put things back the way they were. It was a horizontal rain situation, so I didn't spend a lot of time on it.

I'll go up this pm or tomorrow am armed with a new switch.

Peter

On Fri, 22 Feb 2013 03:33:14 -0800, wwaites notifications@github.com wrote:

The behaviour persists.

Furthermore, iperf between the radios facing sgritheall and mhialairigh at corran, i.e. not involving the access point, just over the switch, exhibits the same behaviour.

Suspect the switch is unhappy. Or wet. Or wet and unhappy.

Reply to this email directly or view it on GitHub: https://github.com/tegola-hubs/tegola/issues/4#issuecomment-13939251

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

Buneman commented 11 years ago

I found in my workshop one of those nice ubiquiti 5-port PoE switches with something illegible about Corran scribbled on the box. However the switch itself appears to be unopened. It's currently sitting on the LAN connected to my nanostation 10.11.11.2 with the default address 192.168.1.20

Is it enough to turn on POE on, say, 4 interfaces? I propose to plug all the ubiquiti kit into it (over POE), but I'm not sure if I should also use POE to drive the old experimental board.

Will check back in in an hour or two. More leg-turning

Peter On Fri, 22 Feb 2013 03:33:14 -0800, wwaites notifications@github.com wrote:

The behaviour persists.

Furthermore, iperf between the radios facing sgritheall and mhialairigh at corran, i.e. not involving the access point, just over the switch, exhibits the same behaviour.

Suspect the switch is unhappy. Or wet. Or wet and unhappy.

Reply to this email directly or view it on GitHub: https://github.com/tegola-hubs/tegola/issues/4#issuecomment-13939251

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

wwaites commented 11 years ago

I wouldn't put 24V PoE into the old experimental board. So long as everything's reachable, I should be able to connect to it at its default address, or it could be given 10.4.0.6.

Buneman commented 11 years ago

Thanks. I checked the gateworks boards. They accept 7-48V, but if you think it would be a good idea to have that on a separate power supply, I'll leave it that way.

or it could be given 10.4.0.6

Done.

I'll try to put it in tomorrow morning. Any time good for you in case of problems?

Peter

On Fri, 22 Feb 2013 14:05:33 -0800, wwaites notifications@github.com wrote:

I wouldn't put 24V PoE into the old experimental board. So long as everything's reachable, I should be able to connect to it at its default address, or it could be given 10.4.0.6.

Reply to this email directly or view it on GitHub: https://github.com/tegola-hubs/tegola/issues/4#issuecomment-13973692

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

wwaites commented 11 years ago

That's good. Many of these boards use a standard voltage regulator that takes 7-25V and tends to get very hot near the top end of that range. But what I was more concerned about is that they use the same wiring convention. I'm never sure about these non-standard PoE things.

Buneman commented 11 years ago

OK. Off up the hill now. I'll leave the board on a separate supply for the time being.

Peter On Sat, 23 Feb 2013 01:38:47 -0800, wwaites notifications@github.com wrote:

That's good. Many of these boards use a standard voltage regulator that takes 7-25V and tends to get very hot near the top end of that range. But what I was more concerned about is that they use the same wiring convention. I'm never sure about these non-standard PoE things.

Reply to this email directly or view it on GitHub: https://github.com/tegola-hubs/tegola/issues/4#issuecomment-13987599

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

Buneman commented 11 years ago

New switch has gone in. Iperf from it to the college shows 21Mb/s Finlay also reports improved performance. He'll check it out later. Off to breathe sawdust

Peter

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.