Print

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

[Ixel]

Hi all,
Just a follow up to say to everyone who's interested that you can bump the SNRM target up on the Line Settings tab with a BT Infinity connection. I've currently set my SNRM target on the downstream to 9dB successfully . See screenshot below.



The only problem I need to overcome now is how to get my static IP's to work again, as I'm a business customer. I allowed the Business Hub to do this for me before. I have my gateway IP and IP range, just a matter of figuring out how to configure static routing. Any suggestions?

[asbokid]

Hi all,
Just a follow up to say to everyone who's interested that you can bump the SNRM target up on the Line Settings tab with a BT Infinity connection. I've currently set my SNRM target on the downstream to 9dB successfully . See screenshot below.
[..]

Excellent discovery, Ixel!

It was previously thought that the the SNR target margin was locked by the MSAN (both Huawei and ECI)  Do you know which MSAN are you hooked to?  The ECI should report an IFTN (Infineon now Lantiq) linecard chipset, whereas the Huawei is BDCM (Broadcom).

It would be great if you could confirm that the tweak in the SNRM is definitely resulting in a change to subcarrier bitloading. i.e. channel throughput is going up and down accordingly (and error counts are affected likewise).   Perhaps some screenshots showing Attainable Throughput at SNRMs of 3dB, 6dB, 9dB and 12dB.

cheers, a

[Ixel]

Hi all,
Just a follow up to say to everyone who's interested that you can bump the SNRM target up on the Line Settings tab with a BT Infinity connection. I've currently set my SNRM target on the downstream to 9dB successfully . See screenshot below.
[..]

Excellent discovery, Ixel!

It was previously thought that the the SNR target margin was locked by the MSAN (both Huawei and ECI)  Do you know which MSAN are you hooked to?  The ECI should report an IFTN (Infineon now Lantiq) linecard chipset, whereas the Huawei is BDCM (Broadcom).

It would be great if you could confirm that the tweak in the SNRM is definitely resulting in a change to subcarrier bitloading. i.e. channel throughput is going up and down accordingly (and error counts are affected likewise).   Perhaps some screenshots showing Attainable Throughput at SNRMs of 3dB, 6dB, 9dB and 12dB.

cheers, a

I'm on an ECI, DSL Overview page reports it as Infineon. My throughput seemed to drop according to the increased SNR. I moved the slider three steps to the left for SNRM target purpose, which would change the default SNRM target by +3 dB. I appear to sync at 9 dB currently with a lower throughput downstream. I'm not sure if there's a dodgy connection between me and the cab though, as whenever an engineer is in the PCP setting someone else up my connection's SNR/attainable rate fluctuates, either usually dropping a bit or increasing a bit. I've noticed in the spectrum tab that occasionally on an auto refresh of the SNR image some of the high frequencies completely disappear for a second, while the lower ones remain fine.

I will monitor stats and perhaps further adjust the sliders, but I will only do so once a day in order to not further upset DLM as I'm rather high up on INP/delay/interleaving as it is (before changing to the Fritz it was like this). I believe the --snr parameter on the HG612 didn't do anything because it was designed for use on ADSLx type connections, not VDSLx.

[Ixel]

Well, setting up the public static IP's wasn't as bad as I thought. All I had to do was set the router to use the final public IP in my range that was given to me, disable NAT and then setup my devices to use a public IP in the usable range along with the gateway IP being my router public IP. No messing around with static routing was necessary.

[asbokid]

It was previously thought that the the SNR target margin was locked by the MSAN (both Huawei and ECI)
...
It would be great if you could confirm that the tweak in the SNRM is definitely resulting in a change to subcarrier bitloading. i.e. channel throughput is going up and down accordingly (and error counts are affected likewise).   Perhaps some screenshots showing Attainable Throughput at SNRMs of 3dB, 6dB, 9dB and 12dB.

My throughput seemed to drop according to the increased SNR. I moved the slider three steps to the left for SNRM target purpose, which would change the default SNRM target by +3 dB. I appear to sync at 9 dB currently with a lower throughput downstream.

Worth noting, as you move the slider, the reported throughput and error figures, for the sake of comparison.  Perhaps specific statistics could shed some light.   Lots of people would be interested, so well worth exploring in detail.

