Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: NewtronStar on June 26, 2012, 07:42:24 PM
-
I am looking into my Stats and trying to understand most of it but, Line Attenuation & signal Attenuation I am searching the net to get an answer what the differences are ?
-
http://forum.kitz.co.uk/index.php/topic,11279.0.html
Hope this helps
-
Cheers Kitz
That solves my confusion , the D1 & D2 are both identical on Signal Att & Line Att, just a slight difference from U0 & U1.
(http://)
-
D3 is still missing due to needing to change the font size at the top of GRAPH6.BAT
rem ***** Vista *****
set FONT_USED=courier-new -pointsize 12
-
ok thanks Bald_Eagle1 I did a full re-install of HG612 stats because the first time I intalled it I did not have a clue what was going on, but this is excellent software !
I'll change that font size on GRAPH6.BAT
-
Have looked at Vista the Font size for Graph6 is as follows
-
If you're not sure what to change, just replace what you have with this:-
rem ***** Set the font & size for different Windows versions *****
rem ***** Windows 7 *****
rem set FONT_USED=courier-new -pointsize 14
rem ***** Vista *****
set FONT_USED=courier-new -pointsize 12
rem ***** XP *****
rem set FONT_USED=courier-new -pointsize 14
-
What I have and in the graph6 and in your last post is exactly the same so I don't need to change any font size for Vista its set at Courier-New -pointsize 12
Any other fixes for me to see D3 ?
Ps I have not changed or Modified the Graph6.bat font sizes
-
Sorry Bald_Eagle1
I should edit Vista as
rem ***** Vista *****
set FONT_USED=courier-new -pointsize 12
sorry my misunderstanding :-[
-
Is this what it should look like BE1
-
ok i don't have D3 (0.1) in Signal ATT ?
-
ok i don't have D3 (0.1) in Signal ATT ?
That indicates that the D3 band isn't being utilised. Typically because there is high attenuation for the tones in D3, and the signal-noise ratio for the tones in that band fall primarily below the SNR margin.
So that possibly also answers your other question of why line attenuation and signal attenuation are different. Line attenuation shows the aggregate attenuation across the tones allocated during the medley stage for that band, while signal attenuation is an aggregate calculation based only on utilised tones in a band.
As c6em notes in the link provided by kitz, there is a mathematical equation for calculating aggregate attenuation which is given by..
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.texify.com%2Fimg%2FAttn%255BdB%255D%253D10%2520%255Ccdot%2520%255Clog_%257B10%257D%2520%255C%255B%2520%255Cfrac%2520%257B%2520%255Csum_%257Bi%253D0%257D%255E%257BNSC%257D%2520%257B%257B10%257D%255E%257B%255C%2528%255Cfrac%2520%257BHlog%2528i%2520%255Ccdot%2520%255CDelta%2520f%2529%257D%257B20%257D%255C%2529%257D%257D%255E%257B2%257D%257D%257BNSC%257D%2520%255C%255D.gif&hash=ab012aae477e1e6e5ad8ceb3aacc0528aef5375f)
It initially looks daunting, but it's not.. NSC=number of Sub-Carriers, and delta f is the subcarrier spacing (4312.5Hz)
cheers, a
-
Seems Max Download has gone down since HG612 was turned off due to unlock firmware (Day 2)
But SNR goes down in the evening to 5.4 to 6.3 during the afternoon.
I guess the D3 Band is not being utilised because I am on Infinity 1 40/10 and Infinty 2 uses utilises D3 80/20
-
I see you have gone back to your original GRAPH6.BAT & edited the Vista font thing.
I guess the D3 Band is not being utilised because I am on Infinity 1 40/10 and Infinty 2 uses utilises D3 80/20
Well yes, 80/20 (if the higher speeds can actually be achieved) does use D3.
However, 40/2 & 40/10 can also use D3, if attenuation is not too high.
I have attached an example of a 40/10 connection that does indeed use D3 as attenuation is NOT too high.
The example is from a 400m connection.
-
But that Max downstream rate is hiting 66megs thats in the 80/20 profile Bald_Eagle1 it not a 40/2 or 40/10
That Graph show a person stuck on a 40/10 they should be 80/20 :o
-
That is the attainable rate.
But you can see the sync speed is capped at 39998 & 10000 i.e. a 40/10 service.
All the 80/20 service does is change the cap up to 80/20.
Some connections have up to 130 Mb Attainable, with really high SNRM (loads to spare) & really low attenuation, yet are still capped at 40/10.
I trialled the 80/20 service with my ISP as an experiment, but I could still only use D1 & D2 due to high attenuation, with actual sync speeds still around 30/5.
This example is around 50m from the cabinet, but still capped on a 40/10 service.
-
But that Max downstream rate is hiting 66megs thats in the 80/20 profile Bald_Eagle1 it not a 40/2 or 40/10
That Graph show a person stuck on a 40/10 they should be 80/20 :o
It actually shows a person who has either chosen not to use the 80/20 service or is with an ISP that doesn't yet offer 80/20.
-
Replaced the Graph6 Batch file with the one I downloaded from you yesterday I made a copy of it before reinstalling HG612 Stats V2.0, I am really getting into this software cheers.
Ok the guy was testing 80/20 must be a TT customer looks like they will need to wait a wee bit longer to Iron out the bugs ;D
-
But that Max downstream rate is hiting 66megs thats in the 80/20 profile Bald_Eagle1 it not a 40/2 or 40/10
That Graph show a person stuck on a 40/10 they should be 80/20 :o
It actually shows a person who has either chosen not to use the 80/20 service or is with an ISP that doesn't yet offer 80/20.
That looks like the data I recently obtained from Gordon's line! His ISP is Beatie Retail and he is quite happy with her Infinity 1 Service (40/10). ;D
-
Well I whish it was My VDSL2 stats Burakkucat funny the more you get the more you want :-[
-
That looks like the data I recently obtained from Gordon's line! His ISP is Beatie Retail and he is quite happy with her Infinity 1 Service (40/10). ;D
Thank you b*cat.
I hoped you would recognise it & pass suitable confirmation of 40/10 service comments accordingly :)
-
Thank you b*cat.
I hoped you would recognise it & pass suitable confirmation of 40/10 service comments accordingly :)
You're welcome. "Team work" prevails. ;D
-
No worrys Guys I will only post if i need help on the forum !!!
-
?
-
Its ok Kitz I am way to much of a newbie to help other Members out with there problems on the forum I'll start slowly ;D
-
I am currently running a 14 day 1 minute sample but looking at the ongoing stats it seems to have stopped logging but I can here the HardDrive thrashing every minute or so.
I turn off My PC at night before I go to bed !
-
I am currently running a 14 day 1 minute sample but looking at the ongoing stats it seems to have stopped logging but I can here the HardDrive thrashing every minute or so.
I think you will need the help of our Bald_Eagle1 to resolve that minor "mishap".
I turn off My PC at night before I go to bed !
Eh? ??? Then you cannot be "running a 14 day 1 minute sample"! :-X
-
Thanks Burakkucat
Your gonna tell me I can't turn off the PC or the 14 day logger won't work :'(
But looking at the ongoing_stats (modem Stats) text document the stats are still logging but the Graph has not updated ?
-
I am currently running a 14 day 1 minute sample but looking at the ongoing stats it seems to have stopped logging but I can here the HardDrive thrashing every minute or so.
I turn off My PC at night before I go to bed !
The time along the x axis stays in a more readable order if plotting in multiples of 4, e.g. 12 days or 16 days.
You won't be able to plot 12, 14, 16 days etc. until you have that amount of data.
The scripts assume continuous data collection (especially overnight as that is quite often when DLM has it's wicked way with our connections, perhaps hoping we won't notice as most of us are snugly tucked up in bed).
When the PC is turned off, the scripts can't actually log anything, so you end up with even fewer 1 minute samples.
Let's say you switch off for 8 hours overnight.
That means you will only be recording 16 hours of 1 minute samples per day.
16 x 60 = 960 samples per day.
Then you try to plot 1 day of samples which should be 1440 samples.
You will end up with incorrectly plotted graphs where the times are wrong & more or less unusable for detailed monitoring purposes.
The first attachment is from me trying to plot 8 days, but only having 5 days or so of data.
The 2nd attachment is the same data file, but only plotting 4 days.
-
Thanks I have been able to get the graph in sync again, I go to scripts then Graphpd and select 14 d again, it then adds a new folder in ongoing_stats
I am happy with the results but as you say I am not getting a true picture of my stats because I turn off PC (150 watts) * 24/7 no thank you thats 6 energy saving light bulbs left on all week.
But I can see already with RsUncorr & Hec errors as we had thunder storms from 6.30pm to-day untill 9pm
-
Thanks I have been able to get the graph in sync again, I go to scripts then Graphpd and select 14 d again, it then adds a new folder in ongoing_stats
I am happy with the results but as you say I am not getting a true picture of my stats because I turn off PC (150 watts) * 24/7 no thank you thats 6 energy saving light bulbs left on all week.
But I can see already with RsUncorr & Hec errors as we had thunder storms from 6.30pm to-day untill 9pm
Just for fun & as an experiment, why don't you try graphing the data that you actually have rather than data that you don't have yet?
i.e. Try graphing 1 day, 2 days, 3 days, 6 hours, 12 hours, 18 hours etc. & then post some of those for us to have a look at.
It might just give a better/truer understanding of the timing an nature of any of "events".
You clearly don't have 14 days of data yet.
Yes, each time graphs are plotted a new folder will be created (as long as a gap of at least 1 minute is allowed between each time you run graphpd.BAT)
-
Who wrote the Scripts and Apps for the HG612 logger, I am sure donations would be much appreciated by the programmer as this is worth a £10 or so.
-
I did as asked and have a Graph still there are two spikes in FEC errors and uncorrectable errors due to two T Storms one at 18.30 yesterday and to-day at 17.30 but looking at attainable Download rate there is a pattern evolving seems to be at 22:00 .
I am starting to wonder if that attainable Rate is due to me turning on my Dimmer switch as the HG612 is 3 feet from it and at 22:00 it starts to get dark in this room, I am only guessing.
-
. . . due to me turning on my Dimmer switch as the HG612 is 3 feet from it and at 22:00 it starts to get dark in this room, I am only guessing.
Ah, now that is significant. Dimmer switches can be pure evil to xDSL signals, as they tend to "splatter" noise across the RF spectrum. I would go as far to say that they are the work of the devil and anyone who has one fitted should be prepared to accept xDSL issues as a result!
The next steps in your diagnosis will be: (1) set up some alternative mode of room lighting (2) try turning the lights on full, don't attempt to dim them. A couple of days trying out each of the above may yield interesting results.
Just between the two of us . . . Those graphing scripts are the result of some excellent work by a certain bird-of-prey, who has no feathers "up top". ::)
-
Is the programmer that has no feathers on top accept paypal donation or should I just donate to kitz !
Cheers Burakkucat I used My Yupiteru 7300EU radio scanner and notice alot of interference when I used the dimmer light switch (REIN) at 612khz what a mess.
-
Donate to bald eagle.. all the HG612 stuff is his hard work and nothing to do with me....
... although I think a couple of other forum members from here such as a certain black cat and asbo did have some input too?
----
edited edit.
Yep, just seen BE's latest post... B*cat and asbokid did have their mitts in there too :)
-
One other thing to be mindful of is that whenever the scripts recommence logging e.g. when the PC is switched back on again, they "catch" up with the modem's stats that are clocking up all the time the modem is switched on, regardless of the PC and or router being switched on or off.
This can sometimes appear as a sudden burst of errors that wouldn't show as a burst if the scripts had been logging throughout.
One way to deal with that would be to delete the offending "catching up" row in modem_stats.log each time the scripts recommence their data logging.
The other alternative would be to leave the scripts logging 24/7 so that any changes will be shown more gradually as the data is that way updated every minute.
I'm not a great fan of dimmer switches either.
Even when switched on full, a humming/buzzing sound can quite often be heard that probably causes some interference on xDSL signals, especially at the higher/weaker frequencies involved in VDSL2 provision.
Just between the two of us... If a certain black feline (who doesn't even have a VDSL2 connection of his own to play with) hadn't stuck his paw in many months ago, these Windows scripts wouldn't even exist at all, especially if that kid with an asbo against his name hadn't found the unlocking key for us in the first place.
EDIT:
Make the donation toward your electricity bill, so that you could run the scripts 24/7 for a full week (8 days would be better) ;)
-
LOL ok 150 watts * 24 hrs = 3.6 kilowatts * 7 (7 days) = 25.2 kilowatts =£3.90 at 0.156p per unit
-
I used My Yupiteru 7300EU radio scanner and notice alot of interference when I used the dimmer light switch (REIN) at 612khz what a mess.
I use an ICOM IC-R5. :) Have you tried listening around 300 - 306 kHz? The LCD screen of my laptop and the laptop's PSU are both rather noisy. :(
If a certain black feline (who doesn't even have a VDSL2 connection of his own to play with) hadn't stuck his paw in many months ago, <snip>
All member of the species Felis Domesticus are born inquisitive -- it is a fact of nature.
LOL ok 150 watts * 24 hrs = 3.6 kilowatts * 7 (7 days) = 25.2 kilowatts =£3.90 at 0.156p per unit
. . . leaving you with enough left over for some "throat embrocation". ;) :drink:
-
Boy I am having problems with accessing the Internet seems to be better had to reset HH3 and HG612 but I think is was a BT DNS problem had this in the morning as well.
The Yupiteru picks up the LCD wide screen moniter as loud and clear but its range is around a foot
I have Three Felis Domesticus which is a big chunk out of are weekly grocery bill :P
-
Boy I am having problems with accessing the Internet seems to be better had to reset HH3 and HG612 but I think is was a BT DNS problem had this in the morning as well.
Ah,
I wonder if that could also explain some strange results from another connection (BT Infinity) that is being monitored 24/7.
SNRM etc. looks good, but RSCorr errors suddenly shot through the roof last night & continued this morning:-
-
It seems ok to-day but last night just after 00:31 all IE pages stopped working but all dsl lights were on I should not have bothered turning off router and modem because it made no difference only now I have lost 1 meg sync.
-
Those 7 million errors from when you recommenced logging & the scripts played catch up with the modem's stats at around noon today are masking any of the "normal" error counts.
Perhaps you could delete the "offending" row from your modem_stats.log to make it look sensible & useful again.
-
ok Bald_eagle1 will look through the modem.stats.log and see if I can find the line with a million errors it will take me while as I am still very new to this logger :)
-
29/06/2012 00:30
29/06/2012 00:31
29/06/2012 00:32
29/06/2012 00:33
29/06/2012 12:00
29/06/2012 12:01
29/06/2012 12:02
29/06/2012 12:03
It should look a bit like the above, where the time suddenly changes by a few hours or so.
The first row of the times starting to clock up every minute again should be the one to delete.
-
BT had a big maintenance overhall that started at 23:45 (28/6/2012) this caused a widespread BB slowdowns and full Disconnections it was fully fixed at 8:00 (29/6/2012) I have asked BTOR to ring me before they do this again :D
-
Hi have had the PC on for 12 hours I did some edititing in the Stats_log again its scratchy as I am turning off PC sorry.
Also when starting a new Log I get this in the cmd window
-
12 hour graph
-
That all looks quite steady now.
What caused the gap between 23:00 & 23:30?
Also, what caused the resync at a slightly lower speed at not much before 01:00 on 29th?
Your sync speeds are now very similar to mine (your US is a bit higher).
Could you post your xdslcmd info --pbParams for me to compare against mine (or preferably a zipped Plink log that will be small enough to post in this forum):-
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 4698 Kbps, Downstream rate = 33224 Kbps
Path: 0, Upstream rate = 4818 Kbps, Downstream rate = 28085 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207)
DS: (32,859) (1216,1963)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 4698 kbps 33224 kbps
Actual Aggregate Tx Power: 6.3 dBm 12.4 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 8.4 54.8 77.8 N/A 21.9 64.5 0.1
Signal Attenuation(dB): 9.3 54.3 N/A N/A 21.9 64.5 N/A
SNR Margin(dB): 5.7 5.8 N/A N/A 6.3 6.5 N/A
TX Power(dBm): -4.4 5.8 N/A N/A 11.4 5.3 N/A
#
-
Hi have had the PC on for 12 hours I did some edititing in the Stats_log again its scratchy as I am turning off PC sorry.
Also when starting a new Log I get this in the cmd window
That just means you are trying to plot more data samples than are actually stored in modem_stats.log
-
The Re Sync Issue you saw that, The BT outage on Friday 00:30 Internet went down for 1 hour I turned off HH3 & HG612 but it did not fix it, only found out on Friday afternoon BT where doing a large Maintenance upgrade that effected a large part of the UK, I have lost another Meg and others on BT Forums have also lost sync speed.
I guess its my fault I should not have turned off HG612 during the outage :'(
the one the that seems to have changed is the D1 D2 Snr Margin from 6.1 to 6.8
-
the one the that seems to have changed is the D1 D2 Snr Margin from 6.1 to 6.8
Target SNRM when the modem syncs is 6dB.
While it is connecting, line conditions are examined & a "suitable" sync speed is achieved.
Throughout the day/night conditions will fluctuate as people switch electrical equipment on/off etc. making the connection "noisier" or "quieter".
Your increased SNRM suggests that your connection could achieve a little more speed if you had synced at the time you grabbed the stats (not much more though).
SNRM tends to rise a little during the day & lower a little during the night.
You attenuation (Hlog), QLN & SNR are slightly better than mine & thus your connection is able to load more bits in the D2 band than mine.
However, your D1 band looks quite a bit noisier than mine & thus your connection has a large dip in bit loading in the D1 band (usually the best bitloading band as it is the lowest frequencies & so is the least attenuated).
I have attached your montage to compare against mine as shown in the post a little higher up this thread.
-
Thanks Bald_eagle1 I am wondering what the shared/other is in the Band Plan graph that shows as blue ?
Is it the Voice (Telephone) !
Ok D1 band looking at yours and mine and see the dip in my lower Band, I might stick the dsl lead straight into master socket and see if extension wire to Data socket is causing this ??
-
Thanks Bald_eagle1 I am wondering what the shared/other is in the Band Plan graph that shows as blue ?
Is it the Voice (Telephone) !
No, it's for the shared US & DS tones & anything else (other) that has some bits loaded but isn't really part of the band plans.
I don't know how to distinguish between shared US & DS as they are all shown in the same column in the modem's stats.
It is the scripts that splits them up.
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
You can see that US uses tones 0 to 95, yet DS uses tones 32 to 859.
Therefore tones 32 to 95 must be shared.
Ok D1 band looking at yours and mine and see the dip in my lower Band, I might stick the dsl lead straight into master socket and see if extension wire to Data socket is causing this ??
It might be worth a try.
Were the extension wire & data socket installed by the engineer, or are they your own additions?
-
BTOR used my existing extension wiring they just installed the Data Kit socket.
-
I have been using a Lamp in the room for two days to see if the Dimmer Light switch was interfering with HG612 can you see the difference ?
-
Hello I see Retrain reason 2 in my current stats tonight, whats this about ?
-
Well, on Broadcom based chips running standard ADSL, reason 2 is negative margin
whether that applies to your setup/router/FTTC service I have no idea.
-
Hello I see Retrain reason 2 in my current stats tonight, whats this about ?
I think Reason 0 = reboot or power off & on again & Reason 2 = "on the fly" resync.
Messing about with logging & time server settings seems to have caused resyncs last night.
It did the same on my connection too.
-
I have been using a Lamp in the room for two days to see if the Dimmer Light switch was interfering with HG612 can you see the difference ?
It's a bit hard to tell exactly what's going on with all the gaps in the data, but it seems to be showing fewer errors?
Didn't you mention that you had started logging 24/7?
-
Thankyou Bald_Eagle1 & c6em regarding Retrain explanation, and the re-sync of modem 1-2pm has got me Back the 1 Meg , Its silly all that for 1 lost Meg I know but it's all good fun ;)
-
Well, on Broadcom based chips running standard ADSL, reason 2 is negative margin
whether that applies to your setup/router/FTTC service I have no idea.
I posted some duff info about this on thinkbroadband, but it's too long ago to correct..
GrahamC posted Retrain Codes in this message on the plus.net forum [1]
It looks like Graham got the Codes from the source code for Broadcom's DSL driver [2]
/* line-drop reason code */
#define kRetrainReasonLosDetector 0
#define kRetrainReasonRdiDetector 1
#define kRetrainReasonNegativeMargin 2
#define kRetrainReasonTooManyUsFEC 3
#define kRetrainReasonCReverb1Misdetection 4
#define kRetrainReasonTeqDsp 5
#define kRetrainReasonAnsiTonePowerChange 6
#define kRetrainReasonIfftSizeChange 7
#define kRetrainReasonRackChange 8
#define kRetrainReasonVendorIdSync 9
#define kRetrainReasonTargetMarginSync 10
#define kRetrainReasonToneOrderingException 11
#define kRetrainReasonCommandHandler 12
#define kRetrainReasonDslStartPhysicalLayerCmd 13
#define kRetrainReasonUnknown 14
#define kRetrainReasonG992Failure 15
#define kRetrainReasonSes 16
#define kRetrainReasonCoMinMargin 17
cheers, a
[1] http://community.plus.net/forum/?topic=104948.msg894217
[2] http://forum.openwrt.org/viewtopic.php?pid=120035#p120035 -
in the linked tarball see: DG834GBv4_V5.01.01_src/bcmdrivers/broadcom/char/adsl/bcm96348/softdsl/SoftDsl.h
-
>> It looks like Graham got the Codes from the source code for Broadcom's DSL driver
That would be interesting info to dump on the main site or wiki sometime as I have on occasion wondered what they mean, thanks for the code source asbo.
Im sure Ive seen higher numbers than 17 though, let me try do some digging when I get a min.
-
Just gone through a quick search (http://www.google.co.uk/search?q=showtime+drop+reason&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a#q=site:forum.kitz.co.uk+showtime+drop+reason&hl=en&client=firefox-a&rls=org.mozilla:en-US:official&prmd=imvns&ei=0ov6T4zkLtP78QOI-JmaBw&start=30&sa=N&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=1deb3a27a4d9b1ab&biw=1499&bih=777) on the forums..
The one code that crops up quite a lot is 8000 or 8800 for the Netgears DG834Gv4 (broadcom). Ive also seen a 20 but unsure of the router model.
It would be good to put something like this up though, because it is a question I see asked from time to time (http://forum.kitz.co.uk/index.php?topic=4374.0)
-
Looking at my D-Link DSL-2740B, I see this in the stats:
Showtime Drop Reason: 8000
Last Retrain Reason: 8000
That drop and retrain corresponded with an incoming phone call.
-
I have only ever seen 0 & 2 for Retrain Raesons on FTTC/VDSL2 connections using a Huawei HG612 modem.
However, I have seen 0, 1 & 8000 on ADSL connections, still using the Huawei HG612 but in ADSL mode.
b*cat may be able to expand on ADSL Retrain Reasons using that modem/router as it is he that is currently using the HG612 on his ADSL2 connection.
-
b*cat may be able to expand on ADSL Retrain Reasons using that modem/router as it is he that is currently using the HG612 on his ADSL2 connection.
I have seen an 8000 and (I think) a 2000 but I shall have to check to see if I have details of the causes of those Retrain Reasons.
For the record, I am not the only person using a Huawei HG612 for a ADSLx service -- we must not forget the person who made their usage possible by "unlocking" the firmware, Asbokid. :clap2:
-
Oh God. Don't rely on me ???
A recursive grep of the (full) source code tree for the DG834, another Broadcom 63xx-based router, uncovered no obvious references to Retrain Reason 8000.
Hmm..
Perhaps "8000" isn't defined explicitly in the source. Elsewhere in other code, Broadcom uses offsets or bitwise shifts to define constants. e.g. retrainCode could be stored as (1<<15) or as (0x7000 + 0x1000), or maybe the retrain reason code 8000 is not hexadecimal, but base10 like the reason codes up to 17. etc.. It does seem a strange number, not in keeping with other reason codes. Perhaps it's more of a flag (bit 15 set).
The search continues :)
cheers, a
-
I had this error in the Log of the HG612 just the one.
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
-
I had this error in the Log of the HG612 just the one.
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
That usually immediately follows a reboot, so it isn't really an error.
If you did indeed set the date/time for the inbuilt log, then a reboot resets it to 2000-1-1, whereas an on the fly resync doesn't:-
2000-1-1 0:0:21 Notice 104500 DSL activate succeed
2000-1-1 0:0:17 Debug 104500 LAN1 up
2000-1-1 0:0:15 Debug 104500 LAN2 up
2000-1-1 0:0:14 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2012-6-2 19:22:54 Warning 104001 System reboot
2012-6-14 3:22:46 Notice 104500 DSL activate succeed
2012-6-14 3:22:30 Notice 104500 DSL deactivate
-
Thanks BE1 all quite here with my logs Sync going up and SNR DS & US have flatline'd at 6DB long my it continue ;D
-
Thanks BE1 all quite here with my logs Sync going up and SNR DS & US have flatline'd at 6DB long my it continue ;D
So are you now in sync at higher than 30Mb?
Just for curiosity, does your SNR graph change much between morning & night time?
-
Not at 30Mbps yet but looking at Sync something it changing
-
I had this error in the Log of the HG612 just the one.
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
b*cat goes into pedantic mode and says that there is no error noted on the line you have quoted, only a Warning. :P
-
It does seem a strange number, not in keeping with other reason codes. Perhaps it's more of a flag (bit 15 set).
That is what I am considering . . . :-\
However I am now in a position to correct my earlier statement. The only Retrain Reason codes I currently have on record are 0, 1 and 8000.
[b*cat@Duo2 HG612]$ grep -iR reason * | sort | uniq
ADSL1/data-20120630.txt:Retrain Reason: 1
ADSL1/data-20120705.txt:Retrain Reason: 0
ADSL2+/data-20120703.txt:Retrain Reason: 8000
ADSL2+/data-20120704.txt:Retrain Reason: 8000
ADSL2/data-20120709.txt:Retrain Reason: 8000
[b*cat@Duo2 HG612]$
-
Latest update on the Retain Reason codes observed --
[b*cat@Duo2 tmp]$ grep -iR reason modem* | awk -F: '{ print $2":", $3 }' | sort | uniq
Retrain Reason: 0
Retrain Reason: 1
Retrain Reason: 2
Retrain Reason: 8000
[b*cat@Duo2 tmp]$
-
Oh God. Don't rely on me ???
A recursive grep of the (full) source code tree for the DG834, another Broadcom 63xx-based router, uncovered no obvious references to Retrain Reason 8000.
Hmm..
Perhaps "8000" isn't defined explicitly in the source. Elsewhere in other code, Broadcom uses offsets or bitwise shifts to define constants. e.g. retrainCode could be stored as (1<<15) or as (0x7000 + 0x1000), or maybe the retrain reason code 8000 is not hexadecimal, but base10 like the reason codes up to 17. etc.. It does seem a strange number, not in keeping with other reason codes. Perhaps it's more of a flag (bit 15 set).
The search continues :)
cheers, a
Kindly pointed to this debate by B*K, as I too am very interested in it. Although open to correction, it seems to me that all the retrain codes quoted are clearly (combinations of) powers of 2. Therefore IMHO it seems a reasonable presumption that they are indeed flags, and that (perhaps) it is possible for more than one flag to be set, thereby explaining reason 8800. :-\
Using that hypothesis, I now need to go and look at the list and see what I think that interpretation is trying to tell me.
-
If Asbo's 'flag hypothesis' holds,
then 0=LOS
1=RDI ? (ATM VP/VC)
2=Negative margin (presumably srnM)
2000=Dsl Start Physical Layer Cmd
8000=G992 failure
8800=G992 failure, Tone ordering exception
Does any of this make any sense? :-\
-
For those, like me, who didn't know what RDI was ???
How the ATM Interface Handles RDI Cells [1]
RDI cells received from the remote endpoint of the VP/VC indicate an interruption in the cell transfer capability of the VP/VC. For example, the remote endpoint of a VC receives an F5 AIS cell, enters the AIS state, and transmits F5 RDI cells for the duration of the AIS condition. On receipt of a configurable number of F4 or F5 RDI cells, the ATM interface declares an RDI state but does not generate OAM fault management cells in response to the condition. The ATM interface leaves the RDI condition when no RDI cells have been received for a configurable time period.
The OAM VC status field of show atm vc atm shows whether the circuit is in RDI state.
[1] http://www.juniper.net/techpubs/en_US/junose10.0/information-products/topic-collections/swconfig-link/how-the-atm-interface-handles-rdi-cells.html (http://www.juniper.net/techpubs/en_US/junose10.0/information-products/topic-collections/swconfig-link/how-the-atm-interface-handles-rdi-cells.html)
[2] http://www.juniper.net/techpubs/software/erx/junose93/swconfig-link/operations-administration-and-management-of-atm-interfaces.html (http://www.juniper.net/techpubs/software/erx/junose93/swconfig-link/operations-administration-and-management-of-atm-interfaces.html)
-
or Tone Ordering ???
Tone ordering [1]
A DMT time-domain signal has a high peak-to-average ratio (its amplitude distribution is almost Gaussian), and large values may be clipped by the D/A-converter. The error signal caused by clipping can be considered as an additive negative impulse for the time sample that was clipped. The clipping error power is almost equally distributed across all tones in the symbol in which clipping occurs. Clipping is therefore most likely to cause errors on those tones that have been assigned the largest number of bits (and therefore have the densest constellation). These occasional errors can be reliably corrected by the FEC coding if the tones with the largest number of bits have been assigned to the interleave buffer.
The number of bits and the relative gains to be used for every tone are calculated in the ATU-R receiver, and send back to the ATU-C. The pairs of numbers are typically stored, in ascending order of frequency or tone number , in a bit and gain table.
The ``tone-ordered'' encoding assigns the first bytes (8 bits) from the symbol buffer to the tones with the smallest number of bits assigned to them, and the remaining bytes (8 bits) to the remaining tones.
[1] http://www.cs.tut.fi/tlt/stuff/adsl/node13.html (http://www.cs.tut.fi/tlt/stuff/adsl/node13.html)
-
With Lan cable from HH3 going to HG612 (port 2) I have noticed the HH3 will not go into low power mode until I remove Lan cable from port 2 !
-
If Asbo's 'flag hypothesis' holds,
then 0=LOS
1=RDI ? (ATM VP/VC)
2=Negative margin (presumably srnM)
2000=Dsl Start Physical Layer Cmd
8000=G992 failure
8800=G992 failure, Tone ordering exception
Does any of this make any sense? :-\
Interesting find, ColinS! The definitive answer must be somewhere in that 9MB of C source code for the Broadcom drivers!
cheers, a
-
With Lan cable from HH3 going to HG612 (port 2) I have noticed the HH3 will not go into low power mode until I remove Lan cable from port 2 !
:hmm: Hmm . . . An interesting observation. Perhaps the router, the BT HH3, "sees" the HG612 as an active device and thus will not transition into low power mode.
For datum point completeness, are you referring to a HH3.0A or a HH3.0B?
-
I have the HH3.0A Buakkucat only noticed it last week, with all computers and port 2 unpluged the HH3 will go into power save until I plug it back into port 2, Yeah the HH3 see's the Hg612 as a device !
-
Since doing HG612 Graph stats a month or two I did notice alot of HD disc thrashing every 1 minute ,and as the log is getting larger the accessing became worse.
My solution was to uninstall NSI2012 then reinstall the Stats program and install NIS2012 this has solved it, its still logging but its silent ;D