Extremely poor 3 Mobile Broadband performance.
smb856
Posts: 40 Forum Member
✭
Hello,
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.
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