The Huawei MA5616 MSAN which Openreach is installing in many of the FTTC cabinets has a firmware option for setting the Target SNR margin. It would seem that only the service provider has control over it. *

Here's how the VDSL2 profile, including the Target SNRM is modified in the Command Line Interface (CLI) of the Huawei MA56xx MSAN.

To alter the Target SNRM, Openreach provisioning engineers do so via the CLI, either with a laptop and serial cable at the FTTC cabinet, or remotely via a network client:

Code: [Select]

huawei(config)#vdsl line-profile modify
{ profile-index<U><1,128> }:2

  Command:
          vdsl line-profile modify 2
  Start modifying profile 2. New setting will take effect automatically after the modification succeed
..
>    Transmission mode:
>      0: Custom
>      1: All (G.992.1~5,T1.413,G.993.2)
>      2: Full rate(G.992.1/3/5,T1.413,G.993.2)
>      3: G.DMT (G.992.1/3/5,G.993.2)
>      4: G.HS (G.992.1~5,G.993.2)
>      5: ADSL (G.992.1~5,T1.413)
>      6: VDSL (G.993.2)
>    Please select (0~6) [1]:1
>  Bit swap downstream 1-disable 2-enable (1~2) [2]:1
>  Bit swap upstream   1-disable 2-enable (1~2) [2]:
>  Please select the form of transmit rate adaptation downstream:
>  1-fixed, 2-adaptAtStartup, 3-adaptAtRuntime (1~3) [1]:1
>  Please select the form of transmit rate adaptation upstream:
>  1-fixed, 2-adaptAtStartup, 3-adaptAtRuntime (1~3) [1]:1
>  Will you set SNR margin parameters? (y/n) [n]:y
>    Target SNR margin downstream (0~310 0.1dB) [60]:60
>    Minimum SNR margin downstream (0~60 0.1dB) [10]:10
>    Maximum SNR margin downstream (60~310 0.1dB) [300]:300
>    Target SNR margin upstream (0~310 0.1dB) [60]:60
>    Minimum SNR margin upstream (0~60 0.1dB) [10]:10
>    Maximum SNR margin upstream (60~310 0.1dB) [300]:300
>  Will you set DPBO parameters? (y/n)[n]:
>  Will you set UPBO parameters? (y/n)[n]:
>  Will you set RFI notch configuration parameter? (y/n) [n]:y
>    Please set the RFI notch band range, the format : tone index(0~6956)
>    or begin tone index-end tone index. Begin tone index must not be more
>    than end tone index, for example:20,25-30. The bandwidth of each
>    tone is 4.3125KHz. You cannot set more than 16 ranges:1-2,10-20
>  Will you set ADSL tone blackout configuration parameter? (y/n) [n]:y
>    The parameter format is : tone index or begin tone index to end tone
>    index. Begin tone index must not be more than end tone index, for
>    example: 20,25-30.
>    Downstream, tone index is from 0 to 511, you cannot set more than 8 ranges:100-200,350-400
>    Upstream, tone index is from 0 to 63, you cannot set more than 4 ranges:10-20,35-40
>  Will you set VDSL tone blackout configuration parameter? (y/n) [n]:y
>    Please set the VDSL tone blackout range, the format : tone index(0~6956)
>    or begin tone index-end tone index. Begin tone index must not be more
>    than end tone index, for example:20,25-30. The bandwidth of
>    each tone is 4.3125KHz. You cannot set more than 8 ranges:35-40
>  Will you set mode-specific parameters? (y/n) [n]:y
>    Current configured modes:
>    1-defmode              6-adsl2PlusIsdn
>    Please select 1-Add  2-Modify  3-Delete  4-Save and quit   [4]:1
>    2-adsl                 3-adsl2Pots            4-adsl2Isdn
>    5-adsl2PlusPots        7-adsl2ReachExtended   8-vdsl2Pots
>    9-vdsl2Isdn
>    Please select  [2]:5
>    Maximum nominal aggregate transmit power downstream
>    (0~205 0.1dBm) [145]:
>    Maximum nominal aggregate transmit power upstream
>    (0~205 0.1dBm) [145]:
>    Will you set PSD mask value downstream parameter? (y/n) [n]:
>    Will you set PSD mask value upstream parameter? (y/n) [n]:
>    Will you set Upstream PSD mask selection parameter? (y/n) [n]:y
>      This parameter is used only for Annexes J and M of ITUT
>      Recommendations G.992.3 and G.992.5.
>      It ranges from 1 to 9,from ADLU-32 to ADLU-64 in Annexes J
>      and from EU-32 to EU-64 in Annexes M.
>      You can select the mask with the following definition:
>      1-ADLU-32/EU-32       2-ADLU-36/EU-36
>      3-ADLU-40/EU-40       4-ADLU-44/EU-44
>      5-ADLU-48/EU-48       6-ADLU-52/EU-52
>      7-ADLU-56/EU-56       8-ADLU-60/EU-60
>      9-ADLU-64/EU-64
>      Please select(1~9)[1]:6
>    Current configured modes:
>    1-defmode              5-adsl2PlusPots        6-adsl2PlusIsdn
>    Please select 1-Add  2-Modify  3-Delete  4-Save and quit   [4]:
>  Will you create a new profile to save these settings (y/n) [n]:
  Modify profile 2 successfully, and new setting will take effect after the bound ports are reactivated

