What's happening

1st May 2016 BQM goes from http://www.thinkbroadband.com/ping/share/7f5184dcfa2... low latency which it has been for a long long time.

to http://www.thinkbroadband.com/ping/share/ebf02c35c87... no idea what the spikes are.

then on 17th June to http://www.thinkbroadband.com/ping/share/e7eb509ccfe... spikes disappear latency +10

I use a Billion 8800NL fibre router/modem, which is working fine. Nothing changed on the phone line. I've tried to jump gateways a couple of times to get lower latency but nothing changes.

For some reason I can't copy/paste the line stats.

Edited by wingco1 (Fri 17-Jun-16 16:31:08)

All three are coming back as:

Page Not Found

The page you were looking for was not found. Please double check the address you entered. Alternatively, select an option from the menu to continue.

As MHC says.

I see your live BQM is working. I think you need to pick up the equivalent link just below the graph on the history page.

Thanks I've replaced the original links. Hopefully these should now be fine.

Yes, those work fine. Any chance you could find the day the base latency changes please?

http://www.thinkbroadband.com/ping/share/f74bf990e74...

I suspect your base latency has actually risen by 8ms, which is the standard first step by DLM when turning on interleaving. Have you also lost quite a bit of connection speed?

The spikes in my case were always to do with the routing through Plusnet's systems. Not just the gateway but also the route to it from entering PN's backhaul. You may find a red marker on your BQM at the point they disappeared.

Line Stats, is this any help?

Line Coding (Trellis) On On
SNR Margin (dB) 6.3 6.1
Attenuation (dB) 18.7 0.0
Output Power (dBm) 12.7 6.8
Attainable Rate (Kbps) 75462 20245
Rate (Kbps) 63053 19998
B (# of bytes in Mux Data Frame) 51 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 64 3
R (# of redundancy bytes in the RS codeword) 12 16
S (# of data symbols over which the RS code word spans) 0.0262 0.3788
L (# of bits transmitted in each data symbol) 19512 5385
D (interleaver depth) 1235 1
I (interleaver block size in bytes) 64 255
N (RS codeword size) 64 255
Delay (msec) 8 0
INP (DMT symbol) 3.00 0.00
OH Frames 99465167 26519151

D line - interleave depth. 1 = Fast path

Delay line - what has been added to latency by DLM.

Your upstream sync is at maximum so there shouldn't be a problem with that.

The I and N lines define the dimensions of the matrix being used by the interleaving. WWWombat is the expert on how all those parameters work together.

Note how high the downstream Attainable Rate is compared to the Rate. That is normal when interleaving is on. If interleaving gets turned off then Attainable will fall and Rate will rise. Delay reset to zero.

I asked earlier if you know what the cabinet is. That's so we know whether G.INP is available on your line. If it is, it is possible that in a while it will step in, normalise the rate, set interleaving depth to 8 or 16 in most circumstances, and zeroise the Delay. That's assuming your Billion is G.INP capable. I think it is but others will know for sure, yea or nay.

Thanks for the info Bob. It's an ECI cabinet. Confirmed by a friendly BB engineer

Spikes: I suffered with them for a long time and tried tyo find out the reason - with not joy. I got rid of them by moving from an ECI modem to a Huawei which resulted in a speeed drop. They were, like yours, happening at regular intervals, with an occasional double spike.

Unfortunately the BPM does not hold records over 6 months old so I cannot link to it.

I also suffered same, never got to the bottom of it.

However nobody has ever reported it causing a problem so far as I know, and loads of us have had them. It doesn't seem anything to worry about.

Agreed!

Problem no, niggle yes.

If a large download was running and a a spike occurred then the download could stall for a few seconds which if you were looking at a remote system capability on a satellite link then you needed to be aware.

Not necessarily. The BQM and similar only show what is happening to pings, not data traffic.

Your example needs a little more definition anyway. If you are talking about domestic or even business internet connections via satellite then the latency on those is a completely different order of magnitude and variability in the first place.

If you are talking about mission-critical control systems such as the control of telecoms or any other sort of satellite the networks we are on will not be in use.

Edited by RobertoS (Sat 18-Jun-16 11:47:03)

Yes, it does show what is happening to the pings but the cause of that can also affect data - as I have experienced.

When running test on satellite connectivity I would have an MES uploading continually on a connection at maybe 20, 30 or 40 Mbps. Then via the satellite it would be landed at a GES and routed to me via a normal connection. When running a test for significant periods of time I would see notches in the received data rate the timing of which correspond with the BQM spikes.

Are MES and GES acronyms I should be familiar with? I'm not going to look them up. Because of them your post is even less clear than your previous one.

You say it was a test. If you were losing data or the data was time-critical you proved my point.

How were you sending? Through your normal connection to a sending station or what?

Clear as mud .

I was one of the first to try one of these. The problem was got to the bottom of long ago - Caused by the wireless. Switch it off and go wired to prove!

19th June 2016. With no input from me it seems to have resolved itself.
http://www.thinkbroadband.com/ping/share/967ea7a66ef...

Can Anyone explain this please?
http://www.thinkbroadband.com/ping/share/73ee5bc61f3...
Thanks