Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 [2]

Author Topic: Speed capping to reduce errors  (Read 4992 times)

GaryW

  • Member
  • **
  • Posts: 96
Re: Speed capping to reduce errors
« Reply #15 on: February 21, 2018, 08:59:56 AM »

I'm not on fastpath - I'm interleaved (31 data bytes, 10 redundancy bytes according to the Billion, not sure what the Draytek was doing).
Logged
EE 4G - Huawei B618s-22d - BT WHWF

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: Speed capping to reduce errors
« Reply #16 on: February 21, 2018, 09:05:49 AM »

I'm not on fastpath - I'm interleaved (31 data bytes, 10 redundancy bytes according to the Billion, not sure what the Draytek was doing).

Hmm, I see, interesting. I've never really compared the results when I've been interleaved but perhaps it still applies something differently that causes some additional overhead or something.
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 4093
Re: Speed capping to reduce errors
« Reply #17 on: February 21, 2018, 09:11:54 AM »

Quote
I briefly tried a Draytek 2760, at a point when I knew from my Billion that I was banded at 14999.  Without tweaking the SNRM offset on the Draytek, it synced at 11400 (ish, can't remember exactly) - I know that looks like a banded limit, but I immediately switched back to the Billion and was straight back to 14999.
Banding can change on the fly when your swapping modems back and forth.
I'll eat Paddys hat if the Draytek didn't hit a banded figure. Probably over 5000 to 1 odds it resynced at that exact number (11,399 you've stated on numerous previous posts).
Quote
I just gave up on the Draytek (sent it back) without really looking at stats or playing with parameters - didn't seem worth it since the starting point was so poor

14,999 @8dB snrm would be 19-20Mb attainabnle
11,399 not banded (6dB) would be under 60% the sync rate of the Billion.
The Broadcom chipsets do tend to perform better/sync higher than Lantiq.
I don't believe the difference to be anywhere near that high though.
Logged
Talktalk FTTP 550/75 - Speedtest - BQM

GaryW

  • Member
  • **
  • Posts: 96
Re: Speed capping to reduce errors
« Reply #18 on: February 21, 2018, 09:33:33 AM »

Banding can change on the fly when your swapping modems back and forth.
I'll eat Paddys hat if the Draytek didn't hit a banded figure. Probably over 5000 to 1 odds it resynced at that exact number (11,399 you've stated on numerous previous posts).
14,999 @8dB snrm would be 19-20Mb attainabnle
11,399 not banded (6dB) would be under 60% the sync rate of the Billion.
The Broadcom chipsets do tend to perform better/sync higher than Lantiq.
I don't believe the difference to be anywhere near that high though.

Does banding really change on the fly that quickly?  There was one resync to put the Draytek in place, then another resync later in the day to put the Billion back in place.  Would DLM really drop the banding to 11.4 and then restore it to 15 in the same day?  Based on my previous experience of my line (when I'd eliminated internal RFI), it took somewhere in excess of a month for DLM to raise my banding from 11.4 to 13, and a further month to raise it from 13 to 15.  It seems odd that DLM would then drop the banding to 11.4 on a resync then raise it to 15 on the next resync later in the day.  Or are you saying that DLM remembers/varies banding for a particular chipset?
Logged
EE 4G - Huawei B618s-22d - BT WHWF

j0hn

  • Kitizen
  • ****
  • Posts: 4093
Re: Speed capping to reduce errors
« Reply #19 on: February 21, 2018, 10:04:29 AM »

Quote
Does banding really change on the fly that quickly?
Yes it can.
DLM reacts to ES over a 24 hour period, once a day.
It doesn't wait 24 hours with resyncs.
It can react instantly to multiple resyncs (e.g swapping modems).

I've seen (on numerous occasions) problem lines constantly resyncing back and forth between banded levels throughout the day.

My main point is that the DrayTek doesn't sync anywhere near that low in comparison to Broadcom chipsets (under 60%).
The odds that it wasn't a banded level are extremely high.

Logged
Talktalk FTTP 550/75 - Speedtest - BQM

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Speed capping to reduce errors
« Reply #20 on: February 21, 2018, 07:36:28 PM »

I'm pretty sure the reason why the DrayTek syncs lower, if you're on fastpath that is, is because it applies reed solomon coding (R: 16) on the downstream where as a modem with a Broadcom chipset doesn't seem to (R: 0). As such the 'R: 16' reduces the sync rate as there's a light amount of error correction. I imagine all devices with a Lantiq do this for some reason.

It's never quite that simple unfortunately. Remember that the modem works out the best speed it can manage subject to meeting the bit error rate (generally 1 bit error in 107 bits). When you add error correction, that reduces the error rate, and so should allow for more speed meeting the same bit error rate.
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: Speed capping to reduce errors
« Reply #21 on: February 21, 2018, 07:43:40 PM »

It's never quite that simple unfortunately. Remember that the modem works out the best speed it can manage subject to meeting the bit error rate (generally 1 bit error in 107 bits). When you add error correction, that reduces the error rate, and so should allow for more speed meeting the same bit error rate.

True, but I would still imagine it's at least part of the reason :).
Logged

kayjay

  • Just arrived
  • *
  • Posts: 1
Re: Speed capping to reduce errors
« Reply #22 on: October 26, 2018, 06:52:25 PM »

On the Draytek increasing the margin does indeed work and I sync up at lower speeds with a higher margin, but it does not solve the problem. As soon as my SNR degrades, and it does at some times of the day, the line still drops as before. What I really want is to to fix the sync speed to a lower value such that when the SNR is poor the standard 6db noise margin is not exceeded and the line does not drop. This issue can happen 20+ times a day
Logged
Pages: 1 [2]