Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: NewtronStar on November 12, 2013, 10:11:07 PM
-
Hi we all know the SNRM drops during the evening and attainable sync rate seems to follow.
Just would like to get and idea on how much it swings from 11am and 6pm don't need any graphs just your DS & US SNRM dB at the times in my post.
thanks
-
Today
a.m d/s 3.4 u/s 10.8
p.m d/s 5.8 u/s 9.5
8th
a.m d/s 3.3 u/s 10.1
p.m d/s 2.7 u/s 10.1
but remember that margins change all the time.
-
11:00
Down Up
SNR (dB): 5.8 6.0
18:00
Down Up
SNR (dB): 4.9 6.0
22:00
Down Up
SNR (dB): 5.5 6.0
I know you said no graphs, but I just wanted to show you the 24/7 DS fluctuations I now see since I started using Wolfy's new GUI firmware.
So, the 18:00 results could have been when it had fluctuated downward.
EDIT:
Having just checked modem_stats.log, it can indeed be seen that DS SNRM was lower at 18:00:-
12/11/2013 17:57 20514 4940 5.6 6.0
12/11/2013 17:58 20514 4940 5.5 6.0
12/11/2013 17:59 20514 4940 4.9 5.9
12/11/2013 18:00 20514 4940 4.9 5.9
12/11/2013 18:01 20514 4940 5.8 6.0
12/11/2013 18:02 20514 4940 5.5 6.0
-
11am
down up
SNR (db) 6.2 5.8
6PM 4.8 5.9
-
See below:
-
Today
a.m d/s 3.4 u/s 10.8
p.m d/s 5.8 u/s 9.5
8th
a.m d/s 3.3 u/s 10.1
p.m d/s 2.7 u/s 10.1
but remember that margins change all the time.
ok thats not what i expected the SNRM should go down during the evenings ???
-
EDIT:
Having just checked modem_stats.log, it can indeed be seen that DS SNRM was lower at 18:00:-
12/11/2013 17:57 20514 4940 5.6 6.0
12/11/2013 17:58 20514 4940 5.5 6.0
12/11/2013 17:59 20514 4940 4.9 5.9
12/11/2013 18:00 20514 4940 4.9 5.9
12/11/2013 18:01 20514 4940 5.8 6.0
12/11/2013 18:02 20514 4940 5.5 6.0
;D thought so, just trying to get some sort of consensus of how low it go's especially at this time of year with only 8 hours of sunlight, because it does look more like atmospheric/Ionospheric is causing more interference on BroadBand CP cables than in the Summer time.
-
I see a consistent 2 dB swing in the DS SNRM (hours of daylight v hours of darkness) throughout the entire year.
Following the Eagle's lead, I attach two graphs from 2012. The first, from August 2012, shows the typical 2 dB swing of the DS SNRM over a 24 hour period. The second, from December 2012, shows how that the US SNRM was really hit by somebody's flashing lights! >:(
-
I see a consistent 2 dB swing in the DS SNRM (hours of daylight v hours of darkness) throughout the entire year.
Following the Eagle's lead, I attach two graphs from 2012. The first, from August 2012, shows the typical 2 dB swing of the DS SNRM over a 24 hour period. The second, from December 2012, shows how that the US SNRM was really hit by somebody's flashing lights! >:(
right so your DS and US snrm drop is consistant all year round except for December with XMAS tree lights the US SNRM hates christmas :ouch: thats good info.
-
Here is a 24 hour graph, from last June, showing the typical variation in SNRM that is observed on my circuit.
-
Here is a 24 hour graph, from last June, showing the typical variation in SNRM that is observed on my circuit.
Cheers for the graph ;D its seems like the DS SNRM has a gradual rise as the sun rise's early in the morning and sets later (mid summer) again a gradual decrease after 8pm.
And I don't know whats up with your US SNRM its very messy way to many random drops in 24 hours.
-
Mines normally pretty boring.. continual flatline 24/7, very occasional 0.5 dB blip on the graph.
What have have seen is a very slow decline in my SNRm. So slow you wouldnt really notice it on a day to day basis. When I first got fttc it was at about 18dB, a new pair took it to about 14dB. It now sits at 8.3dB. The largest down jump was after a forced resync this morning and I lost 3dB immediately, yet there was no reason to show for this :(
-
Mines normally pretty boring.. continual flatline 24/7, very occasional 0.5 dB blip on the graph.
What have have seen is a very slow decline in my SNRm. So slow you wouldnt really notice it on a day to day basis. When I first got fttc it was at about 18dB, a new pair took it to about 14dB. It now sits at 8.3dB. The largest down jump was after a forced resync this morning and I lost 3dB immediately, yet there was no reason to show for this :(
its an odd issue this SNRM drop during evenings, I have read your low SNR problems -> http://www.kitz.co.uk/adsl/lowSNR.htm many times.
but something does not seem to add up, yes street lights and heating pump and so on but still there is something missing in the overall SNRM drops equation,.
how could more users online at the same exchange effect your SNRM ?
it's as you say difficult to say what is the cause but a shorter copper wire with grounded coaxial sheilding to CP premises will help reduce these effects.
-
. . . a shorter copper wire with grounded coaxial sheilding to CP premises will help reduce these effects.
Please remember that the xDSL circuit is (as close as possible to being) a balanced pair, operating in differential mode. So if you are proposing screening, you will need to use STP (screened twisted pair) cable. Why is differential mode used? Because any spurious, alien, signal induced is very likely to be induced onto both wires of the pair. Common mode rejection of the alien signal occurs whilst the required signal still "gets through".
-
signal induced is very likely to be induced onto both wires of the pair. Common mode rejection of the alien signal occurs whilst the required signal still "gets through".
I love the way you word it :lol: I know it's a bad word on the forums so i'll type it very small
"crosstalk :no:
-
. . . a shorter copper wire with grounded coaxial sheilding to CP premises will help reduce these effects.
Please remember that the xDSL circuit is (as close as possible to being) a balanced pair, operating in differential mode. So if you are proposing screening, you will need to use STP (screened twisted pair) cable. Why is differential mode used? Because any spurious, alien, signal induced is very likely to be induced onto both wires of the pair. Common mode rejection of the alien signal occurs whilst the required signal still "gets through".
The cable which runs from my original master socket location (now just a blanking plate with jelly crimps) to it's new location a few meters away is STP, I've often wondered whether the shielding drain wire should be connected to something? What's your thoughts? I may have already asked this, I've a nagging felling I have......
-
Hmm . . . I will say that it should definitely be connected to a "good" earth (and not via the nearest convenient mains socket earth terminal). I am undecided as to whether both ends should be connected to earth. I'm sure there have been discussions on this topic in the past and, I think, Rizla had some convincing arguments -- one way or the other. ::)
-
Hi we all know the SNRM drops during the evening and attainable sync rate seems to follow.
Just would like to get and idea on how much it swings from 11am and 6pm don't need any graphs just your DS & US SNRM dB at the times in my post.
thanks
snrm doesnt always drop in evenings, seems more common when loop loss is higher and on overhead lines.
On adsl I had noticeble drops of snrm at night but on my vdsl it barely budges and even sometimes goes up due to outside interference been reduced.
-
Hi we all know the SNRM drops during the evening and attainable sync rate seems to follow.
Just would like to get and idea on how much it swings from 11am and 6pm don't need any graphs just your DS & US SNRM dB at the times in my post.
thanks
snrm doesnt always drop in evenings, seems more common when loop loss is higher and on overhead lines.
On adsl I had noticeble drops of snrm at night but on my vdsl it barely budges and even sometimes goes up due to outside interference been reduced.
I have the same, some nights can drop by 3/4DB (DS & US), some nights it won't move at all sometimes it rises to 7/8DB from 6.
-
Hmm . . . I will say that it should definitely be connected to a "good" earth (and not via the nearest convenient mains socket earth terminal). I am undecided as to whether both ends should be connected to earth. I'm sure there have been discussions on this topic in the past and, I think, Rizla had some convincing arguments -- one way or the other. ::)
I could run an earth from one end into the main earth bar in the CU, would that be acceptable? I have some 4mm earth cable in the garage, but that may be a bit ott.
-
I have my doubts that earthing the screen will make any difference, because even when it's not earthed it still constitutes a Faraday cage. If you do want to earth it, then I'm fairly certain that one end only is the right way to do it, and the important factor is that the earth connection should have low reactance at DSL frequencies (reactance is frequency-dependent resistance). The gauge of the wire is fairly unimportant, but a run without lots of twists and bends would be best.
-
Hmm . . . I will say that it should definitely be connected to a "good" earth
With apologies to Eric, I agree with above.
It's a long time since I studied such things, but I kind of thought a Faraday Cage was only effective if it encapsulated the entire system. In the case of DSL, it would need to encapsulate not just the modem cable, but also the router, all of the BT wiring to the exchange, and the DSLAM. That would be a very large cage.
I also recall reading arguments that an ungrounded screen could actually make matters worse as it presents a larger surface area to pick up interference, which could then be induced into the conductors within (made possible because the equipment they connect are not entirely within the cage).
As to whether there is any benefit at all from screened cabels to DSL, grounded or not, I would be highly sceptical.
But I do confess it's a long time since anybody expected me to be a reliable source on things, I may be mistaken. Talking 'Twaddle', in other words :)
-
its seems very hard to judge the SNRM's swings and sways as it looks like every line has it's own unique pattern going on, but kind of getting this is more down to weather conditions and common local interference and the Ionosphere only plays a small part, so that's three random number generators that effects your SNRM day in & day out.
anyway on a lighter note i had my first SES error, may have had loads before but Ronskies GUI now is able to display them ;)
-
I wasn't intending to post but your comment about SES struck a chord.
Attached are recent 24 hour graphs for the US/DS SNRM of my connection. This is a typical set of graphs ever since OR fixed a lot of cable problems that previously existed between the FTTC cabinet and the home. As you can see the SNRM hardly seems to vary, but I do have concerns over my ES and SES counts.
Over the past 19 days I have had 3240/1592 down/up ES, but more wrorringly 127/1 down/up SES. Yet the connection never seems to be significantly affected (touch wood).
-
I wasn't intending to post but your comment about SES struck a chord.
Attached are recent 24 hour graphs for the US/DS SNRM of my connection. This is a typical set of graphs ever since OR fixed a lot of cable problems that previously existed between the FTTC cabinet and the home. As you can see the SNRM hardly seems to vary, but I do have concerns over my ES and SES counts.
Over the past 19 days I have had 3240/1592 down/up ES, but more wrorringly 127/1 down/up SES. Yet the connection never seems to be significantly affected (touch wood).
Thats a nice SNRM graph straight lines are good and if connection is good no need to worry untill the next modem resyncs to see if any settings have been forced upon your line.
-
I could run an earth from one end into the main earth bar in the CU, would that be acceptable? I have some 4mm earth cable in the garage, but that may be a bit ott.
Having "slept on it" I'll now say "why bother?", as 7LM has nicely summarised the situation --
It's a long time since I studied such things, but I kind of thought a Faraday Cage was only effective if it encapsulated the entire system. In the case of DSL, it would need to encapsulate not just the modem cable, but also the router, all of the BT wiring to the exchange, and the DSLAM. That would be a very large cage.
In other words, will you see any benefit from (correctly) screening just a few yards (or metres, if you wish) of your circuit? :-\ I think not. :no:
That is, of course, discounting any placebo effect. ;)
-
Thanks for the replies about the screening, I won't worry about it, One less job to do.
I'll post a screenshot tomorrow of our ses errors at work, well over 100.
-
Over the past 19 days I have had 3240/1592 down/up ES, but more wrorringly 127/1 down/up SES.
How about putting that into some form of perspective?
Nineteen days is (19 * 24 * 60 * 60) seconds. So, 127 seconds of that total is a whopping (127 * 100) / (19 * 24 * 60 * 60)%. I.e. 0.0077%
I wonder if the "excessive, obsessive Eagle effect" has mutated into something extremely contagious? :P
b*cat goes and hides from the attentions of that beak! :paperbag:
-
its seems very hard to judge the SNRM's swings and sways as it looks like every line has it's own unique pattern going on, but kind of getting this is more down to weather conditions and common local interference and the Ionosphere only plays a small part, so that's three random number generators that effects your SNRM day in & day out.
anyway on a lighter note i had my first SES error, may have had loads before but Ronskies GUI now is able to display them ;)
ronski need to make new version with wider column to support your FEC soon ;)
-
Here's mine from our works line. This was on fast path until the firmware update, then a day or two later it all went a bit pear shaped!
PS. I'll tweak the column width a bit :)
Edit: Actually whilst posting that my FEC's went up to 1002598178, and I think there is still room to spare, as you can see I get around half million FEC errors per minute.
Seems NewtronStar connection has been up 6 days, but he has four times as many FEC errors than me, but his delta figure is only 171,000 odd where is mine is regularly half a million, he must have a lot of errors sometimes to get that high that quickly. Or did his total not reset at the last resync, I know BE1 said some do and some don't.
-
Or did his total not reset at the last resync, I know BE1 said some do and some don't.
thats was something i was going to ask yourself or BE1 last week, as I can't remember if they did reset or not, when we had the Orginal Modems GUI and rebooted the hg612 from inside the GUI the totals did reset.
I guess I'll not know until next time when powering off the modem or "power cut >:(", but thats not going to be untill my 14 day wait is over.
as for the columns you could make Field 25 US_RScorr smaller and make Field 24 DS_RSCorr bigger without havingto make the GUI window larger as the US gets less errors most of the time.
-
From memory, the HG612 can handle error counts up to a value of 2,147,483,648 before being reset to zero (2 ^ 31).
(It might even be 4,294,967,296, i.e. 2 ^ 32) ???
FEC/RSCorr are one & the same thing, but one of them is reset to zero following a Retrain Reason 2 resync (I can't recall which one) & they are both reset to zero following a Retrain Reason 0 resync.
I have no idea waht happens for other Retrain reasons as I only ever see reasons 0 & 2 on my own connection.
the delta value (change each minute) should still be the same for both though.
-
sorry BE1 i edited last post after you posted so i removed it .
I have a constant DS FEC 1200 errors per min * 60 = 72000 in 1 hour * 24hr (day) 1,728,000
* 6 days = 10,368,000 so it looks like the totals were not reset.
I have not had a retrain 0 since the 8th of november 6/7 days ago why it's showing 532,954,772 when it should 10 million for 6/7 days :-\
-
I'm not 100% sure, but I think DSLStats averages some data, such as FEC errors.
HG612 Modem Stats reports the differences minute by minute.
It is quite possible that FEC/RSCorr actaually peak here & there.
I have attached my recent DS FEC/RSCorr graphs to demonstrate what actually happens on my connection.
Unfortunately, I don't have any DSLStats graphs from the same period for comparison.
-
I think this may shock you when you look at my graphs
-
CRC looks O.K.(ish) but FEC is working hard.
Is it only like that in the evenings or is it constant?
The value per minute is massively different to that shown by DSLStats.
Do you actually see that huge amount when looking at FEC (total) in Ronski's GUI? (& minute-by-minute in xlogfile.txt)?
-
I'm not 100% sure, but I think DSLStats averages some data, such as FEC errors.
No, the FEC and CRC per minute graphs are calculated and plotted on a sample-by-sample basis. But the snapshot posted by NewtronStar is very strange - I've never seen a straight line like that, which makes me suspect that it's an error.
-
Our SNRM drops by about 4-5dB, but we have a REIN fault on the line currently, so that's probably the cause.
-
CRC looks O.K.(ish) but FEC is working hard.
Is it only like that in the evenings or is it constant?
The value per minute is massively different to that shown by DSLStats.
Do you actually see that huge amount when looking at FEC (total) in Ronski's GUI? (& minute-by-minute in xlogfile.txt)?
it's why i made this thread in the first place BE1 when DS SNRM drops the attainable sync drops in the evenings and FEC errors rank up like theres no tomorrow.
Yes I can see it also in Ronski's GUI it 's been like this since those firmware updates sure you know me I only complain when it's serious, and have a graph of FEC errors from July and it's like chalk and Cheese unless i am missing something.
-
I'm not 100% sure, but I think DSLStats averages some data, such as FEC errors.
No, the FEC and CRC per minute graphs are calculated and plotted on a sample-by-sample basis. But the snapshot posted by NewtronStar is very strange - I've never seen a straight line like that, which makes me suspect that it's an error.
Don't tell me the error is on my line :(
-
If it's any consolation we're getting half a million FECs per minute at work, also only been like it since the firmware update, but I think we may be suffering from crosstalk, or a fault. Was on fastpath prior to the update.
-
If it's any consolation we're getting half a million FECs per minute at work, also only been like it since the firmware update, but I think we may be suffering from crosstalk, or a fault. Was on fastpath prior to the update.
Yes it does help Ronski ;) I just don't know what to do here, but going to keep the modem on and see what happens be it more Interleaving or less Attainable speed, kind of thinking I should report a fault on my Broadband and get it over and done with.
-
I did report a fault, but because it recovered I got nowhere. When it first happened the connection was almost unusable, then interleaving kicked in and it all started to work, albeit at a slower speed.
-
Don't tell me the error is on my line :(
:)
I was actually wondering if you'd found a bug in DSLstats.
-
I did report a fault, but because it recovered I got nowhere. When it first happened the connection was almost unusable, then interleaving kicked in and it all started to work, albeit at a slower speed.
What I have noticed since this update is the DLM is inducing higher interleaving on marginal lines, I could be wrong but that should reduce the FEC errors but another thing that appears on my line is the attainable is able to go much higher than the line can cope with so it's conflicting with the DLM's attributes and in basic terms it's made a mess of my line.
-
Don't tell me the error is on my line :(
:)
I was actually wondering if you'd found a bug in DSLstats.
I can't find any, I use both DSLstats and HG612_stats and Ronski's GUI day in and day out all programs work well, yours has a nice realtime update graph which helps when flicking on and off applainces which dectected and show'd a big error when the PIR light comes on & Ronski's GUI is what you look at after booting up the PC to see a quick whats up, and BE1 HG612_stats is for a closer look over time.
-
I seemed to have reached 1 Billion FEC errors in 8 days
125,000,000 per 24 hours
5,208,333 per hour
86,805 per minute
is this a record breaker has anyone the telephone number for Guinness World records
-
I remembe rmy adsl line used to have those kind of FEC (when interleaved) but I dont think it ever hit 1 billion (although it had trouble staying up 8 days), so maybe it is a record :D
-
I remembe rmy adsl line used to have those kind of FEC (when interleaved) but I dont think it ever hit 1 billion (although it had trouble staying up 8 days), so maybe it is a record :D
I am not to worried by the DS FEC count, I was just looking back at my stats history it seems the more interleaving you have the more FEC errors you get and once the 14 days are over the Interleaving should go down by half and DS FEC errors should also follow by the same amount :fingers:
edit: coming up to the 2 Billion Mark :-\
-
I've got over 3.25 billion in 16 days, but the maths doesn't quite work out, unless of course the counters reset but I haven't noticed it do that.
3256062877 / 16 days = 203503929.8125 / 24 hours = 8479330.40885417 / 60 minutes = 141322.173480903 per minute.
But I always get around 500,000 as the delta.
-
But I always get around 500,000 as the delta.
Good or not so good to see your also in the same boat, I take it the FEC delta is how many FEC's you get per sample (1 Minute), when I look back when my Interleaving was at 450 the delta would be from 50,000 to 80,000 FEC errors per min at the moment it's at 285,000
-
Yes the delta is the amount in the last minute, it's my works connection which is in the same boat, my home connection is currently on fast path.
-
it's my works connection which is in the same boat,
I know it's your work connection, have seen your home connection stats which one would be envious of but thats the way FTTC works the closer to the cab the better ::)
-
There's not much in it distance wise, 50 meters, but the telephone lines are notoriously bad and I should think electrical interference is also a lot higher. It was also on fast path until a few weeks back though.
-
There's not much in it distance wise, 50 meters, but the telephone lines are notoriously bad and I should think electrical interference is also a lot higher. It was also on fast path until a few weeks back though.
50 meters from Cab to Work :o then you have a problem which you kind of know :P
look RS I am 725-800 meters from cab so that tells you a story (your work line needs a good Investigation" :ouch: or are you to close to the exchange ?
-
No no, no. There is 50 meters difference (which I see I left out). My home connection is 450 meters, and work is 500 meters.
-
No no, no. There is 50 meters difference (which I see I left out). My home connection is 450 meters, and work is 500 meters.
I get you now ;D I can only say that the Work line must have had alot more noise on the line two weeks ago but your QLN graph should show this to be the case or maybe it was just a coincidence the bandplans were changed at the same time your fastpath was turned off, though I am not a great believer of coincidence scenarios it's either one or the other which caused this
-
If only I knew what causes that sudden jump up and down during the day. :(
-
Those drops are probably crosstalk as other lines are activated. I get a much bigger amount of about 3db in total of such daytime drops, two individual properties known to me cause just over 1db each (I can tell when they go on holiday!) and the remaining 0.8 db are the total of all the other properties that don't leave modems on 24/7. My night time snrm is always about 3 db bigger than in the day. If I sync at 6am at 6db I drop to 3db by 10.00am and start to recover back to 6db at about 10pm! I wonder over a length of split pair along the way between me and the CAB!
An example below ( 3db sync) with one of of the two "offending" properties owners on holiday ( I guess I may be "offending" them as well) , i.e. main impact one known neighbor.
-
There is a noise issue on the downstairs line intermittently causing very erratic SNRM fluctuations but generally the SNRM drops less than 0.3 dB throughout the day.
I was tested earlier and I disconnected the upstairs line resulting in the downstairs line's downstream SNRM increasing to 7.6 (from 6.4) and the upstream SNRM increased to 10 (from 9.4).
My telephone lines are separate drop wires.
-
Our REIN fault is resolved according to Plusnet and the SNRM certainly does seem to be dropping less at night. It drops maybe 2dB at the most now, which is the least it has ever dropped and it's winter too!
-
With regard to total FEC errors the counter resets around 4294656929, as the next total in my log is 196094, that explains why the maths didn't work out before. With the total showing 196094, my FEC delta is 506461, so 506461 - 196094 = 310367. So 4294656929 + 310367 = 4294967296 as the maximum possible amount before resetting to zero. Which is 100000000000000000000000000000000 in binary, so actually it should be 4294967295, which is 11111111111111111111111111111111 is binary, so total FEC is stored as a 32 bit value.
Regarding SNRM ours was 9db for a long time, until the new firmware appeared.
-
With regard to total FEC errors the counter resets around 4294656929, as the next total in my log is 196094, that explains why the maths didn't work out before. With the total showing 196094,
yes my fec totals seem to have been reset, but the uptime is still going on, so it not a great way to compare your total vs modem uptime :o
-
Unfortunately it does make it difficult to know the total, but do you really need to?
BE1 could alter his software to take it into account, BUT if the software wasn't on continuously then it could lose track for various reasons. Shame they don't use a 64 bit number, that would go up to 9223372036854775807 :o
-
Several of the values reported by the router are stored as 32-bit integers, and they all wrap round when they hit the limit of just over 4 billion. As Ronski says, you have to monitor continuously if you want to maintain an accurate count of the totals. In truth, these aren't very useful figures (apart from their curiosity value) - what's far more interesting is the per-minute rate and how it varies over time.
-
Unfortunately it does make it difficult to know the total, but do you really need to?
Yes I really need total error counters to be accurate with the Modem uptime to see how my line compares from previous to current that is the fundamental of what stats meens and yes I know that my FEC errors are very large but if am having it others must also be seeing it to.
-
As Ronski says, you have to monitor continuously if you want to maintain an accurate count of the totals. In truth, these aren't very useful figures (apart from their curiosity value) - what's far more interesting is the per-minute rate and how it varies over time.
I have just posted more or less the same message here:-
http://forum.kitz.co.uk/index.php?topic=13078.msg250178#msg250178
I can see how my connection changes over very long periods of time, but it is being monitored 24/7 (see the attached 320 days of ongoing stats to see how it has deteriorated over time).
-
BE1 could alter his software to take it into account, BUT if the software wasn't on continuously then it could lose track for various reasons. Shame they don't use a 64 bit number, that would go up to 9223372036854775807 :o
Just to confirm, BE1 isn't about to alter his software as it does appear to provide a reasonable 'picture' of a connection's performance over time as it is :)
-
I see what your saying about the Stats software running continuously (PC on 24/7) but when the HG612 had it own GUI those error counts were held inside the Modem so you never had to leave BE1 stats program on 24/7 to show the errors accumulating
-
I see what your saying about the Stats software running continuously (PC on 24/7) but when the HG612 had it own GUI those error counts were held inside the Modem
Yes, but the ones it displayed were WRONG (FEC/CRC).
You can get the GUI back if you choose to use Wolfy's firmware (basically using BT's recent updates, but adding the GUI back in).
-
I see what your saying about the Stats software running continuously (PC on 24/7) but when the HG612 had it own GUI those error counts were held inside the Modem
Yes, but the ones it displayed were WRONG (FEC/CRC).
You can get the GUI back if you choose to use Wolfy's firmware (basically using BT's recent updates, but adding the GUI back in).
Cheers BE1
I am not ready for Wolfys firmware as yet, what I am trying to understand here is your total error counts don't come from the Modem itself only from your software is that right.
-
All the data comes from the modem.
My software then calculates the differences each minute.
e.g:-
sample 1 - RSCorr = 100
sample 2 - RSCorr = 150
Difference = 50
The graph reports 50 for that minute.
sample 3 - RSCorr = 175
Difference = (175 - 150) = 25
The graph reports 25 for that minute.
The connection then resyncs, so RSCorr = 0
sample 4 - RSCorr = 40
Difference = (40 - 0) = 40
The graph reports 40 for that minute.
& so on & so on.............................
Even if the modem's data isn't reset at a resync, the difference between the samples is calculated & reported in the graphs.
So, let's say RSCorr wasn't reset to zero, sample 4 would have been 215.
Difference = (215 - 175) = 40
The graph would still report 40 for that minute.
A special case is when the maximum value the modem can store is reached.
The value is then reset to zero.
Whatever data is stored by the next minute's sample is recorded & if there is only 1 minute difference between samples, whatever is recorded is reported in the graph.
However, if the data hadn't been harvested for a while, the first new sample could be a huge value & a great big spike incorrectly reported in the graph.
So, whenever there are 2 minutes or more between samples (e.g. the software/PC has been switched off), the data at the next sample is ignored to avoid the misleading spike, although the data is still recorded in modem_stats.log, ready to calculate the difference when the next minute's sample data is obtained.
So, between samples when the software isn't running, the difference could be say 100,000,000.
Reporting that as a minute by minute difference would be clearly wrong, so the very first sample after re-starting the software is ignored.
But the next sample is say 100,000,040
The one minute difference would then be only 40, which would be correct so it is reported in the graph.
The only graphs that don't work like that are DS & US OHF.
They aren't actually error counts as such, so whenever a few samples are missed, for whatever reason, the graphs intentionally report a spike, which acts as a visual 'flag' to indicate that there had been a pause or delay in sampling.
I have attached an example of the DS OHF graph from when my virus scanner slowed the PC down at 04:00 that much that a sample or two were missed or were delayed.
Thus spikes are seen
I have also attached the DS CRC graph from the same period. Spikes are not seen at 04:00.
The spikes that are shown in the DS CRC graph from earlier on are actually genuine CRC error spikes.
-
All the data comes from the modem.
My software then calculates the differences each minute.
Have been using your software for years without questioning it's results, your explanation and the workings behind your software and the modem is remarkable.
Maybe one day in the future I'll be able to leave the PC on for 51 weeks @ 24/7 it's just not viable at the moment :( so it looks like the software does not work to well for an energy saving EU like me. :D
-
Have been using your software for years without questioning it's results, your explanation and the workings behind your software and the modem is remarkable.
I concur with BE1, there really is very little point in altering the logging software, we have to work with what the modem gives us. I've been using his software for well over a year, testing things and developing the GUI, but I still don't understand what the majority of the information means :no:
Maybe one day in the future I'll be able to leave the PC on for 51 weeks @ 24/7 it's just not viable at the moment :( so it looks like the software does not work to well for an energy saving EU like me. :D
I'm also an energy saving EU, my wife and daughters will tell you how much I nag about lights and things left on. Last thing I do before bed is to make sure everything is turned off/standby - the media PCs have a habit of staying on even when they are set to go to sleep after X minutes.
My logging is done on my server which is on 24/7 for various reasons, but it only draws 40 - 50w, so probably costs around £60 a year to run. I certainly wouldn't leave my desktop system on 24/7.
-
I actually had a cool idea the other day, though I have no idea if it's possible.
Most routers are supplied with a USB (For firmware, software updates, etc?)... here comes the question.
You create a bootable of your or roseways program upon putting the USB into HomeHub it will then boot the program and gather the line stats from this location using the HH's power. It will save all files onto the USB, when you want to look at the line stats you take the USB out and plug it in your computer and bobs your uncle all your information is saved.
Though as I said I have no idea if this is possible, I'm assuming it's not.
-
It's a nice idea, but a program needs an operating system environment to run in, it can't just boot all by itself.
-
It's a nice idea, but a program needs an operating system environment to run in, it can't just boot all by itself.
I know that but my was point to use the software provided router but that means you will have to make a unique for each different router (more than likely).
Guess keeping my PC on in the mean time will suffice.
-
It's not a big job really but obviously it requires technical knowledge to accomplish.
Perhaps a client/server solution will be made when lantiq based routers are the norm for example the HH5A.
-
For those persons already fluent in Penguin, a Raspberry Pi will quite happily provide the means for 24 hour logging.
Below is an image of a R-Pi, logging the data from my Huawei HG622. ;)
-
And for people who don't wish to get involved with Linux there is always something like the Fit-PC2 (http://www.fit-pc.com/web/specifications/?PN=fit-PC2i-D1G-C1600-W), obviously a lot more expensive than a Pi and you would also need a copy of Windows to shove on it, but it is very low power.
Or there are some pretty cheap Net Tops on Ebay complete with OS which would be low power.
-
I can see now if you turn off ongoing stats in Ronski's GUI the information is halted untill you turn it back on again, I just thought Ronski's new GUI was using his own independent telnet, but it's using BE1 ongoing stats to generate thoses GUI figures.
I figured it out cheers guys silly me :blush:
-
I figured it out cheers guys silly me :blush:
:friends:
-
I just thought Ronski's new GUI was using his own independent telnet, but it's using BE1 ongoing stats to generate thoses GUI figures.
I wouldn't know where to start to even attempt gathering any stats, and there's no point reinventing the wheel, as you've now sussed out it's just a graphical user interface for BE1's excellent stats logging software.
PS. Take a look at the Help & About tab ;D
-
PS. Take a look at the Help & About tab ;D
;D Yeah rub it in, I don't know why just thought your New GUI was directly tapping into the HG612 and extracting the data the same way as we did on the HG612 via its GUI (192.168.1.1) but it's gone.
So as BE1 said above those FEC errors were displayed as incorrect on the HG612 GUI so that's why it looks like my FEC errors are a lot higher on your GUI because they are the correct ones, and when I think back I never really took much notice of BE1 DS_FEC errors in the graphs only on the HG612 GUI
eating my humble pie ;)
-
well it does look like the DS SNRM has finally gone back to the norms after the 14 day wait and power off/on the modem, SNRM rises to 6.9dB afternoon and 5.6dB evenings thats much better, and FEC errors have gone down from 200,000 per min to 33000 and to my surprise the interleaving is still at 1200, will have to wait another 2 weeks to see if that will drop to. :-\
also after turning off/on the HG612 modem Ronski's GUI stats do reset so thats good.
-
Update
Have been mucking around to find this excess of FEC errors 200.000 to 400.000 per min, this has come as a shock to me, when I unplug the two TPlink homeplugs from the mains the FEC errors drop to 861 per min and when plug them back into mains socket FEC errors go back into the 200.000.
Has anyone any ideas how this would happen ? MY PC is connected to router (HH3) via Lan cable, the homeplugs are only used for the 2nd PC at home.
-
homeplugs are known as noise sources, but people are oblivious to it and ofcom failed to act on it.
Replace them with proper ethernet, problem solved.
-
Homeplugs are evil devices. >:(
Am I surprised? No. :no:
Install an Ethernet LAN and "do it properly"! ::)
Edit: I see Chrys managed to type faster than me . . .
-
Thanks BC and Chrysalis
Wish you had told me this before ;) have been searching the net for weeks for reasons why the FEC was so high and yes people were coming up with Noise was the Fault on my line but never thought it could be internal due to HomePlugs :'(
ok i'll have to go back to wireless again on 2nd PC untill I can stuff some ethernet cable upto roof space and poke it down into other room.
Cheers
-
yeah and since openreach seem keen on trying to tell people that home wiring can cause issues for some reason they never mention homeplugs.
I wonder now if DLM will put you back on fast path.
-
yeah and since openreach seem keen on trying to tell people that home wiring can cause issues for some reason they never mention homeplugs.
I wonder now if DLM will put you back on fast path.
I should have picked this up ages ago when I noticed the MultiBand Radio Scanner was locking onto channels with interference thought it down to are Digital TV transmitter running at full power after digital switch over but also purchased the HomePlugs at the same time.
I never had seen fast path on my line ADSL to xDSL it always been interleaved.
Also during the search for High FEC I re-flashed the HG612 back to Asbo's A2pv6C030b.d22g that made no difference it was the Homeplugs, did the -kill killall stuff but would like to go back to lastest firmware, do I just wait untill it comes in or do I have to turn off/on modem ?
-
Also during the search for High FEC I re-flashed the HG612 back to Asbo's A2pv6C030b.d22g that made no difference it was the Homeplugs, did the -kill killall stuff but would like to go back to lastest firmware, do I just wait untill it comes in or do I have to turn off/on modem ?
You can: (1) re-enable Beattie's busybody ((a) from the CLI or (b) by rebooting the HG612) and wait for it to decide that your time is ripe for the firmware upgrade or (2) re-flash the HG612 with Wolfy's firmware image.
The choice is yours. ;D
-
or (2) re-flash the HG612 with Wolfy's firmware image.
The choice is yours. ;D
Thanks BC, I think i'll choose Wolfys Firmware but which one as there are three version's
1. bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_no-btagent
2. bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_original
3. bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_unlocked
I was reading the post but got confused which one has the rebuilt GUI is it number 3 ?
-
In the list that you have shown:
- Is the unlocked version of Beattie's original firmware image with her busybody (the little snitch) removed.
- Is Beattie's latest firmware image, locked up tight.
- Is Beattie's latest firmware image in an unlocked state, which will allow statistics to be harvested via the LAN2 port.
Of those three images, you don't want to install number 2. ;)
So number 1 or number 3 ? . . . You decide. ;D
Edited to add:
Here are the images that I possess --
[Duo2 Firmware]$ ls -1 bcm*
bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked
bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked_Updated_BLOB
bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_BT_Original
bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Wolfy_No_BTAgent
bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_BT_Original
bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_Wolfy_Unlocked
bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_Wolfy_Unlocked_GUI
bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_Wolfy_Unlocked_GUI_No_BTAgent
[Duo2 Firmware]$
-
FWIW, this is the one I have been using for a while without any apparent issues (with a working GUI):-
bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_unlockedgui
I downloaded it directly from the 'Experimental' area, but the site now needs a newer version of browser when I tried to have another look tonight.
-
FWIW, this is the one I have been using for a while without any apparent issues (with a working GUI):-
bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_unlockedgui
I downloaded it directly from the 'Experimental' area, but the site now needs a newer version of browser when I tried to have another look tonight.
;D yeap BE1 when using IE9 on Vista it comes up with this "your using and old browser please update and a blank page" but Chrome seems to work fine, whats that all about :-\
Thanks I'll go with that one -> HG612V100R001C01B030SP06_unlockedgui
I do appreciate all the help you guys & girls have given me here.
-
Just an update since removing the Homeplugs and also found a another source of noise/interference old Sony freeview box which I sort of knew it was causing some interference, the DLM has lowered the interleaving from 1600 to 466 and increased Sync speeds this morning after 3 days and FEC errors are still remaining low (24-500) so thats great.
I am still on Asbo's A2pv6C030b.d22g unlocked firmware and don't wanna be turning off the HG612 at this time to flash to wolfys firmware would like to give the DLM a chance to bed in.
I would like to turn on Beattie's busybody from the Telnet but I need the correct command line parameters ;)
-
I would like to turn on Beattie's busybody from the Telnet but I need the correct command line parameters ;)
Essentially you will need to:
- Establish a telnet connection to the device.
- Log in as usual. (admin/admin)
- Invoke the Busybox shell.
- Invoke the controlling shell-script (called start) as a background process.
As I do not currently have a HG612 powered-up, I can't give you the precise details. However I am sure that this has been documented in the forum -- either by Eric or Wolfy -- in the near past.
I prescribe a quick forum search! :angel:
-
I prescribe a quick forum search! :angel:
I'll do that :silly: me
-
newtron imo the new firmware is worse for error rates, I would stick with what you got now its improving nicely.
I think I will be downgrading again to asbokid firmware next week, I am now getting 3x the error rate on this new firmware.
-
newtron imo the new firmware is worse for error rates, I would stick with what you got now its improving nicely.
I think I will be downgrading again to asbokid firmware next week, I am now getting 3x the error rate on this new firmware.
Hello Chrysalis and your also a mind reader to ;D also was wondering if the New Firmware was impacting the line, 100% sure the Homeplugs was the current cause, it's hard to know if the lastest firmware made things worse and since then the Interleaving has always been high so you could be on to something.
heres the BTagent command to turn it back on http://forum.kitz.co.uk/index.php?topic=13034.30
putting it here so I don't have to do a 30 minute search again
-
you dont need btagent to upgrade the firmware by the way, I am using howlingwolf's firmware. Because of this I still have the GUI.
-
you dont need btagent to upgrade the firmware by the way, I am using howlingwolf's firmware. Because of this I still have the GUI.
I know have Wolfy's firmware saved in my Firmware folder and ready when the time is right for a flash but not yet ;)
-
In that case I suggest that you don't enable the BT Agent, then you can upgrade the firmware when you want to, not when BT want you to.
I'm afraid I don't know how to enable it, if that's what you really want to do.
-
In that case I suggest that you don't enable the BT Agent, then you can upgrade the firmware when you want to, not when BT want you to.
I'm afraid I don't know how to enable it, if that's what you really want to do.
The great thing is you can enable the BT Agent without turning off the HG612 see post #100 and you will see a link to turn it on via Telnet, as I have just had a retrain 2 at 3:59am if I turn off the modem to re-flash wolfy's firmware it more than likely I will be hit by the DLM and introduce more interleaving and slower sync, so I have to wait for a quite a few days before doing a flash, if I leave it to BTagent then it will update at the optimal moment I hope :-\
-
I have always found homeplugs work very well. They don't seem to cause any interference on our line.
Running ethernet cable would be difficult in our house!
-
I have always found homeplugs work very well. They don't seem to cause any interference on our line.
Running ethernet cable would be difficult in our house!
They seemed to work fine for 12/13 months with no impact to VDSL Modem but one of the homeplugs was giving of a hi pitched sound only noticed during the Homeplug on/off tests and I do think HP 2 was at fault but both are in the Black BIN and back to Wireless for Desktop 2, they do interfere just whish I had bought Mains conditioner strips but I would have to buy one for every Mains socket in the house that's not viable.