| View previous topic :: View next topic |
| Author |
Message |
The Natural Philosopher
Guest
|
 Posted: Wed Jul 09, 2008 6:46 pm Post subject: Re: Why isn't ADSL rate adaptive |
 |
|
alexd wrote:
| Quote: |
On Mon, 07 Jul 2008 17:22:10 +0000, Klunk wrote:
AFAIK ADSL does not use Ethernet - it uses point to point protocol over
ATM (or mostly in the UK it does). Not sure, but is that not layer 2?
That would mean there could be no packet loss as it is moving frames? My
guess would be that if you pack a frame with packets and it has to keep
resending the frame, throughput could be seriously hampered.
ATM uses 53-byte cells, of which 5 bytes is headers, hence the max
throughput on a line synced at 8128k being about 7100k. If there are any
errors detected in the cells, these cells are dropped which presumably
cause the upper-layer protocol [eg TCP] to re-transmit the entire packet.
I don't think its quite that simple actually, since what runs over ADSL |
is not ATM but either PPPOE over ATM over ADSL or possibly PPPOE over
ADSL. MM. That's probably not the case since my router has ATM stats.
The backhaul is ppp over ATM of some kind.
Ip runs over he top of ALL that. |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Klunk
Guest
|
| Posted: Wed Jul 09, 2008 7:12 pm Post subject: Re: Why isn't ADSL rate adaptive |
|
|
On Wed, 09 Jul 2008 14:46:33 +0100, The Natural Philosopher passed an
empty day by writing:
| Quote: |
alexd wrote:
On Mon, 07 Jul 2008 17:22:10 +0000, Klunk wrote:
AFAIK ADSL does not use Ethernet - it uses point to point protocol
over ATM (or mostly in the UK it does). Not sure, but is that not
layer 2? That would mean there could be no packet loss as it is moving
frames? My guess would be that if you pack a frame with packets and it
has to keep resending the frame, throughput could be seriously
hampered.
ATM uses 53-byte cells, of which 5 bytes is headers, hence the max
throughput on a line synced at 8128k being about 7100k. If there are
any errors detected in the cells, these cells are dropped which
presumably cause the upper-layer protocol [eg TCP] to re-transmit the
entire packet.
I don't think its quite that simple actually, since what runs over ADSL
is not ATM but either PPPOE over ATM over ADSL or possibly PPPOE over
ADSL. MM. That's probably not the case since my router has ATM stats.
The backhaul is ppp over ATM of some kind.
Ip runs over he top of ALL that.
|
I'm not totally clear on this either. I know the back haul BT network is
ATM - I imagine this is true of many telco's. My best guess is that DSLAM
to cloud is ATM but I'm not so sure about the DSLAM to subscriber. What
does seem to emerge from all of this is that even a small packet loss
seems to be an issue with throughput.
--
begin oefixed_in_2005.exe |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
The Natural Philosopher
Guest
|
| Posted: Wed Jul 09, 2008 10:56 pm Post subject: Re: Why isn't ADSL rate adaptive |
|
|
Klunk wrote:
| Quote: |
On Wed, 09 Jul 2008 14:46:33 +0100, The Natural Philosopher passed an
empty day by writing:
alexd wrote:
On Mon, 07 Jul 2008 17:22:10 +0000, Klunk wrote:
AFAIK ADSL does not use Ethernet - it uses point to point protocol
over ATM (or mostly in the UK it does). Not sure, but is that not
layer 2? That would mean there could be no packet loss as it is moving
frames? My guess would be that if you pack a frame with packets and it
has to keep resending the frame, throughput could be seriously
hampered.
ATM uses 53-byte cells, of which 5 bytes is headers, hence the max
throughput on a line synced at 8128k being about 7100k. If there are
any errors detected in the cells, these cells are dropped which
presumably cause the upper-layer protocol [eg TCP] to re-transmit the
entire packet.
I don't think its quite that simple actually, since what runs over ADSL
is not ATM but either PPPOE over ATM over ADSL or possibly PPPOE over
ADSL. MM. That's probably not the case since my router has ATM stats.
The backhaul is ppp over ATM of some kind.
Ip runs over he top of ALL that.
I'm not totally clear on this either. I know the back haul BT network is
ATM - I imagine this is true of many telco's. My best guess is that DSLAM
to cloud is ATM
|
That is certainly true.
| Quote: |
but I'm not so sure about the DSLAM to subscriber.
|
Me neither. And yet my router has ATM fdiagnostics built on, which
suhgests that its talking ATM as well as ADSL, and it also allows me to
select pppoe, so it must be talking that too.
What
| Quote: |
does seem to emerge from all of this is that even a small packet loss
seems to be an issue with throughput.
|
very much so. Wit high window sizes and reasonably long latencies you
get the best speed ..until an ack fails to arrive. At that point you
probably back off and sent the un-acked packet gain..and wait for the
ack before starting a new window.
You can trade raw speed for resilience in high packet loss situations by
dropping window and frame sizes. Chances are that a greater amount of
little packets will get through than big ones..been there done that on
the old days of very congested networks |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
alexd
Guest
|
| Posted: Wed Jul 09, 2008 11:04 pm Post subject: Re: Why isn't ADSL rate adaptive |
|
|
On Wed, 09 Jul 2008 14:12:30 +0000, Klunk wrote:
| Quote: |
I'm not so sure about the DSLAM to subscriber.
What does seem to emerge from all of this is that even a small packet
loss seems to be an issue with throughput.
|
DLSAM to subscriber is PPP over ATM over DSL [or PPP over Ethernet over
ATM over DSL] for BT. Be, for example, is Ethernet over ATM. Not having
any resellers to delegate authentication to, Be don't need the PPP bit.
--
<http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
18:30:53 up 7 days, 4:58, 3 users, load average: 0.04, 0.03, 0.00
Convergence, n: The act of using separate DSL circuits for voice and data |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Andy Furniss
Guest
|
| Posted: Tue Jul 15, 2008 12:51 am Post subject: Re: Why isn't ADSL rate adaptive |
|
|
ato_zee@hotmail.com wrote:
| Quote: |
They are really handy if you want to run a
packet tap on the traffic going into and coming out of another
computer, and that's useful to help figure out why some network
protocol is malfunctioning or how a computer is being attacked.
Plus getting a handle on the effect of errors and retransmissions.
|
Not the same as loss on a dsl line though, as ethernet stores and
resends the frame so the tcp layer never sees a loss.
Andy. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Andy Furniss
Guest
|
| Posted: Tue Jul 15, 2008 1:00 am Post subject: Re: Why isn't ADSL rate adaptive |
|
|
Peter Crosland wrote:
| Quote: |
The simple answer is that the BT adaptive system is poorly designed, poorly
implemented and based on an ultra-conservative model. Quite simply it not
fit for the purpose it is intended for but as BT has a de facto monopoly we
are stuck with it. AIUI when BT implement ADSL2+ it should improve.
|
1 meg step bras rates for sync > 8meg AIUI :-(
Andy. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
The Natural Philosopher
Guest
|
| Posted: Tue Jul 15, 2008 1:59 am Post subject: Re: Why isn't ADSL rate adaptive |
|
|
Andy Furniss wrote:
| Quote: |
ato_zee@hotmail.com wrote:
They are really handy if you want to run a
packet tap on the traffic going into and coming out of another
computer, and that's useful to help figure out why some network
protocol is malfunctioning or how a computer is being attacked.
Plus getting a handle on the effect of errors and retransmissions.
Not the same as loss on a dsl line though, as ethernet stores and
resends the frame so the tcp layer never sees a loss.
DSL does its own error correction and retransmision too..or something |
does...could be at the ATM level I guess.
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Andy Furniss
Guest
|
| Posted: Tue Jul 15, 2008 4:33 pm Post subject: Re: Why isn't ADSL rate adaptive |
|
|
The Natural Philosopher wrote:
| Quote: |
Andy Furniss wrote:
ato_zee@hotmail.com wrote:
They are really handy if you want to run a
packet tap on the traffic going into and coming out of another
computer, and that's useful to help figure out why some network
protocol is malfunctioning or how a computer is being attacked.
Plus getting a handle on the effect of errors and retransmissions.
Not the same as loss on a dsl line though, as ethernet stores and
resends the frame so the tcp layer never sees a loss.
DSL does its own error correction and retransmision too..or something
does...could be at the ATM level I guess.
|
Error correction yes, when interleaving is on, retransmission no, not at
any level below TCP.
TCP assumes loss means congestion and backs off so you really don't want
link level loss. DSl IIRC defines a 0db SNR margin as that giving a
BER of 1E-7.
There are TCPs with congestion control algorithms that rely less on loss
- you have some if you use linux, but they don't get used on internet
servers, they are more for wireless I think.
Andy. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
The Natural Philosopher
Guest
|
| Posted: Tue Jul 15, 2008 5:45 pm Post subject: Re: Why isn't ADSL rate adaptive |
|
|
Andy Furniss wrote:
| Quote: |
The Natural Philosopher wrote:
Andy Furniss wrote:
ato_zee@hotmail.com wrote:
They are really handy if you want to run a
packet tap on the traffic going into and coming out of another
computer, and that's useful to help figure out why some network
protocol is malfunctioning or how a computer is being attacked.
Plus getting a handle on the effect of errors and retransmissions.
Not the same as loss on a dsl line though, as ethernet stores and
resends the frame so the tcp layer never sees a loss.
DSL does its own error correction and retransmision too..or something
does...could be at the ATM level I guess.
Error correction yes, when interleaving is on, retransmission no, not at
any level below TCP.
|
I did the research, and it appears you are essentially correct. Well
nice to learn new stuff!
| Quote: |
TCP assumes loss means congestion and backs off so you really don't want
link level loss. DSl IIRC defines a 0db SNR margin as that giving a
BER of 1E-7.
There are TCPs with congestion control algorithms that rely less on loss
- you have some if you use linux, but they don't get used on internet
servers, they are more for wireless I think.
|
Most TCP implementations carry some awareness of congestion, but it
certainly helps t tune things up a bit.
Not sure what my bit error rate is, but I am getting as I type about one
CRC every 10k frames.
> Andy. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Klunk
Guest
|
| Posted: Wed Jul 16, 2008 10:21 am Post subject: Re: Why isn't ADSL rate adaptive |
|
|
On Tue, 15 Jul 2008 13:45:53 +0100, The Natural Philosopher passed an
empty day by writing:
| Quote: |
Andy Furniss wrote:
The Natural Philosopher wrote:
Andy Furniss wrote:
ato_zee@hotmail.com wrote:
They are really handy if you want to run a packet tap on the
traffic going into and coming out of another computer, and that's
useful to help figure out why some network protocol is
malfunctioning or how a computer is being attacked.
Plus getting a handle on the effect of errors and retransmissions.
Not the same as loss on a dsl line though, as ethernet stores and
resends the frame so the tcp layer never sees a loss.
DSL does its own error correction and retransmision too..or something
does...could be at the ATM level I guess.
Error correction yes, when interleaving is on, retransmission no, not
at any level below TCP.
I did the research, and it appears you are essentially correct. Well
nice to learn new stuff!
TCP assumes loss means congestion and backs off so you really don't
want
link level loss. DSl IIRC defines a 0db SNR margin as that giving a
BER of 1E-7.
There are TCPs with congestion control algorithms that rely less on
loss - you have some if you use linux, but they don't get used on
internet servers, they are more for wireless I think.
Most TCP implementations carry some awareness of congestion, but it
certainly helps t tune things up a bit.
Not sure what my bit error rate is, but I am getting as I type about one
CRC every 10k frames.
Andy.
|
But the key here still remains that if the link is iffy, there will be a
loss which can affect the throughput - so upping the speed of the link
does not necessarily mean a massive increase in throughput if you get a
frame full of packets lost every so often. Imagine reading a 10,000 word
speech as fast as you can only to find the audience saying 'I didn't get
that, can you say it again' every couple of minutes.
--
begin oefixed_in_2005.exe |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
The Natural Philosopher
Guest
|
| Posted: Wed Jul 16, 2008 11:05 am Post subject: Re: Why isn't ADSL rate adaptive |
|
|
Klunk wrote:
| Quote: |
On Tue, 15 Jul 2008 13:45:53 +0100, The Natural Philosopher passed an
empty day by writing:
Andy Furniss wrote:
The Natural Philosopher wrote:
Andy Furniss wrote:
ato_zee@hotmail.com wrote:
They are really handy if you want to run a packet tap on the
traffic going into and coming out of another computer, and that's
useful to help figure out why some network protocol is
malfunctioning or how a computer is being attacked.
Plus getting a handle on the effect of errors and retransmissions.
Not the same as loss on a dsl line though, as ethernet stores and
resends the frame so the tcp layer never sees a loss.
DSL does its own error correction and retransmision too..or something
does...could be at the ATM level I guess.
Error correction yes, when interleaving is on, retransmission no, not
at any level below TCP.
I did the research, and it appears you are essentially correct. Well
nice to learn new stuff!
TCP assumes loss means congestion and backs off so you really don't
want
link level loss. DSl IIRC defines a 0db SNR margin as that giving a
BER of 1E-7.
There are TCPs with congestion control algorithms that rely less on
loss - you have some if you use linux, but they don't get used on
internet servers, they are more for wireless I think.
Most TCP implementations carry some awareness of congestion, but it
certainly helps t tune things up a bit.
Not sure what my bit error rate is, but I am getting as I type about one
CRC every 10k frames.
Andy.
But the key here still remains that if the link is iffy, there will be a
loss which can affect the throughput - so upping the speed of the link
does not necessarily mean a massive increase in throughput if you get a
frame full of packets lost every so often. Imagine reading a 10,000 word
speech as fast as you can only to find the audience saying 'I didn't get
that, can you say it again' every couple of minutes.
Oh yes..no argument there at all. Thats why reducing packet and window |
sizes works...
....one of the mosts frustrating is satallite links: capable of vast data
rates with very little error, but with a latency measured in large
fractions of a second. you need HUGE window sizes so you dnt hang around
waiting for ACKS, but if it does drop a packet, expect a 4 second pause
in throughput.. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Mark
Guest
|
| Posted: Wed Jul 16, 2008 11:05 am Post subject: Re: Why isn't ADSL rate adaptive |
|
|
On Wed, 16 Jul 2008 08:17:13 +0100, The Natural Philosopher <a@b.c>
wrote:
| Quote: |
Klunk wrote:
On Tue, 15 Jul 2008 13:45:53 +0100, The Natural Philosopher passed an
empty day by writing:
Andy Furniss wrote:
The Natural Philosopher wrote:
Andy Furniss wrote:
ato_zee@hotmail.com wrote:
They are really handy if you want to run a packet tap on the
traffic going into and coming out of another computer, and that's
useful to help figure out why some network protocol is
malfunctioning or how a computer is being attacked.
Plus getting a handle on the effect of errors and retransmissions.
Not the same as loss on a dsl line though, as ethernet stores and
resends the frame so the tcp layer never sees a loss.
DSL does its own error correction and retransmision too..or something
does...could be at the ATM level I guess.
Error correction yes, when interleaving is on, retransmission no, not
at any level below TCP.
I did the research, and it appears you are essentially correct. Well
nice to learn new stuff!
TCP assumes loss means congestion and backs off so you really don't
want
link level loss. DSl IIRC defines a 0db SNR margin as that giving a
BER of 1E-7.
There are TCPs with congestion control algorithms that rely less on
loss - you have some if you use linux, but they don't get used on
internet servers, they are more for wireless I think.
Most TCP implementations carry some awareness of congestion, but it
certainly helps t tune things up a bit.
Not sure what my bit error rate is, but I am getting as I type about one
CRC every 10k frames.
Andy.
But the key here still remains that if the link is iffy, there will be a
loss which can affect the throughput - so upping the speed of the link
does not necessarily mean a massive increase in throughput if you get a
frame full of packets lost every so often. Imagine reading a 10,000 word
speech as fast as you can only to find the audience saying 'I didn't get
that, can you say it again' every couple of minutes.
Oh yes..no argument there at all. Thats why reducing packet and window
sizes works...
...one of the mosts frustrating is satallite links: capable of vast data
rates with very little error, but with a latency measured in large
fractions of a second. you need HUGE window sizes so you dnt hang around
waiting for ACKS, but if it does drop a packet, expect a 4 second pause
in throughput..
|
Sounds like it could do with greater data redundancy.
--
(\__/) M.
(='.'=) Owing to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
See http://improve-usenet.org |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Dennis Ferguson
Guest
|
| Posted: Thu Jul 17, 2008 9:22 am Post subject: Re: Why isn't ADSL rate adaptive |
|
|
On 2008-07-16, The Natural Philosopher <a@b.c> wrote:
| Quote: |
Klunk wrote:
But the key here still remains that if the link is iffy, there will be a
loss which can affect the throughput - so upping the speed of the link
does not necessarily mean a massive increase in throughput if you get a
frame full of packets lost every so often. Imagine reading a 10,000 word
speech as fast as you can only to find the audience saying 'I didn't get
that, can you say it again' every couple of minutes.
Oh yes..no argument there at all. Thats why reducing packet and window
sizes works...
...one of the mosts frustrating is satallite links: capable of vast data
rates with very little error, but with a latency measured in large
fractions of a second. you need HUGE window sizes so you dnt hang around
waiting for ACKS, but if it does drop a packet, expect a 4 second pause
in throughput..
|
I think if you use a TCP which supports SACK this shouldn't be such a
big problem; you don't have to wait a full round trip to find out what
needs to be resent and what doesn't.
It doesn't fix the basic problem with TCP and packet loss from link
errors, though. If a packet is lost due to a link error the "correct"
response is to resend that packet but otherwise keep on going full blast.
If a packet is lost due to congestion, however, the "correct" response
is to resend the packet and slow down to let the congestion clear.
Since TCP assumes that packet loss is always due to congestion (this is
the conservative assumption), when you get a significant level of
packet loss from link errors you end up with TCP going inappropriately
slow and leaving the link idle.
Dennis Ferguson |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
73 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