Though perhaps the ECI MSAN behaves differently?  Or maybe the Fritzbox is not reporting the Target SNRM? Perhaps that (suspiciously rounded..) figure of 9dB shown in the FritzBox GUI is not the current SNR for each channel, but just the user-requested Target SNR Margin?  To which the MSAN pays no heed?   Does the SNR figure go up and down? Or is it stuck on 9dB?

It would seem odd for Ikanos (who make the FritzBox chipset) to include a mechanism for tweaking Target SNRM, while Broadcom, the market-leader, apparently did not.     Nice to know for sure though!

There are some ADSL2+ and VDSL2 linecards here. At some point they could be used to test under 'laboratory conditions', the various VDSL2 chipsets for CPE (Broadcom, Lantiq, Ikanos, PMC-Sierra and Metanoia, any more?).  With the advantage of being in control of both ends of the connection. 

Though if you do find the time before then, some screenshots of the line stats reported by your FritzBox at various CPE-selected Target SNRM would be very useful.

cheers, a

* EDIT: The Huawei MSAN supports 128 possible different VDSL2 line profiles (see "profile-index" above). Each profile can in theory have its own Target SNRM.  However, even the mini-MSAN (MA5616) when fully-loaded, could be serving 192 separate VDSL2 subscriber lines. Any of those 128 line profiles can be bound to any of the 192 VDSL2 subscriber lines (aka ports).

So there are not enough VDSL2 line profiles to allocate a unique profile (with a unique Target SNRM) to each port.  Therefore consumer tweaking of TSNRM doesn't appear possible. If TSNRM tweaking was allowed, one subscriber could alter the target margin for all other subscribers on the same line profile!  But maybe there is something still overlooked?

[Ixel]

...

This will take me over the course of a few days to a week to accomplish this, as I don't want to further upset DLM in the process. That's also assuming an engineer doesn't do something in the PCP again, during the testing time, which either increases or decreases my attainable rate.

All I know is my sync speed and attainable speed decreased since upping the SNRM target, and the GUI did at one point today show 8 dB, then it rose back to 9 dB a few moments ago (so it fluctuated). Perhaps ECI isn't restricted, but I have a feeling Huawei cabinets would do the same as the ECI, I don't think the SNRM target is restricted, just that the HG612 is incapable of specifying it as I believe the --snr <n> parameter is for ADSLx connections.

I am tempted to enable telnet, but at the same time I've heard it invalidates the warranty and leaves a flag set on the router to know it has had telnet enabled. On the other hand, I've heard you can reset the flag by using a recovery tool and uploading the firmware again through that.

[Ixel]

I have an odd problem that I've noticed this morning. When I use my phone now I notice a 3dB~ SNR drop, once I've hung up it goes back up by the amount that was lost. My only guess is that it's the special Y cable supplied with the Fritzbox 7390 . Any ideas? This only happens in the receive direction, not the send direction.

I have taken two pictures of the SNR graph, one with phone in use and one without phone in use.

Phone not in use (SNR increase/normal):


Phone in use (SNR drop/not normal):

[Ixel]

