Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: renluop on October 05, 2013, 06:40:30 AM
-
What info about a connection can be gathered from the graphs' patterns over a few days. say? I've noticed the patterns can be very variable.
-
This explains bitswapping:-
http://www.kitz.co.uk/adsl/adsl_technology.htm#bit_swapping
What do your bitswap graphs look like?
I have attached mine over a 4 day period as an example.
There's a clear pattern at 'noisier' periods (around 8pm to midnight & this morning a little more US bitswapping than usual after 4am).
The 4th example is from another user's connection where US bitswapping (unusually) more or less swamps the DS bitswapping.
-
Just to add to my previous message, the other user (also unusually) sees a lot more US errored seconds than DS errored seconds & often sees dips in US SNRM when the phone rings.
That suggests a slight HR issue at US frequencies to me, but not sufficient to actually cause the connection to drop.
The examples are from VDSL2 connections, but the principle is the same as for ADSL connections.
-
See attachment of some taken when errors were low, and some when very much not so. Also incl is the graph of a massive upstream dip and recovery of SNRM this morning, where upstream sync also fell. Edit: Fwiw over he period of the SNR glitch DSL event log reported that no data was received
I know it all may be to do with noise, but as the substation is supposedly recently attended to, I am not so convinced.
Interleaving is up and down like a yo-yo and downstream margin target seems to be an odd ~7.5 dB.
Apart from noise, is there anything else that might be the cause of the erratics.....router (TG582N) playing up....overheating. The base feels warm having been on from late last night to now, but not uncomfortably so. i Have a TG 585 v7 I could try.
-
I'm not at all familiar with ADSL connection stats & their effects, only getting involved in detail with VDSL2 connection stats, so I don't know what would be classed as 'normal' for ADSL connections.
Hopefully, an ADSL user may be able to provide some stats/graphs for comparison purposes.
Without being able to also see 'other' error graphs etc. it's hard to say if the bitswapping is an issue or actually proof that noise fluctuations etc. are being adequately dealt with as intended.
Eric may be able to comment on the no data received message in the DSLStats log, but it does appear that various values have been plotted in the graph.
You mention that Interleaving is up & down like a yo-yo.
That suggests to me that the connection resyncs regularly via DLM intervention or that the router is turned off/on on a regular basis.
From what I can gather, DLM stores the latest 30 days worth of connection history & uses these details to determine interleaving depth etc. at the next resync.
I wonder if it would be possible to set the DSLStats window (time per page) to 24 hours rather than 2 hours & keep the connection & logging live for a while.
Doing that might just identify 'problem' times & patterns may emerge over a period of time (either time related or maybe even weather related).
It may well be worth trying an alternative router for a while, if only to eliminate the router itself as a potential cause.
-
Eric may be able to comment on the no data received message in the DSLStats log, but it does appear that various values have been plotted in the graph.
The "No data received" log entry applies only to an individual sample. It just means that for some reason the program was unable to collect that sample, possibly because the router was busy on other tasks at the time and didn't respond to the CLI command. This is a fairly common occurrence with some routers.
BE1's suggestion to set the time per page to 24 hours and leaving it running all day sounds a good one, as it may reveal patterns which aren't obvious over a shorter timescale.
-
I shall set the graphs to 24 hours. The computer is turned off usually overnight, but the router kept running 24/7.
I take the point about "no data received", but the fact that it happened when the ?substantia? dip in u/s SNRM occured dif seem it might be worthwhile mentioning.
Had a resync in the early hours. Abbrev. example of telnet on 5th and today is attached as well to illustrate how the interleave and u/s sync fluctuates.
Today's bitswap graph is entirely different ( att).
-
Re 24 hr graphs; what sample interval do you recommend? Currently it's 30 secs.
-
I suggest that you make it 60 seconds.
-
Further bitswap graph added
-
That shows the bitswaps per tone.
How does the bitswaps per minute graph look?
-
Router 582N and so bitswaps per minute option is greyed out :(
-
Ah yes, I'd forgotten that you use a Thomson router. Unfortunately it doesn't report bitswaps, so a lot of this discussion isn't relevant. The bitswaps per tone graph is one which I derive from the bitloading figures, and is really only useful as an indication of the shape of bitswapping over the tone range.
-
Duh! :D
That said, I will continue with the 24 hr graphs. Just in case it might be somehow relevant I have enquired of the power co about the work done.
BTW what Broadcom based router would you all recommend, something considered better than Tecnicolor but not in the Billion 7800 and Draytek price points?
-
That's becoming a rather difficult question to answer. In my opinion the best answer is HG622, but you probably won't be able to find one of those for sale new. There's the D-Link DSL-2740B, which isn't the latest, and it's a rather ugly beast, but it's an excellent performer and fully compatible with DSLstats. Another low cost possibility is the TP-Link TD-W8960 which I haven't tried personally but gets generally good reviews.
-
There seem to be in Kitz and elsewhere some mention of the TP-Link getting very hot. Sheddy.. was one such commenter, IIRC.
Does that still apply?
Eric, ou mention "low cost", what would lie between that and "high cost"?
Edit: I see the HG622 mentioned as VDSL, were it to be found new or used, is it also ADSL too?
-
I've no personal experience with the TP-Link, so I can't comment.
There's the Billion 7700N, which is a slightly cut-down version of the 7800N. As far as I can see, 'cut-down' merely means that it has 10/100 ethernet ports in place of the gigabit ports of the 7800N. Not something which will affect you unless you have a very busy home network.
The HG622 covers ADSL as well as VDSL2. I use one myself on an ADSL2+ connection from time to time, and there are others here who also do.
-
They're probably not worth that much now, but graphs etc for 24 hours from 15:30 yesterday are attached in a zip.
-
PN have agreed a SNR reset as connection has looked clean recently.
Thanks for all your comments.
-
Apart from noise, is there anything else that might be the cause of the erratics.....router (TG582N) playing up....overheating. The base feels warm having been on from late last night to now, but not uncomfortably so. i Have a TG 585 v7 I could try.
Not really, although it has been known in the past that some router f/wares have been less efficient with bit-swap. Why this should be I dont know as the algorithm should be similar across the board, so possibly a bug. Some routers are warmer than others not necessarily anything to do with bit-swap, although if the router is performing lots of bit swapping then the processor will be working hard and will contribute to heat.
Bit swap could be seen as a first line of defence against brief burst type noise spikes. Without bit swapping most lines would see a lot more errors and loss of syncs. The tones where the most bit swap occurs should mirror the tones where SNR is lost from. For example when I had the line fault which affected my U0 channel, then thats where all my bitswap was happening, and none in the higher frequencies. You can also use the bitloading graphs to see where noise has been problematic.. again an example would be on my line, that after a while U0 would have no bits loaded as bit-swap had shunted all the data to be distributed & transmitted over higher frequencies.
-
Thanks for that interesting info.
Last night- this morning telnet showed there had been 9 resets, and from graphs there were shown 2 resyncs which brought speed down from 7331/888 to 6727/792 kbps and some heavy fluctuations in u/stream SNR.
Me thinks it's time test socket, and a suicidal Ethernet run up to spare room.