On 07/07/2008 11:32, wrote:

IMHO the correct way to manage the SNR threshold is do do
it adaptively, measure the error rate, if it is high say over 30%
reduce the sync rate, if it then drops below say 10% increase
the sync rate.

Have you seen what 1% (let alone 10% or 30%) packet loss does for TCP
throughput?

On Mon, 07 Jul 2008 13:04:07 +0100, Andy Burns passed an empty day by
writing:

On 07/07/2008 11:32, wrote:

IMHO the correct way to manage the SNR threshold is do do it
adaptively, measure the error rate, if it is high say over 30% reduce
the sync rate, if it then drops below say 10% increase the sync rate.

Have you seen what 1% (let alone 10% or 30%) packet loss does for TCP
throughput?

I've not seen it - what does it do? I'm guessing it has a serious
throttling effect.

--
begin oefixed_in_2005.exe

Have you seen what 1% (let alone 10% or 30%) packet loss does for TCP
throughput?

I've not seen it - what does it do? I'm guessing it has a serious
throttling effect.

So ethernet cannot work as it is based on collisions, retransmissions,
and packet loss.
Try using a heavily loaded ethernet segment to see its effect
on TCP/IP, preferably while watching a network analyser,
to see what's happening in real time.
Ideally you aim for a 1% or less figure for retransmissions over
any link, at 10% you notice degredation, 30% or above severe
degredation.
This applies to ADSL as well.
For gamers, VOIP, P2P you try for a low error rate, but have
to bear in mind that a connection is only as good as the weakest
link, that usually means the slowest most congested link of
the many point to point links you may be going through, from
router to router, often between continents.
If you want low loss then you use a synchronous
protocol, but you would still have problems with some UK
ADSL long, high noise, lines.

On Mon, 07 Jul 2008 15:33:33 +0000, ato_zee passed an empty day by
writing:

Have you seen what 1% (let alone 10% or 30%) packet loss does for TCP
throughput?

I've not seen it - what does it do? I'm guessing it has a serious
throttling effect.

So ethernet cannot work as it is based on collisions, retransmissions,
and packet loss.
Try using a heavily loaded ethernet segment to see its effect on TCP/IP,
preferably while watching a network analyser, to see what's happening in
real time. Ideally you aim for a 1% or less figure for retransmissions
over any link, at 10% you notice degredation, 30% or above severe
degredation.
This applies to ADSL as well.
For gamers, VOIP, P2P you try for a low error rate, but have to bear in
mind that a connection is only as good as the weakest link, that usually
means the slowest most congested link of the many point to point links
you may be going through, from router to router, often between
continents. If you want low loss then you use a synchronous protocol,
but you would still have problems with some UK ADSL long, high noise,
lines.

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. It is,
however, just a guess. The PPP portion should already be able to
negotiate the optimum connection - it always could with dial-up modems.
How it fits in with Asynchronous Transfer Mode has me too cuffudled to
get my head around at this moment.

--
begin oefixed_in_2005.exe

Klunk wrote:
On Mon, 07 Jul 2008 03:19:45 +0100, Martin passed an empty day by writing:

Klunk:
So, with this in mind, why can't the routers firmware pick up the fact
that the statistics on the line have changed, and then refresh the sync?
Surely this is a pretty basic thing to do in router firmware if the
vendors wanted to do it?
Am I missing something?
Yes, the BT DSLAM will NO longer play ball and just sticks to min SNR
prescribed by BRAS for that line.
Therefore I think that routers that can set their own min SNR will be of
no help.
Regards,
Martin

There is just one thing that gets my mind boggling in all of this. Say
your LLU ISP decide to lower the noise threshold to give you that 'faster
speed'. You've not actually changed the fact that the line is saturated
with 'x' amount of noise. It probably follows that you may have an
increase in bit rate, but surely the error rate will increase in
proportion making any actual increase in speed less than it may first
appear?

yes, and your resynchs will be more frequent.

BTs system keeps customer complaints down to the minimum. It makes sure
you have reliable error free con nection. Sometimes you lose a lot of
speed as a tradeoff.

Klunk wrote:
On Mon, 07 Jul 2008 15:33:33 +0000, ato_zee passed an empty day by
writing:

Have you seen what 1% (let alone 10% or 30%) packet loss does for TCP
throughput?
I've not seen it - what does it do? I'm guessing it has a serious
throttling effect.
So ethernet cannot work as it is based on collisions, retransmissions,
and packet loss.
Try using a heavily loaded ethernet segment to see its effect on TCP/IP,
preferably while watching a network analyser, to see what's happening in
real time. Ideally you aim for a 1% or less figure for retransmissions
over any link, at 10% you notice degredation, 30% or above severe
degredation.
This applies to ADSL as well.
For gamers, VOIP, P2P you try for a low error rate, but have to bear in
mind that a connection is only as good as the weakest link, that usually
means the slowest most congested link of the many point to point links
you may be going through, from router to router, often between
continents. If you want low loss then you use a synchronous protocol,
but you would still have problems with some UK ADSL long, high noise,
lines.

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. It is,
however, just a guess. The PPP portion should already be able to
negotiate the optimum connection - it always could with dial-up modems.
How it fits in with Asynchronous Transfer Mode has me too cuffudled to
get my head around at this moment.

thats is correct but not relevant: what he was saying is that once error
rates go above a small percentage, the retransmits start smashing what
bandwidth you still have.


TCP/IP tends to then start sending in longer and longer time slots and
thruoghput crashes.

On 07/07/2008 16:33, wrote:

So ethernet cannot work as it is based on collisions, retransmissions,
and packet loss.

Except in a few dark corners where coax and transceivers still lurk,
Ethernet hasn't used CSMACD for decades (i.e since it used twisted pair)

Klunk:
It probably follows that you may have an
increase in bit rate, but surely the error rate will increase in
proportion making any actual increase in speed less than it may first
appear?

But the problem is the noise on the line has random spikes, which cut off
the synch regardless of the speed !

My line used to be 2.8Mb/s and 6dB SNR for weeks on end, but sometimes cut
of every couple of days, sometimes just hours. It usually took couple of
reboots to get back to 6dB and max speed.

Now BT / DSLAM / BRAS has PERMANENTLY pegged my SNR at min 12dB and thus
throttled my speed to 1.5Mb/s, but actual download speed is just 800kb/s.

Its like this:
"BT sells you a car that will do 'up to' 80 mph.
In reality it will at best reach 28 mph, and the engine cuts out every few
days, if not hours, because the wiring is c**p.
Instead of fixing the problem, BT reduces the speed to 15 mph,
but of course it still cuts out just the same !

In real life one could get a new car or the money back,
but BT is still a monopoly and law to itself !

BT are UNNECESSARILY reducing the usability of our connection.

We now have mobile broadband, as yet it's not much better, but is meant to
improve soon. We may be giving up broadband and the BT line.....
Regards,
Martin

Invalid:
Only solution I've found, which helps a
little is to swap Draytek and BT modems.
This seems to force two retrains, the
second when I put the original one back
again

Tried that, it didn't help.
Temporarily replaced the 2WIRE aka BT1801HG router with Draytek 2600 (plain
ADSL).
The Draytek connected at even lower speed ~1.2Mb/s and 13.5dB,
when I put the 2WIRE back it synched at 12dB and 1.5Mb/s, slighty lower then
previous 1.64Mb/s.
Now I am stuck with that....
Regards,
Martin

On Mon, 07 Jul 2008 20:23:14 +0100, The Natural Philosopher passed an
empty day by writing:

Klunk wrote:
On Mon, 07 Jul 2008 15:33:33 +0000, ato_zee passed an empty day by
writing:

Have you seen what 1% (let alone 10% or 30%) packet loss does for
TCP throughput?
I've not seen it - what does it do? I'm guessing it has a serious
throttling effect.
So ethernet cannot work as it is based on collisions, retransmissions,
and packet loss.
Try using a heavily loaded ethernet segment to see its effect on
TCP/IP, preferably while watching a network analyser, to see what's
happening in real time. Ideally you aim for a 1% or less figure for
retransmissions over any link, at 10% you notice degredation, 30% or
above severe degredation.
This applies to ADSL as well.
For gamers, VOIP, P2P you try for a low error rate, but have to bear
in mind that a connection is only as good as the weakest link, that
usually means the slowest most congested link of the many point to
point links you may be going through, from router to router, often
between continents. If you want low loss then you use a synchronous
protocol, but you would still have problems with some UK ADSL long,
high noise, lines.

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. It
is, however, just a guess. The PPP portion should already be able to
negotiate the optimum connection - it always could with dial-up modems.
How it fits in with Asynchronous Transfer Mode has me too cuffudled to
get my head around at this moment.

thats is correct but not relevant: what he was saying is that once error
rates go above a small percentage, the retransmits start smashing what
bandwidth you still have.


TCP/IP tends to then start sending in longer and longer time slots and
thruoghput crashes.

Thanks, I was not aware of that. I've not looked into that closely.
Something for a rainy month - I'll start today.


--
begin oefixed_in_2005.exe