Just an update to say I've solved the problem with the noise margin dropping when using the phone, I'm not sure exactly how but it's one or both of the following:
- Put DECT phones to work on old base station (the router's one was making snapping noises on the phones every few seconds occasionally) and plugged the base station into Fon0 on the back of the router
- Changed identification of RFI to the middle (balanced between max stability and max performance) on the line settings page

[asbokid]

The VDSL2 chipset in the Fritz!Box 7390 is the Ikanos Fusiv Vx180 [1]. The Fusiv Vx180 (codenamed IKF6850) is an obscure two-IC chipset, found rarely in VDSL2 CPE shipped by telcos.   Why could that be?  An issue of performance, price or chipset politics?

The Fritz!Box 7390 is a comparatively expensive device (~£200), but there are a few other manufacturers using the same Fusiv chipset.  Ikanos publishes a list of customers on its website [2]   Most of these are tiddlers or fledglings with little or no manufacturing volumes. One exception, however, is D-Link.

To date, D-Link has built two VDSL2 devices around the Ikanos Fusiv IKF6850.  These are the D-Link DSL-6541K and the DSL-6641K.

Below are photos of the DSL-6641K (posted by zaxc123 to a Taiwanese tech. forum [3].  More info on the same devices at [4] and [5])

(click for full size)


(click for full size)


(click for full size)


(click for full size)


(click for full size)


(click for full size)


(click for full size)


(click for full size)


(click for full size)

These D-Link VDSL2 devices seem to be supplied only to the Asian market. And Taiwan in particular, where VDSL2 spectral masks (Region 3?) may be different to Europe. However, perhaps these devices could be tweaked to work here, too.  For those interested in the Fusiv VDSL2 chipset, maybe these D-Links could be a low-cost alternative to the Fritz!Box?

It would be insightful to pitch all of the VDSL2 CPE chipsets against each other, in a benchmark test of their comparative performance under various conditions.

cheers, a

EDIT:  Other Vx180 VDSL2 devices include the Sagemcom Fast 2764 and the Fast 2864 [6] [7].  These devices are re-branded as the PowerBox GVT and shipped as CPE by Brazilian telco, Global Village Telecom (GVT).  Another source perhaps for a cheap Ikanos VDSL2 modem?  The Fast 2764 sells new in Brazil for R$70 or less (about £20).



[1] http://forum.kitz.co.uk/index.php/topic,11470
[2] http://www.ikanos.com/company/customers/
[3] http://www.pczone.com.tw/vbb3/thread/16/154707/
[4] http://www.mobile01.com/topicdetail.php?f=507&t=2026497
[5] http://www.mobile01.com/topicdetail.php?f=507&t=1573962
[6] http://www.portaladsl.com.br/modules.php?name=Forums&file=viewtopic&t=14419
[7] http://www.hardware.com.br/comunidade/sagemcom-hackeando/1238038/

[Ixel]

Just a follow up, though playing around with the settings has cost me a DLM profile drop temporarily, it was worth it to see what worked and what didn't.

From my testing so far, I've found:
- MaxDownstreamRate, MaxUpstreamRate and/or setting the SNRM target offset for downstream all work.
- DSINP doesn't appear to work. Modifying the port profile (unless I'm not doing it right) doesn't appear to do anything either. Either I'm not doing it right or these are enforced remotely.

I'm going to leave my connection running for as long as possible now, in hope that DLM will trigger a disconnection within 7 days to relieve the error correction and such that's in place currently. My CRC errors have definitely decreased by bumping up the SNR for both downstream and upstream (I did upstream by specifying MaxUpstreamRate to be 15000, in other words limit the upstream sync to 15,000 kilobits). I've also capped the downstream rate, for now (until DLM hopefully relieves error correction stuff) to 50,000 kilobits (using MaxDownstreamRate 50000).

My SNR recently, before specifying an upstream sync rate limit, was 6dB~ at the full 20000. It's now 9dB~ at 14992, with downstream around 12dB at 50000. I confirmed if these limits appeared to be working by doing a few cycles of speedtest.net on a reliable server (I've found the one in London by Structured Communications (something like that anyway) works reliably for me), and I'm pleased to say that these limits appear to work. I'd be quite happy living with 40-50/15-20 as opposed to 65-70/20 that I was getting after people were starting to be setup on Infinity on my cabinet, if I can get an interleaving depth of 1. Until people started being setup after me (I was first apparently) I was getting 80/20 with an attainable rate in the mid 90's, upload was around 30's.

