Options
Extremely poor performance from 3 Mobile Broadband
smb856
Posts: 40 Forum Member
✭
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:
The pings are sent 4 seconds apart.
Other times, like just now, the following occurs instead:
The data traffic stops at the same time the pings stop so it's not the case that just the ICMP packets for the pings are being dropped. I've just tried using ping on the Android tablet as well and I am seeing the exact same delays as with the above pings from the Linux box.
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.
[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:
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
The pings are sent 4 seconds apart.
Other times, like just now, the following occurs instead:
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
The data traffic stops at the same time the pings stop so it's not the case that just the ICMP packets for the pings are being dropped. I've just tried using ping on the Android tablet as well and I am seeing the exact same delays as with the above pings from the Linux box.
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.
0
Comments
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.
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.
3 3G, tethering, central Reading, belting signal strength.
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)
moox, this is _exactly_ what happens to me. Thank you for confirming it's not just me.
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.
I'm in a town in Yorkshire, so I am nowhere near you.
That would seem to imply it's not just some local 3 hardware problem.
Unfortunately, quite often I am in the middle of a SSH session with either unsaved changes or in a middle of a sequence of commands so it's less painful to wait up to several minutes for the connection to resume than it is to reset the MiFi dongle and re-establish the SSH session.