Fix for Three fallback to Orange GPRS packet loss
Theo Markettos
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.telecom.mobile/browse_thread/thread/c0964cc5341f6681
(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
alexd
> 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) (UnSoEs...@ale.cx)
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
> 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.
Dennis Ferguson
The Natural Philosopher
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
Theo Markettos
> 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
The Natural Philosopher
> In uk.telecom.mobile Dennis Ferguson <dcfer...@pacbell.net> 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.
bod43
wrote:
> Theo Markettos wrote:
With TCP - used by ssh, http, https, nearly all internet
traffic - the TCP MSS (max segment size) is negotiated
at the start of each session. The two end stations each
send a message offering their max and the lowest is selected.
In the case under discussion the "sudo ifconfig ppp0 mtu 100"
command will result in the end station offering a TCP MSS
of around 50 bytes.
100 - PPP_header - IP_header - TCP_header
PPP_header is small - i have assumed 10 bytes
in the above example but I think its less. Oh, maybe
checksum/CRC too?
IP_header is 20 bytes (from memory)
TCP_header also 20 bytes (from memory)
All in all a fine sounding idea.
Alternatively -
There is another factor to be aware of.
I do not know properly how the encoding works on
any of GPRS, 3G or ADSL however my present
model is that the greater bandwidth of ADSL
over a 56k modem was achieved partly by the use
of a fiendishly complex signalling process that
spreads the data out in time. A result of this is
that the minimum ping RTT for ADSL is some
10s of milliseconds. If you use modem or ISDN
or a leased line the minimum ping time is simply the
time expected to send the bits at whatever data rate
is in use. There is some additional overhead with ADSL.
A few years ago I observed that
with 3G/GPRS the ping time was either 300ms or 600ms.
I actually called vodafone and demanded to know
what they were doing with my packets to hold them up.
I got no significant response. :-)
I eventually guessed that the long and varying RTT
must be due to the encoding scheme in use and
there being a switch to a more spread-out encoding
scheme at times of poor signal strength.
So the bottom line is - is there a minimum packet
size for the encoding used by 3G/GPRS and if so
what is it?
I have bundled 3G and GPRS together here, I do not
know if they both use the same encoding scheme or not.
Alex Fraser
> On 18 Aug, 00:29, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> 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.
This is complete nonsense, a CRC provides error detection not
correction. They can be designed to guarantee the dectection of a small
number of bit (not byte) errors - often one or two - given a maximum
block length.
However, if (say) there's a given probability of a byte being corrupted,
and any corrupted bytes mean the entire packet is lost, you will have
greater loss with larger packets.
> With TCP - used by ssh, http, https, nearly all internet
> traffic - the TCP MSS (max segment size) is negotiated
> at the start of each session. The two end stations each
> send a message offering their max and the lowest is selected.
> In the case under discussion the "sudo ifconfig ppp0 mtu 100"
> command will result in the end station offering a TCP MSS
> of around 50 bytes.
>
> 100 - PPP_header - IP_header - TCP_header
MTU is an IP thing; the PPP header is on top of it.
[snip]
> I do not know properly how the encoding works on
> any of GPRS, 3G or ADSL however my present
> model is that the greater bandwidth of ADSL
> over a 56k modem was achieved partly by the use
> of a fiendishly complex signalling process that
> spreads the data out in time. A result of this is
> that the minimum ping RTT for ADSL is some
> 10s of milliseconds.
The main reason for the greater bitrate of ADSL is that it uses ~1MHz
bandwidth, compared to the ~3kHz of a high speed dial-up modem. But
there are two main things I know of that help it achieve the best
possible bitrate after deciding how to allocate bits to carriers:
- Forward error correction (FEC): some bits carry redundant information
that allow a certain number of bit errors to be corrected without
requesting retransmission (which actually only happens at the TCP level
in the case of ADSL).
- Interleaving: this spreads the bits out in time, so that a short burst
of noise will damage lots of independently correctable data blocks by a
small amount, hopefully allowing them /all/ to be corrected by the FEC.
There is a direct relationship between the interleave depth and RTT as
you've suggested. However, interleaving is not necessarily used at all:
I don't have it and at quiet times I can get a ping of around 8ms on
8Mbit ADSL. Bear in mind the ping you can measure is not just the time
to the exchange and back but also to my ISP and back through BT's network.
[snip]
> So the bottom line is - is there a minimum packet
> size for the encoding used by 3G/GPRS and if so
> what is it?
That I don't know, although I suspect the encoding is different. It
seems likely that there will be more efficient sizes like there are with
ADSL due to fragmentation into ATM cells. If so, this should be apparent
as a sudden drop in throughput as you step up the MTU from a small number.
Alex