|
||||||||
Extremely poor performance from 3 Mobile Broadband |
![]() |
|
|
Thread Tools | Search this Thread |
|
|
#1 |
|
Forum Member
Join Date: May 2008
Posts: 39
|
Extremely poor performance from 3 Mobile Broadband
Hello,
[I posted the following in Broadband a couple of days ago because it's a mobile broadband issue, however it was suggested I repost it here. This problem does seem to have improved a bit over the last couple of days, although I am still getting data pauses however.] Is anyone experiencing data flow pauses in their 3 MBB connections lasting up to several minutes during the day ? Using the same equipment and at the same location, I have no problem if using 3 at 2-3 AM in the morning. I am just doing normal web browsing and using a text only SSH connection only; there are no large file transfers (for example) or other large transfers of data in progress. I'm using a E5331 Mifi dongle to connect to 3 and I am using it with both a USB connection to a Linux PC and a Wifi connection to an Android tablet (although not usually at the same time). The signal strength indicator on the dongle remains green at all times and the connection to 3 continues but there's just no flow of traffic. When the lockup occurs while using the Linux PC, a test with the Android tablet also confirms the same lockup which ends at the same time the data starts flowing again on the Linux PC. I've noticed the pauses appear to be in mostly nice round numbers (for example almost exactly five minutes for some of them) which makes me wonder if 3 are cutting off data flows in order to control heavily congested networks. Is anyone else seeing this ? I've tried the local 3 store and they have been completely useless. Is there any point in complaining to 3's head office or am I likely to get the brush-off there as well ? Thanks for any hints. PS: Here's a ping session which occurred a few minutes ago: Code:
64 bytes from 4.2.2.2: icmp_seq=14 ttl=54 time=727 ms 64 bytes from 4.2.2.2: icmp_seq=15 ttl=54 time=221 ms 64 bytes from 4.2.2.2: icmp_seq=16 ttl=54 time=2477 ms 64 bytes from 4.2.2.2: icmp_seq=17 ttl=54 time=730 ms 64 bytes from 4.2.2.2: icmp_seq=18 ttl=54 time=302488 ms 64 bytes from 4.2.2.2: icmp_seq=19 ttl=54 time=298488 ms 64 bytes from 4.2.2.2: icmp_seq=20 ttl=54 time=294570 ms 64 bytes from 4.2.2.2: icmp_seq=21 ttl=54 time=290640 ms 64 bytes from 4.2.2.2: icmp_seq=22 ttl=54 time=286675 ms 64 bytes from 4.2.2.2: icmp_seq=23 ttl=54 time=282737 ms 64 bytes from 4.2.2.2: icmp_seq=24 ttl=54 time=278802 ms 64 bytes from 4.2.2.2: icmp_seq=25 ttl=54 time=274822 ms 64 bytes from 4.2.2.2: icmp_seq=26 ttl=54 time=270864 ms 64 bytes from 4.2.2.2: icmp_seq=27 ttl=54 time=266983 ms 64 bytes from 4.2.2.2: icmp_seq=28 ttl=54 time=263006 ms 64 bytes from 4.2.2.2: icmp_seq=29 ttl=54 time=259125 ms 64 bytes from 4.2.2.2: icmp_seq=94 ttl=54 time=179 ms 64 bytes from 4.2.2.2: icmp_seq=95 ttl=54 time=120 ms 64 bytes from 4.2.2.2: icmp_seq=96 ttl=54 time=280 ms Other times, like just now, the following occurs instead: Code:
64 bytes from 4.2.2.2: icmp_seq=33 ttl=54 time=91.1 ms 64 bytes from 4.2.2.2: icmp_seq=35 ttl=54 time=6361 ms 64 bytes from 4.2.2.2: icmp_seq=37 ttl=54 time=112 ms 64 bytes from 4.2.2.2: icmp_seq=55 ttl=54 time=50807 ms 64 bytes from 4.2.2.2: icmp_seq=68 ttl=54 time=189 ms There's always been poor performance around here, even with a strong signal, but it's got really bad over the last few weeks. There's been no change in my equipment during that time and, as mentioned above, it works ok at about 3AM in the morning. |
|
|
|
|
Please sign in or register to remove this advertisement.
|
|
|
#2 |
|
Forum Member
Join Date: Mar 2009
Posts: 14,545
|
What is the actual signal level in dBm as bars or green indicators don't mean a lot. A good signal is 50-75dBm , average 75-95dBm and over 95dBm is poor. Some might debate these figures a bit, but I give them as a general guide. This app for Windows can tell you your real signal level and your signal to noise ratio, disconnect from 3 connect before opening the app, as the app allows you to connect and gives you signal statistics http://www.nerve.org.za/mdma/
If you post your RSSi (Received signal strength indication) and SNR (signal to noise ratio) it may give an idea of whether your problems might be signal strength or signal quality related. It is worth logging it with the network, but it might just be down to poor signal quality. Testing in different positions can help. |
|
|
|
|
|
#3 |
|
Forum Member
Join Date: May 2008
Posts: 39
|
Thanks for the suggestions.
I'm aware of the issues around what is and isn't a good signal strength, so I just used the green bar indicator as a way of indicating the dongle itself didn't think it was a poor signal. I couldn't run your application because I use Linux, but I manually converted the RSSI value to dBm and it's at the lower signal strength of your average range (approx -93dBm to -95dBm). It is very noticable however that the signal strength does not vary when data flow stops and I get comparable signal strength when getting excellent throughput (I've been monitoring this because I had the same exact idea). I think I'm going to try some experiments during the next few days to see what happens in different locations. |
|
|
|
|
|
#4 |
|
Forum Member
Join Date: Oct 2004
Posts: 14,641
|
I think I just experienced this: Quote:
PING 8.8.8.8 (8.8.8.8): 56 data bytes 3 3G, tethering, central Reading, belting signal strength.
Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 Request timeout for icmp_seq 5 Request timeout for icmp_seq 6 Request timeout for icmp_seq 7 Request timeout for icmp_seq 8 Request timeout for icmp_seq 9 Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 Request timeout for icmp_seq 12 Request timeout for icmp_seq 13 Request timeout for icmp_seq 14 Request timeout for icmp_seq 15 Request timeout for icmp_seq 16 Request timeout for icmp_seq 17 Request timeout for icmp_seq 18 Request timeout for icmp_seq 19 Request timeout for icmp_seq 20 Request timeout for icmp_seq 21 Request timeout for icmp_seq 22 Request timeout for icmp_seq 23 Request timeout for icmp_seq 24 Request timeout for icmp_seq 25 Request timeout for icmp_seq 26 Request timeout for icmp_seq 27 Request timeout for icmp_seq 28 Request timeout for icmp_seq 29 Request timeout for icmp_seq 30 Request timeout for icmp_seq 31 Request timeout for icmp_seq 32 Request timeout for icmp_seq 33 64 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=34241.377 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=33240.322 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=49 time=32240.543 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=49 time=31263.547 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=49 time=30269.920 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=49 time=29268.859 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=49 time=28268.768 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=49 time=27268.809 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=49 time=26268.323 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=49 time=25277.828 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=49 time=24277.697 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=49 time=23285.985 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=49 time=22285.876 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=49 time=21285.014 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=49 time=20284.002 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=49 time=19288.201 ms 64 bytes from 8.8.8.8: icmp_seq=16 ttl=49 time=18303.842 ms 64 bytes from 8.8.8.8: icmp_seq=17 ttl=49 time=17302.780 ms 64 bytes from 8.8.8.8: icmp_seq=18 ttl=49 time=16301.665 ms 64 bytes from 8.8.8.8: icmp_seq=19 ttl=49 time=15300.962 ms 64 bytes from 8.8.8.8: icmp_seq=20 ttl=49 time=14300.886 ms 64 bytes from 8.8.8.8: icmp_seq=21 ttl=49 time=13299.814 ms 64 bytes from 8.8.8.8: icmp_seq=22 ttl=49 time=12300.288 ms 64 bytes from 8.8.8.8: icmp_seq=23 ttl=49 time=11300.144 ms 64 bytes from 8.8.8.8: icmp_seq=24 ttl=49 time=10299.777 ms 64 bytes from 8.8.8.8: icmp_seq=25 ttl=49 time=9299.293 ms 64 bytes from 8.8.8.8: icmp_seq=26 ttl=49 time=8298.227 ms 64 bytes from 8.8.8.8: icmp_seq=27 ttl=49 time=7297.192 ms 64 bytes from 8.8.8.8: icmp_seq=28 ttl=49 time=6303.831 ms 64 bytes from 8.8.8.8: icmp_seq=29 ttl=49 time=5303.147 ms 64 bytes from 8.8.8.8: icmp_seq=30 ttl=49 time=4303.029 ms 64 bytes from 8.8.8.8: icmp_seq=31 ttl=49 time=3303.119 ms 64 bytes from 8.8.8.8: icmp_seq=32 ttl=49 time=2302.375 ms 64 bytes from 8.8.8.8: icmp_seq=33 ttl=49 time=1305.395 ms 64 bytes from 8.8.8.8: icmp_seq=34 ttl=49 time=319.052 ms 64 bytes from 8.8.8.8: icmp_seq=35 ttl=49 time=131.741 ms 64 bytes from 8.8.8.8: icmp_seq=36 ttl=49 time=112.338 ms |
|
|
|
|
|
#5 |
|
Forum Member
Join Date: Mar 2009
Posts: 14,545
|
ICMP packets do sometimes get treated with low priority in a busy network. I say this to Moox if you aren't experiencing any other issues with the speed of pages etc.
|
|
|
|
|
|
#6 |
|
Forum Member
Join Date: Oct 2004
Posts: 14,641
|
Quote:
ICMP packets do sometimes get treated with low priority in a busy network. I say this to Moox if you aren't experiencing any other issues with the speed of pages etc.
(and I'd be impressed if the network was busy enough to result in 30 second ICMP responses, I know you can deprioritise ICMP but not to that extent surely) |
|
|
|
|
|
#7 |
|
Forum Member
Join Date: May 2008
Posts: 39
|
Quote:
It was a total outage, nothing was working, that's why I tried to ping something. When it is working the performance isn't amazing but it never has been on 3G in Reading (can't seem to get 4G in this spot)
(and I'd be impressed if the network was busy enough to result in 30 second ICMP responses, I know you can deprioritise ICMP but not to that extent surely) ![]() Thine Wonk, I see exactly the same thing as moox. HTTP, DNS, SSH and ICMP packet flows all stop at the same time and all come back at the same time. In fact, if packets have been lost instead of buffered, then the ICMP packet flow can start up again several seconds before any existing TCP based connections because TCP has to go through it's normal packet loss recovery mechanisms. |
|
|
|
|
|
#8 |
|
Forum Member
Join Date: Oct 2004
Posts: 14,641
|
Where are you located when it appears to go down?
|
|
|
|
|
|
#9 |
|
Forum Member
Join Date: May 2008
Posts: 39
|
Quote:
Where are you located when it appears to go down?
That would seem to imply it's not just some local 3 hardware problem. |
|
|
|
|
|
#10 |
|
Forum Member
Join Date: Dec 2008
Location: East Midlands
Posts: 5,204
|
With the same mi-fi as the OP, I've had random outages on 3. But turning it on/off restores broadband internet access faster than waiting for the service to return on its own accord.
|
|
|
|
|
|
#11 |
|
Forum Member
Join Date: May 2008
Posts: 39
|
Quote:
With the same mi-fi as the OP, I've had random outages on 3. But turning it on/off restores broadband internet access faster than waiting for the service to return on its own accord.
|
|
|
|
![]() |
|
All times are GMT. The time now is 13:25.


