Network flakyness in buckingham?

[robert@…]

Hello,

I'm sitting in the back corner of the room. When joining ietf-a I see:

kistel@RobertAir:~$ ping kadarka
PING kadarka (85.10.198.82): 56 data bytes
64 bytes from 85.10.198.82: icmp_seq=0 ttl=54 time=153.909 ms
64 bytes from 85.10.198.82: icmp_seq=1 ttl=54 time=159.405 ms
64 bytes from 85.10.198.82: icmp_seq=2 ttl=54 time=97.130 ms
64 bytes from 85.10.198.82: icmp_seq=3 ttl=54 time=219.586 ms
64 bytes from 85.10.198.82: icmp_seq=4 ttl=54 time=167.830 ms
Request timeout for icmp_seq 5
64 bytes from 85.10.198.82: icmp_seq=6 ttl=54 time=86.900 ms
64 bytes from 85.10.198.82: icmp_seq=7 ttl=54 time=113.720 ms
Request timeout for icmp_seq 8
64 bytes from 85.10.198.82: icmp_seq=9 ttl=54 time=63.952 ms
64 bytes from 85.10.198.82: icmp_seq=10 ttl=54 time=44.816 ms
Request timeout for icmp_seq 11
64 bytes from 85.10.198.82: icmp_seq=12 ttl=54 time=65.718 ms
Request timeout for icmp_seq 13
64 bytes from 85.10.198.82: icmp_seq=14 ttl=54 time=104.946 ms
64 bytes from 85.10.198.82: icmp_seq=15 ttl=54 time=77.118 ms
64 bytes from 85.10.198.82: icmp_seq=16 ttl=54 time=132.206 ms
64 bytes from 85.10.198.82: icmp_seq=17 ttl=54 time=61.168 ms
64 bytes from 85.10.198.82: icmp_seq=18 ttl=54 time=38.962 ms
64 bytes from 85.10.198.82: icmp_seq=19 ttl=54 time=105.556 ms
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
64 bytes from 85.10.198.82: icmp_seq=22 ttl=54 time=104.052 ms
64 bytes from 85.10.198.82: icmp_seq=23 ttl=54 time=81.718 ms
^C
--- kadarka ping statistics ---
24 packets transmitted, 18 packets received, 25.0% packet loss
round-trip min/avg/max/stddev = 38.962/104.372/219.586/45.996 ms

When joining ietf, I see:


kistel@RobertAir:~$ ping kadarka
PING kadarka (85.10.198.82): 56 data bytes
64 bytes from 85.10.198.82: icmp_seq=0 ttl=54 time=35.931 ms
64 bytes from 85.10.198.82: icmp_seq=1 ttl=54 time=17.814 ms
64 bytes from 85.10.198.82: icmp_seq=2 ttl=54 time=22.425 ms
64 bytes from 85.10.198.82: icmp_seq=3 ttl=54 time=18.513 ms
64 bytes from 85.10.198.82: icmp_seq=4 ttl=54 time=22.593 ms
64 bytes from 85.10.198.82: icmp_seq=5 ttl=54 time=17.869 ms
64 bytes from 85.10.198.82: icmp_seq=6 ttl=54 time=26.069 ms
64 bytes from 85.10.198.82: icmp_seq=7 ttl=54 time=21.362 ms
^C
--- kadarka ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.814/22.822/35.931/5.623 ms


(destination is in Germany, ~20ms is not bad.)

I'm using a Mac Air, OSX 10.9.2, ifconfig at the moment is:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 84:38:35:4c:60:0e
	inet6 fe80::8638:35ff:fe4c:600e%en0 prefixlen 64 scopeid 0x4
	inet 31.133.166.198 netmask 0xfffff800 broadcast 31.133.167.255
	inet6 2001:67c:370:160:8638:35ff:fe4c:600e prefixlen 64 autoconf
	inet6 2001:67c:370:160:c927:9f5a:3c69:ec55 prefixlen 64 autoconf temporary
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active


Regards,
Robert

[cdoyle@…]

The meetings in Plaza C and Buckingham have far more attendees in them they we were prepared to support. We'll be deploying 3 additional WAP's in these rooms during the first break which should mitigate the issues you are having.

Apologies and thank you for your patience.

[anonymous]

We've augmented the number of APs and adjusted the power and believe that the rooms on -3 now should have decent IETF wifi. If you're going to be down there soon and can confirm this for us, please do so. If you're not expecting to be down there anytime soon, let us know and we'll close out this ticket.

Thanks!

• Jim

[robert@…]

> Comment (by anonymous):
> 
>  We've augmented the number of APs and adjusted the power and believe that
>  the rooms on -3 now should have decent IETF wifi. If you're going to be
>  down there soon and can confirm this for us, please do so. If you're not
>  expecting to be down there anytime soon, let us know and we'll close out
>  this ticket.
> 
>     Thanks!
> 
>     - Jim

Hi,

I don't plan to go back there for a while, so I'll not be able to check/confirm.

Regards,
Robert

[jim@…]

Ok, thanks ... we've sent folks down to test, and it's been good, so we'll close out this ticket.

Thanks for letting us know!

• JIm

[Rick Alfvin]

Milestone renamed