Print

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

[kitz]

Thank you blackcat.  This kitteh has just spent a good hour (gosh how time flies) looking at & comparing the results.
Again thanks to BE for the graphs.

Some musings from me

-----

Maximum Sync - F2 & F3 have a max upstream cap of 51316.

At first glance F1 appeared to show better 'maximum' downstream than F2, but repeat testing showe F2 to be the better of the pair.  Since both swang within about the same range, I think I'll have to say nothing conclusive can be drawn.

F3 showed far better max downstream.   Some of this though would be down to the re-organisation of the tone banding. The increase though is approx double of my rough calculation of what these tones would be worth if the bits were fully loaded.


Attained sync - Nothing much between them, but no surprise since they seem to have reached a plateau.

SNR Margin. - F3 has much higher SNR margin.

I actually find the figures 19.8, 19.7, 19.6  quite strange, when compared to F1 & F2
F1 & F2 appeared to show evidence of a different PSD mask than F3
The PSD mask on F3 in more in line with what I'd expect to see on adsl, as the 'uuuu' shape on F1 & F2 isnt something I'd seen before. IMHO the u shape was too regular to be anything other than PSD masks. This shape doesnt appear to follow bit loading though so something else going on there for F1 & F2, no idea what exactly.

F3 has better bit loading.  This could be related to the PSD type masking mentioned above.
 
The new tone banding on F3 also brings it more in line with adsl/adsl2+ banding for up/down.
This has both plus and minus points.  Less chance of vdsl-v-dsl crosstalk.   Less upstream tones mean a much lower upstream speed for long lines. Perhaps limiting upstream speeds to around 500-1000kbps depending on psd mask and bitloading.


I havent looked at all the settings, I believe the b*cat was doing that and has noticed SRA is now switched on by default.   This could or could not be interesting as Ive recently seen sight of a document sent out to ISPs who are to supply their own FTTC modem/routers to the EU rather than use the openreach modem.  One of the items that BT states it will be in-house testing for modem compliance is SRA.

----

and as I type this out something else just struck me.   F3 appears to have far better bit loading, so at first glance we may say - yep F3 is best.  Yet.. how comes they all have very similar sync speed.  Is F3 carrying more overhead and if so what for?   

----

The above are just thoughts and may or may not be correct.

[Bald_Eagle1]

For reference purposes, I have attached the 'snapshot' montages for F1, F2 & F3


& just for 'fun', I have attached a montage for my own connection 


Being a longer line length, used in 'real life' conditions, my connection actually 'needs' to use the U0 band for upstream bitloading.

[burakkucat]

Here is a sideways difference between the two files (which contain some selected output returned by various incantations of the "xdslcmd" command) -- the left hand side is from the original Asbo unlocked firmware image & the right hand side is from the original Wolfy unlocked firmware image.

Code: [Select]

Unlocked Asbo image. Unlocked Wolfy image.
(bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked) (bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_Wolfy_Unlocked)

# xdslcmd --version # xdslcmd --version
xdslcmd version 1.0 xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C030b.d22g      | DSL PHY: AnnexA version - A2pv6C038m.d24j
******* Pass ********* ******* Pass *********

# xdslcmd profile --show # xdslcmd profile --show

Modulations: Modulations:
G.Dmt Enabled G.Dmt Enabled
G.lite Enabled      | G.lite Disabled
T1.413 Enabled      | T1.413 Disabled
ADSL2 Enabled ADSL2 Enabled
AnnexL Enabled      | AnnexL Disabled
ADSL2+ Enabled ADSL2+ Enabled
AnnexM Disabled AnnexM Disabled
VDSL2 Enabled VDSL2 Enabled
VDSL2 profiles: VDSL2 profiles:
8a Enabled 8a Enabled
8b Enabled 8b Enabled
8c Enabled 8c Enabled
8d Enabled 8d Enabled
12a Enabled 12a Enabled
12b Enabled 12b Enabled
17a Enabled 17a Enabled
30a Enabled 30a Enabled
US0 Enabled US0 Enabled
Phone line pair: Phone line pair:
Inner pair Inner pair
Capability: Capability:
bitswap On bitswap On
sra Off      | sra On
trellis On trellis On
sesdrop Off sesdrop Off
CoMinMgn Off CoMinMgn Off
24k On 24k On
phyReXmt(Us/Ds) Off/On phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa TpsTc AvPvAa
monitorTone: On monitorTone: On
dynamicD: On dynamicD: On
dynamicF: On      | dynamicF: Off
SOS: On SOS: On
Training Margin(Q4 in dB): -1(DEFAULT) Training Margin(Q4 in dB): -1(DEFAULT)

