Got something else to discuss that is not covered by the previous forums? Post it here!
#65402 by dullgeek
Fri Sep 24, 2010 5:18 am
I've discovered a new problem. Previously I had posted a question about really long ping times. This problem is different than that problem in that this one is repeatable.

Here's my setup:

cable modem <-> ooma <-> router <-> server (connected via cat5e)

I am pinging google from my server. And here's what happens to my ping times whenever I make a phone call. Is there any way to prevent the phone call from completely dominating all internet bandwidth? I don't mind it having priority but I've got plenty of bandwidth available. It shouldn't downgrade the rest so dramatically.

$ ping http://www.google.com
PING http://www.l.google.com (66.102.7.99) 56(84) bytes of data.
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=1 ttl=52 time=98.6 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=2 ttl=52 time=97.3 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=3 ttl=52 time=99.5 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=4 ttl=52 time=95.7 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=5 ttl=52 time=94.4 ms

Pick up phone. Dial tone. Dial Number

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=6 ttl=52 time=508 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=7 ttl=52 time=559 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=8 ttl=52 time=693 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=9 ttl=52 time=731 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=10 ttl=52 time=768 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=11 ttl=52 time=863 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=12 ttl=52 time=1098 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=13 ttl=52 time=985 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=14 ttl=52 time=830 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=15 ttl=52 time=339 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=16 ttl=52 time=490 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=17 ttl=52 time=825 ms

Ring

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=18 ttl=52 time=789 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=19 ttl=52 time=1035 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=20 ttl=52 time=1436 ms

Pause between ring

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=21 ttl=52 time=1169 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=22 ttl=52 time=519 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=23 ttl=52 time=457 ms

Ring

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=24 ttl=52 time=1098 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=25 ttl=52 time=1616 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=26 ttl=52 time=1329 ms

Pause between ring

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=28 ttl=52 time=1336 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=29 ttl=52 time=992 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=30 ttl=52 time=671 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=31 ttl=52 time=409 ms

Ring

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=32 ttl=52 time=2381 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=33 ttl=52 time=1440 ms

Pause between ring

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=34 ttl=52 time=560 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=35 ttl=52 time=574 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=36 ttl=52 time=959 ms

Answer. Listen to answering machine talk

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=37 ttl=52 time=1140 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=38 ttl=52 time=1231 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=39 ttl=52 time=1711 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=40 ttl=52 time=1465 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=41 ttl=52 time=1685 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=42 ttl=52 time=1565 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=43 ttl=52 time=860 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=44 ttl=52 time=924 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=45 ttl=52 time=1424 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=46 ttl=52 time=1517 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=47 ttl=52 time=1623 ms

Hang up

64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=48 ttl=52 time=963 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=49 ttl=52 time=557 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=50 ttl=52 time=238 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=51 ttl=52 time=93.4 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=52 ttl=52 time=94.8 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=53 ttl=52 time=97.1 ms
64 bytes from lax04s01-in-f99.1e100.net (66.102.7.99): icmp_seq=54 ttl=52 time=91.4 ms
^C
--- http://www.l.google.com ping statistics ---
54 packets transmitted, 53 received, 1% packet loss, time 53157ms
rtt min/avg/max/mdev = 91.474/853.708/2381.901/535.974 ms, pipe 3
#65405 by murphy
Fri Sep 24, 2010 6:13 am
If you have "plenty of bandwith", disable the QOS function in Ooma (set both values to 0) and rerun your test.
#65414 by dullgeek
Fri Sep 24, 2010 7:45 am
But I want the QoS. I just don't think the QoS reserving a small amount of bandwidth should cause this much latency in all other traffic.

My solution was to swap the positions of ooma and the router, and use the router's QoS features. I'm running a WRT54G w/Tomato+Victec firmware. It's QoS seems to be pretty decent.

Who is online

Users browsing this forum: No registered users and 14 guests