Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: fbnts on April 02, 2013, 10:40:57 PM
-
Hi,
My FTTC has slowly reduced the attainable rate over the past few months. (I have a flashed HG612 so can see the line stats).
I have been using rs-w which shows a graph of the bit loading. One interesting thing I see is that the loading for the lower tones (100 to 900 ish ) almost half every few minute and then restore after a few seconds.
Would this indicate a fault?
Attached are two images of the bit loading.
Tom
-
Would this indicate a fault?
Tom
Well, it certainly doesn't look like normal behaviour! :( The reduction in bit-loading appears to have been caused by an accompanying increase in the SNR margin in the D1 band, but why it should oscillate on a minute-by-minute basis like that is beyond me at this point. ??? Perhaps the DSLAM line-card has left the cabinet! ;)
Wiser heads will join the debate soon I expect.
-
Some months ago I actually had a callout with BT as the line was synced higher than the modem's stated attainable rate.
The engineer that came out found a fault in the junction box where the line is attached to the house, just wonder if there's another fault somewhere?
I have just taken a snapshot of the SNR and CRC screens as well.
What is D1 band? What is the blue sections on the bit loading?
Tom
-
Some months ago I actually had a callout with BT as the line was synced higher than the modem's stated attainable rate.
The engineer that came out found a fault in the junction box where the line is attached to the house, just wonder if there's another fault somewhere?
I have just taken a snapshot of the SNR and CRC screens as well.
What is D1 band? What is the blue sections on the bit loading?
Tom
Well, I think that it is very possible that you have another fault. As I thought, your SNR graphs show it oscillating wildly at one point, which is definately 'not normal'.
D1 is the first (red) Downstream band on your bitloading graphs; it includes the ADSL2+ range (up to ~tone 450). The fact that this D1 band is affected most, while the higher frequency bands seem (to me) to be unaffected, does suggest to me that there may well be a fault somewhere between you and the cabinet. The blue tones are 'shared', that is can be allocated either to the upstream or the downstream as necessary during bitswapping (or at least that's my rough understanding of it).
-
Now I just need to try and convince BT there's a fault and proving it to them without them getting arsey that I have a flashed modem which enables me to get these stats!
It all started when I upgraded from 40/10 to 80/20 and didn't notice any change. According to the telnet data I am correctly on 17a:
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 10809 Kbps, Downstream rate = 34548 Kbps
Path: 0, Upstream rate = 10932 Kbps, Downstream rate = 35875 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.3 6.2
Attn(dB): 0.0 0.0
Pwr(dBm): 11.4 6.8
-
Well, well, well! Thinking about your problem Tom, made me go and have a look at my own bit-loadings on rsw.
And guess what :o, I am also getting some 'oscilation' of the bit-loadings in the lower tones of D1, albeit not as frequently as yours. Unfortunately, for some reason I will need to investigate I can't seem to get rsw snapshots working at the moment, or I would post the graphs.
However, sometimes I am getting additional shared (blue) tones in the 30-90 tone range and these are allowing these bins to be loaded as high as 14 bits for a time; then (because of errors I guess) they get first reduced in number, then removed and the loadings fall to 4-6 bits per bin. I think this is just part of the 'normal' error correction on my line, trying to utilise unused bins to carry bits from others with errors, only to find that they are (presumably) worse! It's a very dynamic thing.
I don't remember seeing these before (although I just may not have been looking closely enough until your post) but the DSLAM did force a resync on me earlier this evening, and I don't recall having shared tones in these lower bins before that.
Perhaps somebody wiser will now be able to explain this to both of us. I don't seem to have the wild SNR oscillation you posted, it just appears like that on mine if you were to take 2 snapshots, one with the shared tones on and higher bin loadings and then later when they are removed again and the loadings fall.
/correction. The DSLAM did not force a resynch on me, it was just a data harvesting hiccup .correction/
-
I think the random changes in bitloading data values is a bug. I noticed the same behaviour on my Broadcom 6368 based device.
I noticed another strange thing. The SNR and bitloading data doesn't always fit together.
The first picture was taken directly after a resync, the second a bit later:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.abload.de%2Fthumb%2Fbitloading-2013-03-04ilaba.png&hash=e678cc1234ee7e6447a8e9821fe294b0816aeda4) (http://www.abload.de/img/bitloading-2013-03-04ilaba.png)(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.abload.de%2Fthumb%2Fbitloading-2013-03-04yurih.png&hash=e439bd64a9e9c96e3bfd18b9320524316be39def) (http://www.abload.de/img/bitloading-2013-03-04yurih.png)
-
I think the random changes in bitloading data values is a bug.
One quick query. You think it is a bug. A bug in the device's firmware or in the code of Eric's utility? :-\
-
I think the random changes in bitloading data values is a bug.
One quick query. You think it is a bug. A bug in the device's firmware or in the code of Eric's utility? :-\
I wondered that too. ??? But then I only seem to see these shared tones in the evening (for fairly obvious reasons), and Eric would probably have to try hard to create a time-dependent bug, I guess, unless there was also some associated technical issue that caused it! :shrug2:
-
A bug in the device's firmware or in the code of Eric's utility? :-\
Because the raw data changes the same way these must be bugs on the device itself.
I bet broadcom is reading this forum and will fix this problems as fast as Eric would patch his program. ;)
-
A bug in the device's firmware or in the code of Eric's utility? :-\
Because the raw data changes the same way these must be bugs on the device itself.
I bet broadcom is reading this forum and will fix this problems as fast as Eric would patch his program. ;)
Yes, I agree it (the raw data) does. But this still looks like bitswapping to me. These same tones are reported as heavily bitswapped (both as tone bins and rate). So, it may not just be a reporting problem, it might be some 'flaw' in the bitswapping algorithm, which (I am happy to be corrected) I would have thought was driven more by the DSLAM? But one way or another there certainly seems to be some anomalous behavior taking place down there (in tones ~30-100)!!
Perhaps someone with their own DSLAM might be able to reproduce, or at least monitor this? Cue Asbokid? :P
-
How often are you guys harvesting the data via Eric's program?
It could just be that 'too frequent' harvesting catches bit-swapping in mid-flow i.e. before it has actually completed.
As mentioned, the 'missing' data seems to be restored after a few seconds.
The HG612 seems to also update its GUI every 10 seconds or so.
That's 6 harvests per minute plus however many times per minute you have rs-w set to harvest data may just be many harvests in any given minute.
It may not be relevant but I have caught a resync still 'training' on rare occasions via my previous scripts & now the program versions where SNRM is still reported as zero, yet sync speed is captured.
I have also occasionally seen gaps in bitloading, rectified by harvesting the data again, a few seconds later.
TBH, as I understand things, bit-swapping is a good thing as it seems to be intended in order to load as many bits as possible into the most 'receptive' tones at any given time.
On the other hand, too much may be an indication of fluctuating/intermittent 'electrical noise interference' etc?
The new BLOB for the HG612 seems to stop this 'problem' (on my connection anyway) as it seems to simply stop most of the bitloading in the 'Shared/Other' tones & moves some of the remaining bitloading to different tones.
I have now reverted to the original BLOB & bitloading in the 'Shared/Other' tones has been restored.
The slightly higher sync speed from using the new BLOB firmware has also dropped back down to the level previously provided via the original BLOB firmware.
Also, seeing sync speed higher than attainable rate isn't necessarily a 'fault'.
Quite often a connection can sync quite close to attainable rate when SNRM is at its peak during daylight hours.
As SNRM levels tend to reduce in the evenings (particularly DS SNRM) & the fact that attainable rates reduce directly in proportion to SNRM reduction, the result can be that the connection stays happily at a sync speed which is temporarily higher than attainable rate(s).
EDIT:
Here's an example:-
Max: Upstream rate = 14559 Kbps, Downstream rate = 62792 Kbps
Path: 0, Upstream rate = 14660 Kbps, Downstream rate = 62576 Kbps
SNRM is currently 6.1dB for all 3 DS bands.
If SNRM were to reduce to say 4.5dB overnight, there's every likelyhood that at some time, sync speed will be higher than attainable rate.
-
How often are you guys harvesting the data via Eric's program?
It could just be that 'too frequent' harvesting catches bit-swapping in mid-flow i.e. before it has actually completed.
TBH, as I understand things, bit-swapping is a good thing as it seems to be intended in order to load as many bits as possible into the most 'receptive' tones at any given time.
On the other hand, too much may be an indication of fluctuating/intermittent 'electrical noise interference' etc?
The new BLOB for the HG612 seems to stop this 'problem' (on my connection anyway) as it seems to simply stop most of the bitloading in the 'Shared/Other' tones & moves some of the remaining bitloading to different tones.
Thanks B-E, finger on the pulse as usual. Eric's default sampling is every 30 secs, so that would mean 8 harvests/min + your own ongoing stats. I take your point. Does the HG612 still harvest even if the Gui is not on show?
In practise (by observation) I would say that one transition, from shared tones on and higher bit-loadings, to shared tones off and lower ones, in that tone range ~30-90, takes about 3-4 of Eric's refreshes, so about 2 mins.
Glad to hear that the new blob might reduce and/or eliminate this cyclical activity by shifting the bins in use a bit. Next thing to try.
There is definately more REIN (mostly broadcast radio of one sort or another) at night, I guess for obvious reasons, and a little more now that I am on the distributed filter arrangement. However the observed behaviour predates that. So a matter of degree rather than occurrence I would think. ???
-
If I could find a way of recognising when the refreshing of the bitloading is taking place, then I could probably work around it, but I can't see any way to do this.
-
Here are 2 examples from a high speed connection where remote monitoring commenced last night.
The stats were harvested on a schedule at 22:00 last night & at 06:00 this morning.
The bitloading differences at the lower frequencies are very clear.
I can only put it down to the modem not having completed its own update at the time my program harvested the stats for our monitoring as SNR was only very slightly lower last night.
-
Here are 2 examples from a high speed connection where remote monitoring commenced last night.
The stats were harvested on a schedule at 22:00 last night & at 06:00 this morning.
The bitloading differences at the lower frequencies are very clear.
I can only put it down to the modem not having completed its own update at the time my program harvested the stats for our monitoring as SNR was only very slightly lower last night.
I have two almost identical examples :) (albeit different loop lengths), one taken as one of your manual snapshots about 22:07 last night, and the other scheduled at 08:00 this morning:
Is any one on the forum a statistician? 8) If (say) the HG612 harvests the stats from the line once every 10 secs, and this takes (I don't know) say 2 secs & you harvest once a minute from the HG612 (at an offset no. of secs), how often should the missing stats be caused by you harvesting at the same time as the HG612? All the time? Quite often? Sometimes? Almost never?
This is a very important point you are making Bald_Eagle: This is spurious ... the 'apparent' bitswapping is not real, just caused by a harvesting clash that means not all the data subsequently presented to us by either your or Eric's tools has actually been (fully) collected by the HG612 at that point. If so, and I am in absolutely no position to be able to know, how can we 'prove' it? By sampling the HG612 less frequently, or somehow finding out the HG612 schedule and avoiding it? Would that mean that it would become much less likely that there would be 'missing' tones. If so, if there were (say more than once in a reasonable period), would that mean that bitswapping was actually happening?
But I also notice that it's not just that some bins are empty ('missing'), some of the other adjacent bins also have values, albeit different (lower/higher). Could a clash cause that too? And why is it that (only) the shared tones 32-98 seem to be affected more than others? :hmm: ???
This is a fascinating debate, but I know you have by far much more extensive experience with all this than many of the rest of us put together. ;D
-
how often should the missing stats be caused ...? All the time? Quite often? Sometimes? Almost never?
I though I would take a look at the data I have already collected using B_E's can't_do_without ongoing stats logging, and see what sort of occurrences I have had. :)
Since I started monitoring on 28 March, I configured his package to take 3 scheduled snapshots a day, at midnight, 8am and 4pm. To date that's a total of 25 snapshots including 1 real DSLAM resynch, one false positive resynch, one manual snapshot and the occasional missing one.
Of those 25 snapshots, 11 have no shared tones and lower bit loadings in the lower half of D1, and 14 have the shared tones and higher bit loadings. So, empirically answering my own question, it seems to happen 'quite often' - almost 50-50%.
That seems higher than I would expect (but what do I know). The 'clocks' for harvesting in the modem and on the machine from where we take our snapshots are unlikely to be in sync (are they?), so if the time taken by the modem to update the bitloadings is small compared to the interval between updates, would a harvesting clash occur as often as this? I really don't know, but it kind of 'feels' unlikely. However, common sense, to paraphrase what Wilde said, is not so common, and quite often not very sensible either! ;D (Well, at least mine, anyway!)
On the other hand, looking at the bitswapping stats, it seems (on my line) to happen at a rate of ~10-12bits/min. So, over (say) 2mins, that's only about the same as 2 'fullish' tone bins - not enough to explain how they appear to 'vanish' in that same time period.
Does any of this help the debate? I'm as confused as I ever was. ???
-
On my connection it occurs extremely rarely. Now rs-w is running since 12 hours with a sampling time of 15 seconds. No wrong values were sent since this time.
I noticed that it affects exactly the first 1024 tones.
-
My opinion is crosstalk is most evident on the lower tones when it occurs, and crosstalk on vdsl can be brutal I mean brutal. If there is no fault with the software collecting those stats and the isnt banded (capped) then my first thoughts are crosstalk. Need to see full stats really.
-
My opinion is crosstalk is most evident on the lower tones when it occurs, and crosstalk on vdsl can be brutal I mean brutal. If there is no fault with the software collecting those stats and the isnt banded (capped) then my first thoughts are crosstalk. Need to see full stats really.
If you were referring to my own observations, then I'm sure that you're absolutely right, it is crosstalk. You can tell because my QLN noise floor is 10-20dBm higher than (say) BEs at ~-120dBm as opposed to his ~-140dBm.
I'm not surprised at all. In fact it's what I expected atm. Where I live is an area of significant broadband penetration of all kinds. Although I can't know exactly what the mix of VDSL and ADSL is on my PCP, it would not surprise me if it were >50:50 already, a matter of some discussion elsewhere. And it can only get worse until vectoring cancels some of it out. Nevertheless, because I am (fortunate to be) ~150m from a (Huawei, sorry ;)) cabinet, my attainables are of the order of 92/32 Mb/s (obviously capped lower). So, from my personal point of view, the technology is working well, within its capabilities and limitations.
-
@ Coin,
As far as I'm aware there is only one physical size of ECI cabinet which can also be identified externally from a Huawei one, as it has many more ventilation slots especially designed for friendly "visiting" dogs !
The internals are also identical for ECI 128s and ECI 256s, except for terminating IDC connector blocks and, more importantly, the number of dual Telco 64 cables/connectors. Why they haven't put all four dual Telco 64 cables in beggars belief as any that require upgrades now must require a degree of dismantling live-working cabinets. They also seem to have ignored any cross-patching capability to overcome line card faults. I can't fathom why BT don't include at least dual ducts nor why they throw away 28 or 56 connections as they never seem (at least in this part of Surrey) to install 100 pr AND a 50 pr tie cable sets.
BT were especially stupid in Ewhurst as they only installed ECI 128s despite VERY strong comments as our Vtesse Networks project BT destroyed has specified cabinets with a total capacity of 500 services EACH. Two of the cabinets have run out of capacity already and they only have single ducts to the PCPs whereas BT always install double ducts when 2 pairs of 100 pr tie cables are installed initially. The third cabinet BT "saved money" by using an existing duct with other cables installed. They got the tie cables and the fibre one in but then had to try three separate visits before they managed to insert a rod to pull in the 5 pr telemetry cable. Only the Almighty knows (at least at present) how much damage the other cables have suffered. When any expansion of ANY service - including the mythical FoD (Ha Ha Ha) fibre cables - is required, road excavation will be mandatory.
Kind regards,
Walter
-
looking at ECI's product profile the M41 seems the cheapest of the lot and combined with walter's observations it does seem BT still lack forward thinking and simply go for the cheapest of whats available again and again.
I have emailed ECI to ask if the M41 has any upgrade path to vectoring or if a complete swap of hardware is required.
-
Just getting started with monitoring my stats.
BT/OR tell me my line length is 1400m but my 3 year old pole is not on their records and I think is 1100 at most.
would somebody please pass comments on how good/bad my stats are ?.
Main question is the small number of tones in use.
Thanks
-
Well your able to use the D1 Band but the line attenuation on the D2 band is to high so the modem is unable to make use of this Band and hence the small number of tones, this would confirm your on a long line so I would go with the OR line length of 1400 meters.
There is one thing I noticed your still using the older firmware on your VDSL modem have you blocked the update or has it not been introduced to your area ? as the update may give you a slight increase in sync for the longer line EU.
-
I was once led to believe by a visiting engineer that my line length from the cabinet ws around 840m.
However, I am now aware that he hadn't taken any detours into account.
A different engineer showed me BT's actual Network Records that confirm my line firstly travels away from the direction of my home to a convenient road crossing.
It then goes past my house to a joint chamber, before doubling back to the pole mounted DP.
These detours add somewhere around 150m to 200m (maybe a little more) to my line's length, thus my physical line length is somewhere between 1000m & 1100m (or slightly more).
As mentioned by NewtronStar, the attenuation in the D2 band is too high for any use to be made of it & so high that not all the U1 band can be used.
You have a lower baseline of background noise than my connection, although it is quite 'spiky'.
I also see that quite unusually, Interleaving (albeit at quite a low depth) has been applied to your US, probably the reason for such low US attainable (Max) & sync speed (Path).
Unless you have blocked it, your modem's firmware is likely to be remotely updated within a few days.
The update, using a slightly different configuration of tones does appear to slightly assist longer connections.
Increased DS bitswapping is seen when using the updated firmware & FEC errors generally increase.
However, it does appear to make longer connections slightly more stable & able to slightly improve sync speeds.
Have you started logging/monitoring ongoing stats 24/7?
If so, you may be able to see patterns of fluctuating SNR, error counts etc.
Although, it does appear that your connection is longer than maine and/or it may include section(s) of aluminium cabling.
Is your connection stable, usually managing to stay up for many days at a time?
Mine used to resync every few days, but it recently stayed up for 50 days before I forced a resync & it has been up for over 16 days at the time of posting.
Before crosstalk started to affect my connection, it was able tosync at not much below 30/7.
However, I did see from monitoring ongoing stats, that noise has worsened (QLN) & Attainable/sync speeds deteriorated.
This happened in a few steps over around 8 months, which is probably attributed to additional users being connected at my cabinet.
I was one of the first to be connected, June 2011, so I didn't see much of an effect from crosstalk.
I have attached my snapshot montage from 10:00 this morning for you to compare against your own.
-
. . . thus my physical line length is somewhere between 100mm & 1100m (or slightly more).
<Cough!> ::)
-
Wishful thinking? ???
-
. . . thus my physical line length is somewhere between 1000mm & 1100m (or slightly more).
<Double cough!> :-X
-
Struggling with a furball there b*cat?
O.K. 3rd time lucky then :-[
-
Struggling with a furball there b*cat?
<Nods.>
O.K. 3rd time luck then :-[
Shall we make that "lucky"? :P
-
Multi-tasking is a woman's job isn't it?
That's my excuse anyway & I'm sticking to it :lol:
-
Thanks everybody for useful comments and here is a bit of background.
My 5 week old fibre installation was supplied with a ECI/r which I read has better speeds.
My HG612 I bought 18 months ago and when I discovered I could not get stats from the ECI I connected the 612 yesterday.
I'm slowly coming to grips with the monitoring.
For a long time my 2.5 mile ADSL gave me 2.5Mb down before dropping to 1.34.
Over a few weeks several BT/OR helpful engineers did their best to restore it to no avail ending up with ** the cable has probably depreciated and that's the best it can now achieve.**, it's always been stable but s l o w.
Roll on a few years and FTTC finally available, I'm first on the cabinet getting 25Mb down but a low 1.5 up which after a few days settles to 20/1.2
ISP arranged BT/OR engineer does his best and I end up with 20/2.2 ( bit better, no pun intended ) my ping is anything between 60 and 16.
He says the records show my line length to be 1400m, but the new pole installed 3/4 years ago is not on his plan, confirms no taps or aluminium.
My previous drop wire feed from a pole at the rear very likely is 1400Mts but the new pole in the front is at least 260Mts shorter.
Due to the road layout, in a valley one road up/down and having watched the OR guys pull the fibre, ( as you do ) its clear the main ducting runs along the main road.
Also having previously watched them install the new pole and feed ducting from a chamber I think using Google Earth I can measure the cable length quite accurately give or take a bit !, the only unknown part is the chamber to main duct, so I think is total is 1100Mts max, the downs about right but the up !..
Because of the ADSL history I still feel I have one or more poor connections in the last leg.
The disparity of the figures from the BTW can I get FTTC site, were 23.7 to 17 down, 4.7 to 2.8 up, so from the off the down was higher and the up was very low.
I know a user who is 470Mts from the cab and reports 60/13, from published, what you could expect, 1250m,17/5 and 500m 38/15 so he is a very lucky boy to be getting 60Mb down but his up is what you would expect !..
I fully understand the down/up operate at different frequencies but................
The 612 modem flashed firmware is with no BT agent, and as the ECI is reported as faster I'll probably put it back sometime, right now I'm interested in stability and having an idea whats going on, left a computer running overnight monitoring but this morning it had stopped with several errors so that's work in progress.
Thanks
-
If you're prepared to put your postcode on, I may be able to deduce the actual cable length ??
-
PM delivered. :)
-
@ Coin,
As far as I'm aware there is only one physical size of ECI cabinet which can also be identified externally from a Huawei one, as it has many more ventilation slots especially designed for friendly "visiting" dogs !
The internals are also identical for ECI 128s and ECI 256s, except for terminating IDC connector blocks and, more importantly, the number of dual Telco 64 cables/connectors. Why they haven't put all four dual Telco 64 cables in beggars belief as any that require upgrades now must require a degree of dismantling live-working cabinets. They also seem to have ignored any cross-patching capability to overcome line card faults. I can't fathom why BT don't include at least dual ducts nor why they throw away 28 or 56 connections as they never seem (at least in this part of Surrey) to install 100 pr AND a 50 pr tie cable sets.
BT were especially stupid in Ewhurst as they only installed ECI 128s despite VERY strong comments as our Vtesse Networks project BT destroyed has specified cabinets with a total capacity of 500 services EACH. Two of the cabinets have run out of capacity already and they only have single ducts to the PCPs whereas BT always install double ducts when 2 pairs of 100 pr tie cables are installed initially. The third cabinet BT "saved money" by using an existing duct with other cables installed. They got the tie cables and the fibre one in but then had to try three separate visits before they managed to insert a rod to pull in the 5 pr telemetry cable. Only the Almighty knows (at least at present) how much damage the other cables have suffered. When any expansion of ANY service - including the mythical FoD (Ha Ha Ha) fibre cables - is required, road excavation will be mandatory.
Kind regards,
Walter
Walter, for information (via a quote from one of our elite) ...... 'We currently have 142 exchanges enabled for FoD and will continue to enable exchanges on a quarterly basis. We are due to announce a further 161 exchanges in March which will be enabled by the end of that month'.
-
With some professional help I now know my cable length is 1225 mts against BTW saying it's 1400 and I would be grateful for any comments on the attached graphs.
My starting point is of course I would like it to be faster !, it has been pointed out My 612 does not have the latest firmware which would gain a bit more throughput but I did not want the complication of the upgrade removing the GUI Etc and I'll probably put my ECI/r back later or I may buy a integrated unit.
Do you think that 1225 mts would be long enough to prevent anything over tone 1149 being usable ?
The BTW website estimate was 23.7-17 and 4.7 - 2.8, as the max it looked as though I was going to get was 25 Mb I ordered a 40/10 package and I wonder how the restriction is done and might there be an error in it's setup ?.
My ADSL router reported a line attenuation of 63.5, whilst I understand that was probably the highest number it could display and so could have been higher, I was getting 1.34/0.448 on some 4850 mts of cable, if I have understood correctly the HG612 is reporting 25.7, 75.8 and 102.3 on higher frequency signals, do these look reasonable ?.
I was also intrigued to learn that the old ADSL Dslam was not disconnected at the time of the FTTC install as I would have thought it would/might cause interference with them both active but I'm told the Fibre Dslam contains a filter removing them.
I have Googled Quiet Line Test but have not found anything that might explain the graph here, is it good or bad ?.
The xdslcmd page shows a Max downstream is 25200 using 20114 and a upstream rate of 15604 and using 2651, is that an error of the program ?, my actual upstream rate is below the BTW estimate and the up is above the lowest.
And finally, do the Adsl BRAS step rates apply in the same way to Vdsl as there seems to be quite a big step between 25Mb max and 20Mb achieved ?.
I am mindful that BE1 has reported a sync rate on a similar line length of 30/7 (yes please )
Thanks.
-
With some professional help I now know my cable length is 1225 mts against BTW saying it's 1400 and I would be grateful for any comments on the attached graphs.
My starting point is of course I would like it to be faster !, it has been pointed out My 612 does not have the latest firmware which would gain a bit more throughput but I did not want the complication of the upgrade removing the GUI Etc and I'll probably put my ECI/r back later or I may buy a integrated unit.
If you do that, you will lose access to the detailed stats.
The bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_unlockedgui firmware image from the 'Experimental' area accessed via the link below appears to work very well & it does re-enble the GUI:-
https://mega.co.nz/#F!LdJFDIJL!e_E1twsIg2kTet8mPjrb4w
Unlike the original firmware images, the updated images do also report US data for QLN, SNR & Hlog.
Do you think that 1225 mts would be long enough to prevent anything over tone 1149 being usable ?
In a word, yes.
The BTW website estimate was 23.7-17 and 4.7 - 2.8, as the max it looked as though I was going to get was 25 Mb I ordered a 40/10 package and I wonder how the restriction is done and might there be an error in it's setup ?.
My ADSL router reported a line attenuation of 63.5, whilst I understand that was probably the highest number it could display and so could have been higher, I was getting 1.34/0.448 on some 4850 mts of cable, if I have understood correctly the HG612 is reporting 25.7, 75.8 and 102.3 on higher frequency signals, do these look reasonable ?.
They look reasonable for a line length of 1225m or slightly longer, when taking any 'slack', up & down the pole, drop wire length etc. into acount.
At anything over 70dB Line Attenuation, signal attenuation is likely to be even worse i.e. unuseable.
The updated images do now show Signal attenuation differently:-
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 8.0 52.6 N/A N/A N/A 21.5 64.6 N/A
Signal Attenuation(dB): 8.0 52.3 N/A N/A N/A 30.1 64.3 N/A
I was also intrigued to learn that the old ADSL Dslam was not disconnected at the time of the FTTC install as I would have thought it would/might cause interference with them both active but I'm told the Fibre Dslam contains a filter removing them.
I have Googled Quiet Line Test but have not found anything that might explain the graph here, is it good or bad ?.
It has a reasonable base level of around -140dB, but the many spikes to -120dB or so do indicate quite a lot of noise 'interference' at the time the connection resynced
The xdslcmd page shows a Max downstream is 25200 using 20114 and a upstream rate of 15604 and using 2651, is that an error of the program ?, my actual upstream rate is below the BTW estimate and the up is above the lowest.
15604 Kbps Attainable (Max) US is impossible over your line length.
2651 Kbps is more realistic.
I would very much like to see the raw data from the Plink log that was used to generate your montage.
Something isn't right.
Are you able to zip that Plink log down to a size that can be posted in this forum?
There is no way that US SNR can really be 6502.4 dB as shown in the xdslcmd info --show data.
Neither can all the US SNRM data actually be N/A as shown in the xdslcmd info --pbParams data.
Does the Portrait montage also show the same (incorrect) data?
If so, my 'guess' is that you have somehow gathered spurious data.
Maybe the modem was in mid-flow of updating its stored data just at the same time you obtained the data to generate the graphs.
All the data shown in your montage from 1st March is more realistic.
And finally, do the Adsl BRAS step rates apply in the same way to Vdsl as there seems to be quite a big step between 25Mb max and 20Mb achieved ?.
I am mindful that BE1 has reported a sync rate on a similar line length of 30/7 (yes please )
Your connection has a DS Interleaving depth of 467 (fairly low), but US Interleaving depth of 57 is quite high (it is usually only 1, i.e. OFF on a problem free connection).
Do you have any ongoing graphs/data that we could see to determine if there is any obvious pattern to the noise 'interference' levels?
Finally, your Hlog graph has worsened since 1st March, indicating a possible issue.
Even though it's not at tones/frequencies your connection can actually use, it MIGHT be having some effect on those it can use.
-
BE1, Thanks, Before I break it, again, can I please confirm my understanding of your reply.
I have read on the forum somewhere that in some cases the BT upgrade removed the GUI and I thought it said that (at that time ) it could not be put back which is why I thought it best to flash with No Bt agent. ( I do need to change it's IP address )
Is the firmware you suggested capable of putting the GUI back even if it's removed by BT ?. ( not sure if it gets removed or just disabled, again )
I have not been able to capture the ongoing graphs, I did have set 23.58 but it did not save.
I then had 12 o'clock save ticked which I checked at 10am this morning but coming back to the laptop around 15.30 I woke up the screen to discover it had froze.
I have checked and I'm not set to hibernate only turn off HD after 10 Mins and screen after 30 Mins.
After a Windows restart I have now set to 18.00 and the current uptime is 1 day 21 hrs with a retrain reason of 0 and still shows the same large upstream attainable.
So as not to "annoy" the Dslam I have not power cycled the modem, from memory when I first connected the flashed 612 I'm sure Interleave was off, I can't find that information in the snapshots although the upstream Max was then 3055.
We are both showing version 4.1 but you have more information lines than me, I think when I selected the snapshot it checked for updates and I think it did a download ?, my plink from that is attached.
Yes, my portrait montage show the same data.
Re line length, we have allowed for the slack and up/down poles.
Thx.
I have now been able to capture the ongoing stats, there is corruption in the labels on all graphs, what would you like to see ?
-
BE1, Thanks, Before I break it, again, can I please confirm my understanding of your reply.
I have read on the forum somewhere that in some cases the BT upgrade removed the GUI and I thought it said that (at that time ) it could not be put back which is why I thought it best to flash with No Bt agent. ( I do need to change it's IP address )
Is the firmware you suggested capable of putting the GUI back even if it's removed by BT ?. ( not sure if it gets removed or just disabled, again )
Yes it does restore the GUI where you can change the IP Address etc.
I have not been able to capture the ongoing graphs, I did have set 23.58 but it did not save.
I then had 12 o'clock save ticked which I checked at 10am this morning but coming back to the laptop around 15.30 I woke up the screen to discover it had froze.
I have checked and I'm not set to hibernate only turn off HD after 10 Mins and screen after 30 Mins.
I don't think those settings should cause any problems.
After a Windows restart I have now set to 18.00 and the current uptime is 1 day 21 hrs with a retrain reason of 0 and still shows the same large upstream attainable.
So as not to "annoy" the Dslam I have not power cycled the modem, from memory when I first connected the flashed 612 I'm sure Interleave was off, I can't find that information in the snapshots although the upstream Max was then 3055.
We are both showing version 4.1 but you have more information lines than me, I think when I selected the snapshot it checked for updates and I think it did a download ?, my plink from that is attached.
The firmware version you are using (DSL PHY: AnnexA version - A2pv6C035m.d22g) shouldn't cause any problems, but it does generate fewer rows of data for the Plink log than the updated firmware versions.
My programs don't actually download anything (if you mean via the internet).
The Stats logging GUI, written by RONSKI, does check for its latest version each time it is started though (if you have that option selected in the GUI settings tab).
Yes, my portrait montage show the same data.
Re line length, we have allowed for the slack and up/down poles.
I have now been able to capture the ongoing stats, there is corruption in the labels on all graphs, what would you like to see ?
I have attached a zip file containing the latest versions of the programs that I have worked on recently.
Could you unzip them into the Scripts folder, overwiting the current versions?
Then check your clock is somewhere around 30 seconds past the minute & run this batch file:-
HG612_stats_to_TXT_file.BAT
It will run HG612_stats.exe in the background & create a text file named HG612_stats.TXT that stores the program flow data that is usually not seen.
After you have done that, zipped copies of these files will help to pin down where things are going wrong:-
From the Ongoing_Stats folder:-
ERROR.LOG
ERROR.LOG_file_ERROR.TXT
xlogfile.txt
modem_stats.log
From the Current_Stats folder:-
RESYNC.LOG
Current_ERROR.LOG
From the Scripts folder:-
HG612_stats.TXT
Login_events.TXT
info.txt
HG612_stats.ini
I don't think it's a program problem as you are the first person to have reported corrupted graph labels & I have not previously seen such odd attainable rates & spurious US SNRM values.
EDIT:
Programs from 6th March removed & replaced with programs from 8th, lower down this thread.
-
With some professional help I now know my cable length is 1225 mts against BTW saying it's 1400 and I would be grateful for any comments on the attached graphs.
My starting point is of course I would like it to be faster !, it has been pointed out My 612 does not have the latest firmware which would gain a bit more throughput but I did not want the complication of the upgrade removing the GUI Etc and I'll probably put my ECI/r back later or I may buy a integrated unit.
If you do that, you will lose access to the detailed stats.
Just to show that the firmware BE1 has highlighted the GUI is back and working well ;)
-
Hi All.
Thanks Guys, much appreciate the help being given here !.
BE1, I have downloaded the zip file which you said I should/could copy into the script folder.
I was surprised to see the tree in the screen capture, thought I would just check that I just copy the files in the script folder and ignore the rest ?,
I know they are all empty but, just need to be sure before I mess it up, doesn't take much to confuse me as it's not like the tree I have installed.
-
Apologies for that.
I didn't intend to include the tree from my testing folders.
I have attached another zip file without the tree (also slightly amended programs).
-
Thanks B_E1. and no probs.
I'm on the case.