Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[William Grimsley]

I must add that in the past on my ADSL line a Billion BiPAC 7800N [Its in the loft now but still works] - which was IMO the most stable router I ever had so I do have a soft spot for Billion equip.

Yeah, I mean to say the DSL light was on, it was probably an exchange syncronisation issue so a power cycle was the only way to sort it.

[NewtronStar]

I am not convinced that your line uncapped will hit the 40Mbps (39999kbps) target at most it will get close to 37000 kbps there is to much going against you and that is distance and available tones 

Edit : if William Grimsley
has blocked me on the forums you won't see this message and it would help me a great deal not to waste my time responding to your post if you have them blocked 

[William Grimsley]

I am not convinced that your line uncapped will hit the 40Mbps (39999kbps) target at most it will get close to 37000 kbps there is to much going against you and that is distance and available tones 

Edit : if William Grimsley
has blocked me on the forums you won't see this message and it would help me a great deal not to waste my time responding to your post if you have them blocked 

Are you mad? I'm not blocking anyone. Stop being so presumptive! Jesus! Yes, I had another DLM resync last night and some factors changed but the line is still banded. The Downstream Rate will increase to 40000 Kbps because it was at that before.

[andyfitter]

I wouldn't bank on your banded line returning to its original speed. Banding sometimes seems to 'stick' - for me for over a year, long after the original issue had been resolved.

It was only fixed via a DLM reset from a provider change. After that long, I assume it might have *never* resolved itself automatically.

[WWWombat]

It does look like DLM changed some settings overnight.

On the face of it, it looks like DLM has increased intervention level, rather than decreased it ... the INP level has changed from 48 to 54, and upstream G.INP has been turned on. The INPRein value has been turned on downstream too, though the delay value hasn't increased from 0.

I suspect that DLM thinks yesterday wasn't a good day. But it is hard to tell why.

We can see resyncs at 17:00 and 19:00 from the "uptime" chart, plus the DLM-induced one around 4:15. But who knows what went on in the missing 8 hours.

As for the potential speed ... When your speed is around 40Mbps, I reckon 3dB of margin is worth around 7Mbps. Your current SNR margin is 9.6dB, so you should be able to reach 40Mbps, if/when banding gets removed. That SNR margin is a lot lower than a few days ago, suggesting that the recent change by DLM has caused more bandwidth to be used for FEC protection; unfortunately, these parameters aren't logged by MDWS, so I can't tell.

[Dray]

That SNR margin is a lot lower than a few days ago, suggesting that the recent change by DLM has caused more bandwidth to be used for FEC protection; unfortunately, these parameters aren't logged by MDWS, so I can't tell.

 Would it be worthwhile requesting that MDWS is enhanced to log these parameters?

[tbailey2]

Would it be worthwhile requesting that MDWS is enhanced to log these parameters?

It might be and they might already be in the database - if I knew what it or they were.

But there are possibly major problems if they are not. And even if they are in there - I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .

[Dray]

It might be and they might already be in the database - if I knew what it or they were.

But there are possibly major problems if they are not. And even if they are in there - I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .

I think we all need to talk more

[tbailey2]

It might be and they might already be in the database - if I knew what it or they were.

But there are possibly major problems if they are not. And even if they are in there - I tried showing some of the currently missing params a couple of weeks back but then discovered that only one of the two programs is actually uploading them.. .

I think we all need to talk more

[William Grimsley]

Interesting. The interleaver depth decreased from 16 to 8 on Downstream though, so something positive has come out of it.

May I ask what is going on here?



Have I set something up wrong with the connection?

[William Grimsley]

It does look like DLM changed some settings overnight.

On the face of it, it looks like DLM has increased intervention level, rather than decreased it ... the INP level has changed from 48 to 54, and upstream G.INP has been turned on. The INPRein value has been turned on downstream too, though the delay value hasn't increased from 0.

I suspect that DLM thinks yesterday wasn't a good day. But it is hard to tell why.

We can see resyncs at 17:00 and 19:00 from the "uptime" chart, plus the DLM-induced one around 4:15. But who knows what went on in the missing 8 hours.

As for the potential speed ... When your speed is around 40Mbps, I reckon 3dB of margin is worth around 7Mbps. Your current SNR margin is 9.6dB, so you should be able to reach 40Mbps, if/when banding gets removed. That SNR margin is a lot lower than a few days ago, suggesting that the recent change by DLM has caused more bandwidth to be used for FEC protection; unfortunately, these parameters aren't logged by MDWS, so I can't tell.

Now, that is interesting. I may have to get a DLM reset in a few weeks if the Donwstream Rate doesn't return to 40000 Kbps...

[WWWombat]

It might be and they might already be in the database - if I knew what it or they were.