# xdslcmd info --cfg # xdslcmd info --cfg
xdslcmd: ADSL driver and PHY status xdslcmd: ADSL driver and PHY status
Status: Showtime Status: Showtime
Retrain Reason: 0 Retrain Reason: 0
     > Last initialization procedure status: 0
Max: Upstream rate = 66480 Kbps, Downstream rate = 131956 Kbps    | Max: Upstream rate = 51316 Kbps, Downstream rate = 155408 Kbps
Path: 0, Upstream rate = 51316 Kbps, Downstream rate = 104997 Kbps | Bearer: 0, Upstream rate = 51316 Kbps, Downstream rate = 104999 Kbps


adslTrainingMarginQ4: -1 adslTrainingMarginQ4: -1
adslShowtimeMarginQ4: -1 adslShowtimeMarginQ4: -1
adslLOMTimeThldSec: -1 adslLOMTimeThldSec: -1
adslDemodCapMask: 0090447a adslDemodCapMask: 0090447a
adslDemodCapValue: 0010447a      | adslDemodCapValue: 0090447a
adsl2Param: 00000000 adsl2Param: 00000000
adslPwmSyncClockFreq: 0 adslPwmSyncClockFreq: 0
adslHsModeSwitchTime: 0 adslHsModeSwitchTime: 0
adslDemodCap2Mask: 00500200 adslDemodCap2Mask: 00500200
adslDemodCap2Value: 00500200      | adslDemodCap2Value: 00500000
vdslParam: 007f00ff vdslParam: 007f00ff
vdslParam1: 00000000 vdslParam1: 00000000
xdslAuxFeaturesMask: 00000003      | xdslAuxFeaturesMask: 00060003
xdslAuxFeaturesValue: 00000003      | xdslAuxFeaturesValue: 00060003
vdslCfgFlagsMask: 00000000      | vdslCfgFlagsMask: 00210400
vdslCfgFlagsValue: 00000000      | vdslCfgFlagsValue: 00210400
     > xdslCfg1Mask: 00000000
     > xdslCfg1Value: 00000000
     > xdslCfg2Mask: 00000000
     > xdslCfg2Value: 00000000
     > xdslCfg3Mask: 00000000
     > xdslCfg3Value: 00000000
     > xdslCfg4Mask: 00000000
     > xdslCfg4Value: 00000000
     > maxDsDataRateKbps: 0
     > maxUsDataRateKbps: 0
     > maxAggrDataRateKbps: 0
     > xdslMiscCfgParam: 00000000
     > AFE_ID: 10608100 00000000

When viewing the sdiff, please take note of the "marker" in the "central gutter" between the two files. A "null" marker indicates that there is no difference. A "|" marker indicates that there is a difference. A "<" marker indicates a line unique to the left hard side, whilst a ">" marker indicates a line unique to the right hand side.

The sdiff file is also attached below, for anyone who would like to examine it locally.

[Bald_Eagle1]

FWIW, using the original Asbo unlocked firmware & allowing BT to update it, I only see this for the xdslcmd profile --show command:-

Code: [Select]


# xdslcmd profile --show

Modulations:
        G.Dmt   Enabled
        G.lite  Enabled
        T1.413  Enabled
        ADSL2   Enabled
        AnnexL  Enabled
        ADSL2+  Enabled
        AnnexM  Disabled
        VDSL2   Enabled
Phone line pair:
        Inner pair
Capability:
        bitswap         On
        sra             Off
        trellis         On
        sesdrop         Off
        CoMinMgn        Off
        24k             On
        phyReXmt(Us/Ds) Off/On
        TpsTc           AvPvAa
        monitorTone:    On
        dynamicD:       On
        dynamicF:       Off
        SOS:            On
        Training Margin(Q4 in dB):      50
#


i.e. I don't see any of this:-

Code: [Select]


VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 Enabled


This is from a failed attempt to lower SNRM on my connection:-

Training Margin(Q4 in dB):      50

[burakkucat]

Please consider the screen scrape, attached below. It is of one particular page of the HG612's GUI after that device had synchronised with the (one port) DSLAM (the VC-230N).

The firmware image being used was the original unlocked version from Asbokid. (bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked)

For the testing that was currently being performed, it was only necessary for the HG612 to establish synchronism with the VC-230N.

Look down at the WAN Packet section. The ptm1.101 line refers to the Ethernet bridge between the HG612's LAN1 and WAN ports. Nothing was shown as occurring because that bridge was not in use. However the ptm1.301 line is interesting. That line refers to the tagged VLAN, which exists for the BTagent ("Beattie's busybody") to communicate with the "Evil Empire".    What caught my eye was that the values reported in the Byte and Packet columns, under the Send header, continued to increment as the BTagent ("Beattie's little snitch") attempted to "call home", following the power up of the HG612.

