[April 2006] Current 3G problems - Feedback Please

[snap]

@softdev it didnt fix my problems in cpt - I still have to use the stay alive ping

@pitbull from a users perspective (thats me) the problems are not with HSDPA but around the time of the launch something happened that affects certain groups of users of both HSDPA & existing 3G

 

[internaut]

Im still having the prob after last night's CT's fix.

 

[vodacom3g]

Have any of you tried a GPRS-only profile?

 

[snap]

Yes ever since this problem occured a GPRS only profile stays up for much longer in Langebaan but is VERY slow here.

In the southern suburbs it gets the same downlink problem.

Havent tried it since the patch is that what you are asking us to do?

 

[vodacom3g]

Whatever the patch fixed, this problem obviously is not one of them.

Here's what I'm seeing:

On 3G / HSDPA, if I don't have any data in the downlink for a few minutes, the link goes to 'sleep'. By sending data up the link it wakes the link up again. However, the time to wake up is about 30s AND the amount of data used to 'wake' it up is important. So, I send a "ping -t -l 1000" to a server. After 30s of this I normally get a response, sometimes it can take 120s, but mostly 30s.

On GPRS, I see the same, but the time to wake up seems never more than 30s.

I never disconnect and reconnect to get the link active again, but wait it out and it comes back.

Like to hear your feedback on similar tests.

We're confident this (consistently) affect a specific number of users and is not widespread. Seems to be less than 1%. But those users (like snap) can reproduce the symptoms at will. The guys are working hard at determining why only those users are affected.

 

[bruceahibbert]

Pleased with HSDPA

V3G,

082-56

Bruce

 

[vodacom3g]

Thanks Bruce,

Could you do some of the tests as describes above and let me know the results.

Basically:

1) Connect to the network and do some stuff to make sure it works.
2) Stop all activity for 5 minutes.
3) Do a ping -t and see how quickly you get a response.

Also, is it a 64K or 32K SIM?

 

[internaut]

On 3G / HSDPA, if I don't have any data in the downlink for a few minutes, the link goes to 'sleep'. By sending data up the link it wakes the link up again. However, the time to wake up is about 30s AND the amount of data used to 'wake' it up is important. So, I send a "ping -t -l 1000" to a server. After 30s of this I normally get a response, sometimes it can take 120s, but mostly 30s.

I waited well over two minutes with wake-up routine but nada.
Disconnect, connect, Joy!

 

[bruceahibbert]

Tests

V3G,
You'll have to wait I'm afraid - I'm in dispute with 082155 about my contract at the moment and Vodacom is charging me R2/meg.

I've done a 300Mb download this month with HSDPA and everything worked perfectly.

I'm using a 64K sim.

Apart from the ping what other tests would you like me to do?

PM me and I'll do them as soon as para 1 is resolved.

Bruce

 

[internaut]

Using a GPRS-only Profile at the moment...all Ok after 25 minutes with a couple of 5 minute inactive intervals...Pharkit! I forgot how slow a 56Kbps connection is...will do an immediate 3G-only profile after this.

 

[internaut]

3G connection went down within 5 minutes...and by the way, 5 minutes is not the benchmark, it's anything from 0 seconds to hours before the problem surfaces.

 

[bruceahibbert]

Correction to post 112

Mb should read MB!

Using Telkom test get speeds from 354 kb/s to just over 1.2 Mb/sec

 

[snap]

In Langebaan

Using 3G only cant get it to wake up - tried for over 5 mins with the ping

GPRS wakes up even by refreshing the browser - thats what makes GPRS seem so slow here coz refreshing a browser a couple of times wakes up the connection.

 

[zoot]

I'm in Cape Town too (Rondebosch).

So far (a few minutes) there was a "pause" in data transfer. The following ping history (to a google server) may be of use? However, the argument, to manually send data upstream to keep the connection "live", is moot, as any outbound connection is up-stream first, with a TCP SYN sent to the destination host.

$ while true; do ping -s 1 -c 1 216.239.37.99; sleep 18; done
PING 216.239.37.99 (216.239.37.99) 1(29) bytes of data.

--- 216.239.37.99 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

PING 216.239.37.99 (216.239.37.99) 1(29) bytes of data.
9 bytes from 216.239.37.99: icmp_seq=1 ttl=241

--- 216.239.37.99 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

PING 216.239.37.99 (216.239.37.99) 1(29) bytes of data.
9 bytes from 216.239.37.99: icmp_seq=1 ttl=241

It's obvious from this ping history that the first packet disappeared into the ether. However, the link appeared to return.

Data transfer on my link has already stopped twice, but does eventually return after a while - this seems to take a minute or two.

I'll post updates while connected.

I will be in Jo'burg from this evening for a few days, so will be able to report back on any possible changes in the behaviour of my connection, if any.

Hmmm... the following (on a 2.6 Kernel based GNU/Linux system) seems to wake-up the link:

ping -s 1000 -c 1 -t 255 216.239.37.99
PING 216.239.37.99 (216.239.37.99) 1000(1028) bytes of data.

--- 216.239.37.99 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

ping -s 1000 -c 1 -t 255 216.239.37.99
PING 216.239.37.99 (216.239.37.99) 1000(1028) bytes of data.

--- 216.239.37.99 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Note: there were no responses, but then, on attempting to browse the web, data transfer returned.

 

[internaut]

Kewl zoot!

 

[zoot]

Hmmm... the following (on a 2.6 Kernel based GNU/Linux system) seems to wake-up the link:

ping -s 1000 -c 1 -t 255 216.239.37.99
PING 216.239.37.99 (216.239.37.99) 1000(1028) bytes of data.[/QUOTE]

Sometimes several of these pings are required to wake-up the link. The most recent event required 5 such pings! Oh no... my link has degraded quite a bit now, requiring regular "wake-up" pings. Finally, I had to disconnect and reconnect! :mad: 

It really surprises me that this has not been resolved already!

I can sniff the link (using tcpdump) if such detailed data would help. vodacom3g, let me know.

 

[Big Kriss]

Hi all,New to the forum,found it accidently..great stuff..

Im ready to sell my putor and buy a quad..

Same stuff as above,Im in Benoni,Rynfield to be excact..

This is disturbing stuff for the mind.!

 

[vodacom3g]

I can sniff the link (using tcpdump) if such detailed data would help. vodacom3g, let me know.

Spent most of yesterday running traces with Siemens, so we've got a lot, but thanks for the offer.

What can help is the following:

1) Where are you based?
2) Do you have a 64K or 32K SIM?
3) What is your data card number?, first 5 digits, eg. 082-99
4) Do you get the above on 3G, GPRS or both.

 

[Big Kriss]

Rynfield,Benoni
64k
082 00700
3g,gprs.

This is frustating..

 

[3G4me]

Vodacom3G, if this is only affecting certain numbers, and is only affecting a small percentage of subscribers, will it help to perform cell number changes on most of these numbers where the clients have a data contract and don't really care about the cell number?

I know it doesn't solve the network problem, but since this is taking so long to resolve, I'm sure it would solve alot of frustrated client's problems (as long as it does the trick...)