User comments on ISPs
  >> BT Broadband


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | [7] | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | >> (show all)   Print Thread
Standard User TheEulerID
(committed) Fri 05-Feb-16 10:10:37
Print Post

Re: Myths exploded


[re: BatBoy] [link to this post]
 
g.inp does not, in itself, enable higher sync speeds. However, it does largely avoid the need for interleaving (or at least some of the more aggressive interleaving) which most definitely does impact on sync speeds. Also, as g.inp improves stability then it could, in theory, allow for a lower SNR margin.

Most of the changes I saw in the week or so after the local cabinet was enabled for g.inp was due to interleaving being switched on for a while. What I can say for absolute certain is that since it was enabled on the cabinet, the line stability has improved radically and it went from being an average of one resync a day to none. The only time it now resyncs is when on the approximately 14 day reboot.
Standard User BatBoy
(sensei) Fri 05-Feb-16 10:27:36
Print Post

Re: Myths exploded


[re: TheEulerID] [link to this post]
 
In reply to a post by TheEulerID:
g.inp does not, in itself, enable higher sync speeds. However, it does largely avoid the need for interleaving (or at least some of the more aggressive interleaving) which most definitely does impact on sync speeds.
Not forgetting INP (Impulse Noise Protection) which inflates the data stream with error correction data
Also, as g.inp improves stability then it could, in theory, allow for a lower SNR margin.
How does G.INP improve stability? I notice the target margin remains at 6
Most of the changes I saw in the week or so after the local cabinet was enabled for g.inp was due to interleaving being switched on for a while. What I can say for absolute certain is that since it was enabled on the cabinet, the line stability has improved radically and it went from being an average of one resync a day to none.
perhaps fixes have been applied to your line?
The only time it now resyncs is when on the approximately 14 day reboot.
which is very inconvenient if it happens when you are doing something such as gaming, making a call, watching a film.
Standard User BatBoy
(sensei) Fri 05-Feb-16 12:43:22
Print Post

Re: Myths exploded


[re: BatBoy] [link to this post]
 
I just rang BT for an update on this. They apologised for not getting back to me but have left notes on the fault so the person dealing with it, who's not in today, will ring me back with an update about when it will be fixed. Currently my uptime on my HH5A is

DSL uptime: 21 days, 21:14:57


Register (or login) on our website and you will not see this ad.

Standard User PaulKirby
(fountain of knowledge) Fri 05-Feb-16 14:26:20
Print Post

Re: Myths exploded


[re: BatBoy] [link to this post]
 
In reply to a post by BatBoy:
DSL uptime: 21 days, 21:14:57

Well the last time our HH4A did the reboot it was up for:
1289532.990000 = 14D 22H 12M 12S 990mS

We have been up this time for about 14 days, 16:49:04.

So in theory we are possibly due a reboot soon.

I think its like I said if they detect X amount of errors or sluggish in the HH it schedules it for reboot, so that the HH and connection stays stable.

Paul
Standard User Oliver341
(eat-sleep-adslguide) Fri 05-Feb-16 14:42:11
Print Post

Re: Myths exploded


[re: PaulKirby] [link to this post]
 
In reply to a post by PaulKirby:
I think its like I said if they detect X amount of errors or sluggish in the HH it schedules it for reboot, so that the HH and connection stays stable.

What's the PPP uptime? Maybe it works off that (which can be less than the DSL uptime of course).

Oliver.
Standard User TheEulerID
(committed) Fri 05-Feb-16 15:13:48
Print Post

Re: Myths exploded


[re: BatBoy] [link to this post]
 
g.inp does not add much of an overhead (unlike interleaving). Interleaving puts a whole lot of error correction data into the stream (in the time domain, hence the increase in latency). Unfortunately, it's a big overhead as most of that error correcting data will never be used, but it's transmitted anyway just in case. It's called "forward correcting" as all the redundancy information required for error correction is forwarded to the destination and there is no need (or even opportunity) to go back to the source.

In contrast, g.inp is a low-level on demand error correction protocol that works at the link level. Effectively it's a selective retransmission system where errors are detected at the far end of a link. It only introduces a delay for data that has been corrupted (which will be very much the exception) and the overhead is much, much lower for all but any retransmitted data.

g,inp increases the stability of the line simply because it can tolerate impulse noise better than if it isn't there (and interleaving isn't imposed). That means it will suffer fewer resyncs than an "unprotected" link as it can survive short glitches. It can thus tolerate a lower level SNR margin (or, alternatively, you might view it as being more reliable at the same SNR margin). Of course, interleaving can achieve this too, but at the penalty of a large overhead of error correction data and increased latency on all packets.

I have to emphasise these are link-level protocols between the two modems, and nothing to do with any error detection and retransmission in the higher level protocols (such as the e2e detection/retransmission in TCP).
Standard User PaulKirby
(fountain of knowledge) Fri 05-Feb-16 15:24:58
Print Post

Re: Myths exploded


[re: Oliver341] [link to this post]
 
In reply to a post by Oliver341:
In reply to a post by PaulKirby:
I think its like I said if they detect X amount of errors or sluggish in the HH it schedules it for reboot, so that the HH and connection stays stable.

What's the PPP uptime? Maybe it works off that (which can be less than the DSL uptime of course).
Not really checked, but its normally the same minus a few seconds.
Well unless BT internal network has an issue, which we have had on and off for the last few months, where we loose PPP connection but still remained synced up.

Paul
Standard User Oliver341
(eat-sleep-adslguide) Sat 06-Feb-16 19:00:35
Print Post

Re: Myths exploded


[re: PaulKirby] [link to this post]
 
In reply to a post by PaulKirby:
Well unless BT internal network has an issue, which we have had on and off for the last few months, where we loose PPP connection but still remained synced up.

According to the BT forum, PPP drops without sync drops is quite a common occurrence for some people, e.g: https://community.bt.com/t5/BT-Infinity-Speed-Connec...

Oliver.
Standard User BatBoy
(sensei) Sat 06-Feb-16 19:23:33
Print Post

Re: Myths exploded


[re: TheEulerID] [link to this post]
 
As far as I can see, if you have a damaged packet, you have a damaged packet and all the interleaving in the world can't fix that.
Standard User TheEulerID
(committed) Sat 06-Feb-16 22:30:29
Print Post

Re: Myths exploded


[re: BatBoy] [link to this post]
 
Packets are at a higher level in the comms stack. Link level protocols have there own error detection and recovery systems working at the frame level, which is what interleaving, g.in etc. are for. It will therefore never be seen as a corrupt IP packet. Of course, the occasional corrupt packet will be detected in it's passage through the Internet, as no system is perfect, but the link level error recovery systems seek to minimise this as significant levels of packet corruption are disastrous. Also, TCP/IP packet level error detection has significant weaknesses.

Edit

This is how interleaving works. Annoyingly, they call frames packets, but never mind.


kitz.co.uk/adsl/interleaving.htm

And while you are at it, look at the item kitz has on open reach and g.inp where it is explicitly stated, following an interview with an engineer from the company that says g.inp is supported upstream selectively for those modems which support it, but this is a later mod to the system. That is exactly what I've said all along.

Edited by TheEulerID (Sat 06-Feb-16 22:47:25)

Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | [7] | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | >> (show all)   Print Thread

Jump to