The fact that the BTagent desperately wants to report back to the "Evil Empire" (via a tagged VLAN numbered 301) makes me wonder if I should try to provide such a VLAN, just to see what the "busybody" will attempt to do next. 

Comments, suggestions, etc, are welcomed from all. 

[burakkucat]

FWIW, using the original Asbo unlocked firmware & allowing BT to update it, I only see this for the xdslcmd profile --show command:-
<snip>

  Hmm . . . I wonder if a "long reset" would be required? 

Perhaps Wolfy may have an opinion on your observation that he might share?

[Bald_Eagle1]

  Hmm . . . I wonder if a "long reset" would be required? 

Perhaps Wolfy may have an opinion on your observation that he might share?

From what I can gather, a long reset whilst still using Asbo's original firmware (subsequently updated by Beattie) causes 'telnet' access to be blocked.

I will experiment, probably at the weekend, with a copy of Wolfy's firmware at hand in readiness........................

[Howlingwolf]

Please consider the screen scrape, attached below. It is of one particular page of the HG612's GUI after that device had synchronised with the (one port) DSLAM (the VC-230N).

The firmware image being used was the original unlocked version from Asbokid. (bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked)

For the testing that was currently being performed, it was only necessary for the HG612 to establish synchronism with the VC-230N.

Look down at the WAN Packet section. The ptm1.101 line refers to the Ethernet bridge between the HG612's LAN1 and WAN ports. Nothing was shown as occurring because that bridge was not in use. However the ptm1.301 line is interesting. That line refers to the tagged VLAN, which exists for the BTagent ("Beattie's busybody") to communicate with the "Evil Empire".    What caught my eye was that the values reported in the Byte and Packet columns, under the Send header, continued to increment as the BTagent ("Beattie's little snitch") attempted to "call home", following the power up of the HG612.

The fact that the BTagent desperately wants to report back to the "Evil Empire" (via a tagged VLAN numbered 301) makes me wonder if I should try to provide such a VLAN, just to see what the "busybody" will attempt to do next. 

Comments, suggestions, etc, are welcomed from all. 

I'd certainly be interested is seeing what's going on there. My own research into BTAgent got interrupted some time back and there's little chance of me getting back to it any time soon.

From what I can gather, a long reset whilst still using Asbo's original firmware (subsequently updated by Beattie) causes 'telnet' access to be blocked.

That's correct. There's a post on this in the other thread if you're interested in the technical details.

[burakkucat]

I have come across something that may be of interest to Eagles and Wolves, as well as general Kitizens.

It would probably be best for me to start at the beginning . . .

Walter recently asked about the procedure for updating the firmware in HG612 devices. Having given a typed, step-wise, description I thought it would be useful to collect together a series of "screen scrapes" whilst performing such an update myself.

My (one and only) HG612 currently had the "Wolfy unlocked with GUI" firmware installed. I duly updated it with the "Asbo original unlocked" firmware, capturing "screen scrapes" during the process.

That is the background information. Subsequently I entered the GUI of the device and as I "passed by" the WAN ---> Network page, something did not "seem right" under the WAN Packet heading. It took a few moments for me to realise that the ptm1.301 line was completely missing! 

Having satisfied myself that I had, indeed, updated the device with the "Asbo original unlocked" firmware, a faint tintinnabulation occurred at the back of my mind. Going to Maintenance ---> Device, I left-clicked upon Restore Default Setting under the Reset tab. Once the device had finished its re-boot cycle, I returned to the WAN ---> Network page and observed that the ptm1.301 line was now present under the WAN Packet heading.

As that faint tintinnabulation had now been transmogrified into a loud peel of bells, I searched my archive for a note that had been sent to me some years ago, by Asbokid. And here it is --

I just flashed the unlocked SP10 firmware into that early HG612 which had SP06 firmware ... and it works but you need to perform one
extra step.

The working XML config file from SP06 is still stored in the persistent data area of the flash memory and you need to overwrite that
old SP06 config with the new SP10 config file.

To do that you have to 'Restore Default Settings'. That's an option under [Maintenance | Device | Reset] in the HG612 web interface.

The unlocked SP10 XML config file is then read from the squashfs read-only root file system and it is written to the persistent data
area of the flash memory. That ensures that the old SP06 config file is overwritten.

So, fellow HG612 firmware "flashers", beware! 

[burakkucat]

I still have two phases of investigations to complete that come under this subject heading.

