Fix for Three fallback to Orange GPRS packet loss

I've posted here before about how Three's 3G network is moderately solid
when you're in range, but as soon as you drop down to 2G as outsourced to
Orange, connections start getting really slow, packets drop all over the
place and can take up to a minute to arrive:

http://groups.google.co.uk/group/uk....964cc5341f6681
(thread "Rubbish GPRS performance on "3"" from Dec 2008)

I've now found a workaround. After various ping tests, I found that the
proportion of packet loss depends on the packet size. So to minimise loss,
set the MTU to 100. Yes, one hundred. At that size there's barely anything
useful in a packet so it'll probably balloon your bandwidth bill (but you
can't use too much bandwidth at GPRS speeds anyway) but it does work. I'm
typing this in an SSH session which would never otherwise survive - it'd
keel over at the first screen full of text.

On Linux I discovered ('ifconfig ppp0') that the MTU defaults to 1500. Once
the connection was up I did:
$ sudo ifconfig ppp0 mtu 100
and successfully reduced the MTU and had a working network again. No doubt
Windows has a similar option.

Theo

Theo Markettos wrote:

> On Linux I discovered ('ifconfig ppp0') that the MTU defaults to 1500.
> Once the connection was up I did:
> $ sudo ifconfig ppp0 mtu 100
> and successfully reduced the MTU and had a working network again.

Have you tried other more likely [ie >100] MTU sizes? Surely Orange wouldn't
have their MTU configured that low deliberately?

--
<http://ale.cx/> (AIM:troffasky) ((E-Mail Removed))
15:52:07 up 103 days, 7:39, 3 users, load average: 0.15, 0.24, 0.21
"If being trapped in a tropical swamp with Anthony Worral-Thompson and
Christine Hamilton is reality then I say, pass the mind-altering drugs"
-- Humphrey Lyttleton

Dennis Ferguson wrote:
> On 2009-08-16, Theo Markettos <theom+(E-Mail Removed)> wrote:
>> can't use too much bandwidth at GPRS speeds anyway) but it does work. I'm
>> typing this in an SSH session which would never otherwise survive - it'd
>> keel over at the first screen full of text.
>>
>> On Linux I discovered ('ifconfig ppp0') that the MTU defaults to 1500. Once
>> the connection was up I did:
>> $ sudo ifconfig ppp0 mtu 100
>> and successfully reduced the MTU and had a working network again. No doubt
>> Windows has a similar option.
>
> Funny thing is that I don't think doing that has any effect on
> the size of the packets the network sends to you, only on the
> size of the packets you send to the network.
>

I think it does affect things two ways..

The PPP spec I THINK allows one end to specify a max which the other
will honour, they packet size being the lesser of the two specified.


> Dennis Ferguson

In uk.telecom.mobile Dennis Ferguson <(E-Mail Removed)> wrote:
> Funny thing is that I don't think doing that has any effect on
> the size of the packets the network sends to you, only on the
> size of the packets you send to the network.

Experimentation suggests it does. I had a 'screen' session on my SSH
server. I could successfully login (lots of small packets going back and
forth) and type commands fine. But when I would open the screen session,
which involves sending an entire screenful of text, the connection would
invariably lock up, but in slightly different places each time. On a
non-GSM connection the same experiment works fine (and I do exactly the same
at least once every day).

When I dropped the MTU it started behaving itself and didn't lock up at all.
Therefore my supposition is that the screenful of text is being fragmented
into small packets, and so isn't being 'taken out' by a glitch (bit error,
truncation) which is more likely to torpedo a long packet.

I've had very variable, probabilistic (ie 1 chance in 10 it'll work, reload
enough times and it might) problems when browsing with Three-on-Orange-GPRS
all over the place (not just the one cell I happen to be in at the moment),
so that would suggest it's the same problem nationwide. And I'm using a
HSDPA netbook now against a Nokia N70's phone browser before, so it's not my
hardware at fault.

Theo

Theo Markettos wrote:
> In uk.telecom.mobile Dennis Ferguson <(E-Mail Removed)> wrote:
>> Funny thing is that I don't think doing that has any effect on
>> the size of the packets the network sends to you, only on the
>> size of the packets you send to the network.
>
> Experimentation suggests it does.

http://www.faqs.org/rfcs/rfc1661.html

It looks like YOU send a packet saying how large a packet YOU can
receive and the other end sends a packet saying how large YOU may transmit.

I don't see why you couldn't transmit less..
And you often will, in the case e.g. of a single keypress..

I do remember in the early and very congested days of the Internet, we
would try pings with various packet sizes. With extreme packet loss,
small packets would get through, large packets almost never.

Its easy to see why. If for example you lose/corrupt every tenth byte,
more than twenty bytes will have tow corrupted bytes ..beyond CRC recovery.

Not sure how cellphones do transmission, but if its spread spectrum,
corruption goes up the more (active ONLINE) phones are around.