Something of interesting to some perhaps, which I can't seem to get to work:

Code: [Select]

cpe> 21

 Enter port profile number: 0

         =====================
           PORT PROFILE MENU
         =====================

      1) Min. Noise Margin

      2) Interleaved Percentage

      3) Upstream Max. Interleave Delay

      4) Downstream Max. Interleave Delay

      5) Configure RFI Band

      6) Set Port Options

      7) Tone Disable Configuration

      8) IFE II Configuration

      9) Network Configuration

     27) xDSL Line Profile

     51) Disable Microcut

     60) Retransmission Configuration

     97) Copy values from another profile

     98) Restore profile to default values

 Select the Parameter type from the list
 Press Enter to exit menu without modifications: 3

 Current Upstream Max. Interleave Delay= 63.0 ms
 Enter the new value (in units of 0.5 ms) :1.0

 Writing the data into File
EDIT: Forgot to say that when DLM dropped my profile last in the early hours the Fritz!Box remained connected with a SNR of -5dB, forcing me to unplug it and plug it back in once I woke up.

[asbokid]

Just a follow up...

From my testing so far, I've found:
- MaxDownstreamRate, MaxUpstreamRate and/or setting the SNRM target offset for downstream all work.

Hi again Ixel,

Just for the sake of clarity, what do you mean by "and/or setting the SNRM target offset for downstream all work."    Is that a yes, no or just a maybe?!

It's just that some people might buy a FrizBox, based on what you are reporting here and on ThinkBroadband.

The FritzBox is, however, an expensive (overpriced??) modem, so it could be a costly mistake if that function was found not to work after all (because control of the SNRM is locked by BT's DSLAMs, as many are finding).

What people have discovered with the HG612, as with the FritzBox, is that it is easy to change the SNR target margin for ADSL1/2/2+ and for VDSL2.

However, with a VDSL2 connection, the British Telecom DSLAM (both the ECI and the Huawei) appears to ignore those end-users changes. Instead the DSLAM maintains its own margin, which it adjusts dynamically according to line performance.

Those owning an HG612 (and other Broadcom-based devices) can soon confirm this with the xdslcmd tool.

Below we see the SNR training (aka target) margin set to default (-1). This shows that the margin is by default decided by the DSLAM:

Code: [Select]

# xdslcmd profile --show
...
Capability
:..
Training Margin(Q4 in dB): -1(DEFAULT)

Now we can try to tweak the SNRM. In this case halving whatever the default is (usually 6dB):

Code: [Select]

# xdslcmd configure --snr 50
xdslCtl_GetVersion success

And that end-user change to the margin is confirmed as below:

Code: [Select]

# xdslcmd profile --show   
..
Training Margin(Q4 in dB): 50

Others will confirm that for VDSL2, the request is simply ignored by the DSLAM. Instead, the DLM algorithm running on the DSLAM controller will continue to apply its own (dynamic) SNRM.

My SNR recently, before specifying an upstream sync rate limit, was 6dB~ at the full 20000. It's now 9dB~ at 14992, with downstream around 12dB at 50000.

Will you clarify again what you are saying, please. Earlier, you showed us that the average SNR on your line was fluctuating any way.  Isn't that what it is continuing to do now?

Since the line has to re-train to use a new user-specified SNR margin, we should expect to find that tweaking the margin in the CPE causes an immediate and demonstrable change in average SNR. As well as an immediate change in the ATTNDR.   Which might be illustrated best through screenshots.  Yet it seems you are not reporting that?

P.S. For those interested in trialling the Ikanos Fusiv Vx180, the chipset found in the FritzBox 7390, there is also the Sagemcom Fast 2764 which uses an identical DSL platform.  The two devices should perform the same on the DSL side.

A vendor in Brazil is selling the Sagemcom 2764 for R$85 (about £25).  A lot cheaper than the FritzBox 7390 at ~£200. [1]

Sagemcom F@st 2764 (Ikanos Fusiv Vx180 chipset)
(click for full size)

More photos at [2]

cheers, a

[1] http://produto.mercadolivre.com.br/MLB-432428081-modem-vdsl-wi-fi-power-box-modelo-2764-sagemcom-1-a-100mbps-_JM
[2] http://www.tripleoxygen.net/wp/2012/08/sagemcom-modem-fst-2764-gv-power-box-gvt-teardown/

[Ixel]

You are right, perhaps all my current findings are just display errors, tricking me into believing it works. If people wish to follow what I do then that's up to them, their risk. The reason I haven't posted any screenshots as yet is because: A) I haven't taken many, B) I've just finished converting my HG612Plotter project to work with the Fritz!Box so I can save graphs and such locally as images, automatically, and C) Because DLM has downgraded my profile recently due to the number of resyncs I've been doing due to trying out the various settings, so I'll give it a week or so to hopefully start recovering and should then (with one change to a setting on the router every 48 hours at most) be able to start to prove my findings (for those who doubt either me or any of this).