• A repeat of my earlier experiments but with a "local loop" of some significant length, as requested by les-70. All the components are now "in place" for this to be performed. I just need to make four pairs of connections and then find a suitable "time window" to perform the three separate experiments.
• For the second phase, I would like to have some input from others. I have collected together a sequence of "screen-scrapes" which shows the configuration of the VC-230N. Those images can be downloaded in a ZIP format file. The VC-230N is configured in CO mode with its wireless as a client device and the wireless, the VDSL2 port & the four LAN ports all bridged together. This phase is intended to investigate the two VLANs that are configured in a HG612 device. The VLAN tagged 101 is used by the LAN1 port to VDSL2 port bridge of the HG612 device. The VLAN tagged 301 is that used by Beattie's busybody, the BTagent, within the HG612 device. I have attached, below, an image that shows how I have configured four VLANs in the VC-230N device. With it powered up and an Ethernet patch cable connecting my laptop computer to the LAN4 port, it is possible to obtain Internet access through the wireless link. With an HG612 device connected to the other end of the VDSL2 "local loop", my proposal is to prove that the LAN1 port of the HG612 device and the LAN1 port of the VC-230N device are linked via the VLAN 101. Once that is confirmed, the next step will be to focus attention onto the LAN3 port of the VC-230N device from which would appear the busybody's attempts to "call home" via the VLAN tagged 301. Finally I propose to configure a third VLAN, tagged 401, bound to the LAN2 port on the HG612 device and attempt to obtain Internet access. Suggestions as to how the HG612 device should be configured for this will be welcomed.

[Howlingwolf]

I have come across something that may be of interest to Eagles and Wolves, as well as general Kitizens.

<snip>

The working XML config file from SP06 is still stored in the persistent data area of the flash memory and you need to overwrite that old SP06 config with the new SP10 config file.

<snip>

So, fellow HG612 firmware "flashers", beware! 

My research into why some people were losing telnet access while others didn't shows that this only happens when the config is changed as the update process does not clear the 'user' config areas in flashmem. Only restoring the defaults via the reset button or the web interface does that.

There's a post on it here: http://forum.kitz.co.uk/index.php?topic=13130.msg247609#msg247609

The relevant part is about halfway down after a quote from bbnovice.

Finally I propose to configure a third VLAN, tagged 401, bound to the LAN2 port on the HG612 device and attempt to obtain Internet access. Suggestions as to how the HG612 device should be configured for this will be welcomed.

One approach might be to temporarily configure the modem for routed mode then examine the bridging and iptables configuration via telnet. That might point you in the right direction.

Unfortunately I can't assist right at this moment. I had a bit of a disaster at the end of last week when a BGW V7 vhd test installation decided to stomp all over the BGW XP partition bootblock after running without any problems for nearly a week. After much 'fiddling about' I was forced to wipe the entire drive, repartition it and restore to cure the problem.

Do you have any idea how long it takes to backup and restore 300GB of operating systems, virtual machines, games, assorted O/S iso images and miscellaneous other materials... 

I'm still in the middle of attempting to bring order out of chaos and archive as much of this stuff off onto DVD where it belongs.

I may also be still suffering from PDRDS (Post Disaster Recovery Distress Symptoms) 

[NewtronStar]

I may also be still suffering from PDRDS (Post Disaster Recovery Distress Symptoms) 

I can almost here the pain in your text, same thing happened to me last march with 2 partitions and had to install the first OS and use Easeus Data recovery program to recover partition 1 & 2 data and lost 3% which is not bad but it took 3 hours to scan the partitons.

all my data now go's onto a usb2 external HD its slow at 2-10 Megabytes per second     

[burakkucat]

I have finally prepared a 398 metres local loop and am now ready to repeat the tests with those three firmware images. Tomorrow's task, me thinks.

Completely irrelevant to the tests but if I opted to take a FTTC based service, the loop length from my NTE5/A to the PCP and then down a tie-cable pair to the Huawei SmartAX MA5616 MSAN would be . . . precisely 391 metres!

Edit: As "today" is the "tomorrow" referenced above and I have not performed the tests (where does a feline's time go (when awake)?) I attach, as a consolation, an image of the 398 metres local loop that will eventually be used . . . 

[burakkucat]

After a lot of "fiddle-faddling" and "cat cursing", three sets of measurements were made with a 398 metre "local loop".

I'm not happy with the results.    As the connections between the ends of the "local loop" and the two halves of the severed RJ11 to RJ11 patch cable were very "temperamental", I intend to repeat the experiment.

My latest plan for the "local loop" is to fit an LJU2/3A socket at either end (the cable and the sockets' IDCs are, as we know, made for each other    ) and then use two RJ11 to 431A patch leads to connect the HG612 & VC-230N devices to the LJU2/3A sockets.

[burakkucat]

An image of the revised "local loop" is attached, below.

I'm now awaiting the delivery of a hideously expensive (£0-99) "RJ11 to 431A patch lead", hopefully sometime tomorrow. (Typical. I only had one stashed away in the bowels of my grotto.    )