The FEC and interleaving parameters are the R, D, I and N parameters from "--show" and "--stats"
- R and N show the amount of FEC overhead (R bytes in a block of N bytes is the extra parity data for FEC protection; it allows R/2 bytes to be corrected). 5% is low (old-style) or standard (with G.INP), 18-20% is standard old-style, 30% is very high.
- D and I show the amount of interleaving (depth and "width", aka interleaving block size). Multiplying D and I gives the relative scale of delays/latency.
- N should be a multiple of I.

I think we all need to talk more

I'm not sure what to add here, except how I go about things...

When I analyse someone's line, I'll tend to look at data in this order:
- Attenuation, incl pbParams - How "long" is the line?
- Hlog, QLN, SNR/tone and bits/tone ... Is the line acting right for that length? What is the noise environment? Crosstalk? UPBO?
- INP, INPRein, delay - What has DLM asked for? Is it light or heavy? Getting worse or better?
- R, D, I, N - What impact has the DLM settings had on the line settings? Bandwidth overhead and latency overhead
- Sync actual and attainable - Does this match with FEC overheads?
- BQM latency - Does this match with interleaving latency overhead?
- FEC, CRC, ES - What impact should we expect on DLM, old-style? Patterns across the day; 24 hour ES total
- RS/RSCorr/RSUncorr - If lots of FEC, I look at the proportions of these
- OHF/OHFerr - If lots of CRC, I look at the proportion of these
- rtx_tx, rtx_c, rtx_uc - How much retransmission is going on? How much re-retransmission? How much failure?
- LEFTRS, minEFTR - Is retransmission affecting the overall throughput?

When I look at the data, or charts of the data over time, I guess I'm looking for patterns, or trying to assess some items for quality. I wonder if we can figure any of that into our own KBD, or centre of excellence?

[William Grimsley]

Well, this is interesting. No wonder DLM acted negatively on the line. There's no data!

[WWWombat]

Interesting. The interleaver depth decreased from 16 to 8 on Downstream though, so something positive has come out of it.

True - ironically a "worse" DLM setting can result in a lower interleaving depth. However, the scale of interleaving depends on the block-size too, which probably changed. In any case, interleaving has been added upstream, so there will be added latency in that direction too. Small, certainly, but still added.

May I ask what is going on here?

The router is doing some tests. However, the tests are run "per connection", and the first one (on mine) shows "Test the connection to your local network --- pppoa_0_0_38" with similar failures. But that connection is one targeted at ADSL; look at menu item "Status" -> "WAN" to see all the connections.

If you try clicking on "Next Connection" (possibly more than once), you'll eventually get to a page that shows "Test the connection to your local network --- pppoe_0_1_1.101.101.101.101" which is the connection used for FTTC.

That one will give a slightly better result.

I hae some more information. I just did a telnet using the adsl info --stats command on the Billion BiPAC 8800NL. Interestingly, there was no data recorded from the Billion BiPAC 8800NL before I powered down and powered up the Billion BiPAC 8800NL shortly after I came home last night. So, the line was completely dead before I power cycled the Billion BiPAC 8800NL. So, that's probably why the DLM resync was negative because there wasn't a lot of data.

My 8800NL just survived 101 days, before I rebooted it myself while trying to debug a faulty TV service. Over the last year, it has worked without flaw. If this happens to you much more, you might want to suspect it as being faulty.

[William Grimsley]

Interesting. The interleaver depth decreased from 16 to 8 on Downstream though, so something positive has come out of it.

True - ironically a "worse" DLM setting can result in a lower interleaving depth. However, the scale of interleaving depends on the block-size too, which probably changed. In any case, interleaving has been added upstream, so there will be added latency in that direction too. Small, certainly, but still added.

May I ask what is going on here?

The router is doing some tests. However, the tests are run "per connection", and the first one (on mine) shows "Test the connection to your local network --- pppoa_0_0_38" with similar failures. But that connection is one targeted at ADSL; look at menu item "Status" -> "WAN" to see all the connections.

If you try clicking on "Next Connection" (possibly more than once), you'll eventually get to a page that shows "Test the connection to your local network --- pppoe_0_1_1.101.101.101.101" which is the connection used for FTTC.

That one will give a slightly better result.

I hae some more information. I just did a telnet using the adsl info --stats command on the Billion BiPAC 8800NL. Interestingly, there was no data recorded from the Billion BiPAC 8800NL before I powered down and powered up the Billion BiPAC 8800NL shortly after I came home last night. So, the line was completely dead before I power cycled the Billion BiPAC 8800NL. So, that's probably why the DLM resync was negative because there wasn't a lot of data.

My 8800NL just survived 101 days, before I rebooted it myself while trying to debug a faulty TV service. Over the last year, it has worked without flaw. If this happens to you much more, you might want to suspect it as being faulty.

That's interesting. I'll have a look at the FTTC connection page and see if it has a better result. Obviously, if my Billion BiPAC 8800NL starts to do this more often, I will send it back and get a new one.

Does this look better?