I didn't mean to add confusion by the 'and/or' statement, but to answer your question, all of them work. I stated 'and/or' because you could use all or just some of them together, up to you.

One thing I find annoying about the Fritz!Box, the attainable rate never changes until you resync, it's completely fixed while synced, or so it would seem for me.

All I can say is, despite whether or not the display is bugged from my specified settings, my CRC errors and error seconds have reduced from what I remember them to be, and comparing to at least one 'xdslcmd info --stats' I saved in the past from the HG612.

[Ixel]

...

Hi,
A follow up with some initial proof, to identify that I'm either not seeing something unreal or that I may be lieing (though I can't see what would motivate me to do so).

My speeds are capped on the FB7390 at 50000 / 10500, by using MaxDownstreamRate and MaxUpstreamRate in /var/flash/ar7.cfg.

Check out the following images, it should be sufficient for initial proof. I'm still waiting for DLM to reduce my INP, interleaving and such, unless of course the downside of what I'm doing is that it causes DLM to freeze temporarily, though I doubt it. Ideally I believe I just need to maintain a connnection for a long while, rather than keep disconnecting every 2-3 days like I am in hope to see a pending DLM change. I can certainly say that as of today I will not be touching the connection for at least 1-2 weeks, hoping by then that DLM will see my CRC errors have reduced considerably on both downstream and upstream.







The statistics shown on my FB7390 Plotter program are fetched from the web interface (which uses an XML file that contains the data, and Ajax to fetch and refresh it on the webpage), and so are the same details seen on the web interface. If you doubt that the Plotter screenshot is real then I will be happy to submit a screenshot of the webpage concerned. Last but not least, the attainable rate fetched (for the downstream) seems to be the attainable rate that I'd get at 6dB with the current interleaving and INP configuration, not the attainable rate without that (like the HG612 displays).

Any thoughts or.. ?

[asbokid]

It looks like Blighty Telco's HG612, a device based on the Broadcom 6368,  has gained a following as alternative CPE in Brazil.   (Bem-vindo!)

http://translate.google.com/translate?u=http://www.portaladsl.com.br/modules.php?na..14855

The standard issue VDSL2 CPE from the Brazilian incumbent is the Sagemcom 2764. The Sagemcom modem-router is re-branded as the Power Box GVT. The 2764 is based on the Fusiv Vx180 VDSL2 chipset from Ikanos, also found in the Fritz!Box 7390.

Brazilian owners of both the HG612 and the 2764 report a similar DSL performance.

cheers, a

[Ixel]

I hate to bring an old thread back to life, but I can't resist for more than a week or so with playing around, not to mention I love to prove my theories or research are valid. Today I bring everyone two screenshots of my Fritz!Box page, one showing the default 6dB SNRM on the control panel, the speeds I am achieveing and such, and the other one about 5 minutes later showing what happens when I set the downstream SNRM offset to 40 (by setting the Intended Signal-to-Noise-Ratio in Line Settings to Maximum Stability as opposed to Maximum Performance).

The top half of the screenshot is when I've set the DS SNRM offset to 40 (Maximum Stability), the lower half is everything at default (no DS SNRM offset - Maximum Performance).



As you can see, I get the following results:

DS SNRM Target	DS Sync Rate
6 dB	68,080 kbit/s
10 dB	59,824 kbit/s

Hopefully this information is useful, though I imagine one or two people will still say that this is just a display bug. Mind you, why does my IP profile change accordingly, can those who doubt the results explain that?