A Broadband and ADSL forum. BroadbanterBanter

Welcome to BroadbanterBanter.

You are currently viewing as a guest which gives you limited access to view most discussions and other FREE features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today.

Go Back   Home » BroadbanterBanter forum » Newsgroup Discussions » uk.telecom.broadband (UK broadband)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

uk.telecom.broadband (UK broadband) (uk.telecom.broadband) Discussion of broadband services, technology and equipment as provided in the UK. Discussions of specific services based on ADSL, cable modems or other broadband technology are also on-topic. Advertising is not allowed.

Fix for Three fallback to Orange GPRS packet loss



 
 
Thread Tools Display Modes
  #1  
Old August 16th 09, 11:22 PM posted to uk.telecom.mobile,uk.telecom.broadband
Theo Markettos
external usenet poster
 
Posts: 539
Default 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
  #2  
Old August 17th 09, 04:53 PM posted to uk.telecom.mobile,uk.telecom.broadband
alexd
external usenet poster
 
Posts: 1,765
Default Fix for Three fallback to Orange GPRS packet loss

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) )
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


  #3  
Old August 17th 09, 10:37 PM posted to uk.telecom.mobile,uk.telecom.broadband
Dennis Ferguson
external usenet poster
 
Posts: 118
Default Fix for Three fallback to Orange GPRS packet loss

On 2009-08-16, Theo Markettos 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.

Dennis Ferguson
  #4  
Old August 17th 09, 10:55 PM posted to uk.telecom.mobile,uk.telecom.broadband
The Natural Philosopher
external usenet poster
 
Posts: 2,728
Default Fix for Three fallback to Orange GPRS packet loss

Dennis Ferguson wrote:
On 2009-08-16, Theo Markettos 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

  #5  
Old August 18th 09, 12:30 AM posted to uk.telecom.mobile,uk.telecom.broadband
Theo Markettos
external usenet poster
 
Posts: 539
Default Fix for Three fallback to Orange GPRS packet loss

In uk.telecom.mobile Dennis Ferguson 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
  #6  
Old August 18th 09, 01:29 AM posted to uk.telecom.mobile,uk.telecom.broadband
The Natural Philosopher
external usenet poster
 
Posts: 2,728
Default Fix for Three fallback to Orange GPRS packet loss

Theo Markettos wrote:
In uk.telecom.mobile Dennis Ferguson 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.
  #7  
Old August 18th 09, 11:48 AM posted to uk.telecom.mobile,uk.telecom.broadband
bod43
external usenet poster
 
Posts: 105
Default Fix for Three fallback to Orange GPRS packet loss

On 18 Aug, 00:29, The Natural Philosopher
wrote:
Theo Markettos wrote:
In uk.telecom.mobile Dennis Ferguson 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.

  #8  
Old August 18th 09, 10:13 PM posted to uk.telecom.mobile,uk.telecom.broadband
Alex Fraser
external usenet poster
 
Posts: 553
Default Fix for Three fallback to Orange GPRS packet loss

bod43 wrote:
On 18 Aug, 00:29, The Natural Philosopher
wrote:

[snip]
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
 




Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
be packet loss eps uk.telecom.broadband (UK broadband) 1 May 14th 09 02:57 PM
Packet loss with AOL Ian Pollard uk.telecom.broadband (UK broadband) 3 January 20th 07 03:14 PM
NTL & Skype & packet loss. [email protected] uk.telecom.voip (UK VOIP) 8 October 30th 06 10:45 PM
Belkin Pre-N and Packet Loss Pyyrus uk.comp.home-networking (UK home networking) 1 December 17th 05 06:22 AM
Packet loss - 2 weeks now - is it just BT? [email protected] uk.telecom.broadband (UK broadband) 12 October 8th 05 11:39 AM


All times are GMT +1. The time now is 04:48 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.Content Relevant URLs by vBSEO 2.4.0
Copyright 2004-2019 BroadbanterBanter.
The comments are property of their posters.