Download speed up during 'open questions', down again when closed
Quote from: mickthefitter ..........(seeing as this realm of digital technology is not my natural habitat)..........
That would be pretty much the same as painting (cars or woodwork) would be for me
Quote:
In different places, the TG572n reports 3 time durations - time since last power on / reboot - time since last resynch (in DSL stats) - time for current PPP session (Internet connection)
Yes, I've identified those three slightly different 'time zones' now.
I'm back to recognising the SN Margin from the stats list and remembering from before, that high is bad, low is good.
(I'm scrolling up and down here, trying to translate the messages I've received and comprehend how that relates to the numbers!)
What is a 'PPP' session? Brackets 'Internet connection'? Is that every time I start up my laptop computer and get onto the internet? Regardless of the TG582n sitting there all day, powered up, plugged into the BT copper wires but having nothing to do? Or something else? I'm not clear on the 'hopping gateways' reference.
Did my disconnecting my internet connection from within the Technicolor Gateway last Sunday night, for about three minutes, start a fresh 'PPP' session? Apparently it did nothing useful to my stats or data flow. Sorry, I follow so far, then the trail gets a bit foggy in my head.
With respect to reply #41 which is this
Log in to the Modem/Router, in the Internet box, click Disconnect to drop the PPP Internet session (this is not the sync), wait about a minute and then power down the Modem/Router. After about another minute you can unplug it from the line
Make whatever changes (if any) you want, but stay offline for at least 10 minutes. When you re-connect and power up, you may need to Login to the Modem/Router and click Connect to establish a new PPP session.
Don't do this more than 5 times in an hour, then leave it for the rest of the day. This method is to help stop the Exchange DLM from thinking your sync loss was a dropped connection..
Now that, I remember it well, and will always do that now if I have to pull the plug on the TG582n. What I'm losing here, is the difference between what happens (or is meant to happen) when I do a 'graceful disconnect' and then pull the plug on the TG582n, or do a 'graceful disconnect' and then reconnect a few minutes later, because I know for a fact that at least once, and probably on two occasions, close to when I was having my original problems but I was getting sorted, so I was doing lots of regular checks (rather than just using the darn internet like an appliance - what a silly notion!)
doing a graceful disconnect while leaving the TG582n happily buzzing away with 240 volts surging through it (no, I know its knocked down to train set voltage really) did improve my upstream data flow so I assume it improved the SN up statistic.
The 'why it did it before' and 'but it didn't do it this time' (Sunday) is what I find baffling. Sorry if the explanation is already given (which it probably is) but I'm still not 'getting it'.
Well, that's me done on the 'net for tonight. Off to Gloucestershire in the morning on automotive matters, not related to work.
Cheers
In different places, the TG572n reports 3 time durations - time since last power on / reboot - time since last resynch (in DSL stats) - time for current PPP session (Internet connection)
Yes, I've identified those three slightly different 'time zones' now.
I'm back to recognising the SN Margin from the stats list and remembering from before, that high is bad, low is good.
(I'm scrolling up and down here, trying to translate the messages I've received and comprehend how that relates to the numbers!)
What is a 'PPP' session? Brackets 'Internet connection'? Is that every time I start up my laptop computer and get onto the internet? Regardless of the TG582n sitting there all day, powered up, plugged into the BT copper wires but having nothing to do? Or something else? I'm not clear on the 'hopping gateways' reference.
Did my disconnecting my internet connection from within the Technicolor Gateway last Sunday night, for about three minutes, start a fresh 'PPP' session? Apparently it did nothing useful to my stats or data flow. Sorry, I follow so far, then the trail gets a bit foggy in my head.
With respect to reply #41 which is this
Log in to the Modem/Router, in the Internet box, click Disconnect to drop the PPP Internet session (this is not the sync), wait about a minute and then power down the Modem/Router. After about another minute you can unplug it from the line
Make whatever changes (if any) you want, but stay offline for at least 10 minutes. When you re-connect and power up, you may need to Login to the Modem/Router and click Connect to establish a new PPP session.
Don't do this more than 5 times in an hour, then leave it for the rest of the day. This method is to help stop the Exchange DLM from thinking your sync loss was a dropped connection..
Now that, I remember it well, and will always do that now if I have to pull the plug on the TG582n. What I'm losing here, is the difference between what happens (or is meant to happen) when I do a 'graceful disconnect' and then pull the plug on the TG582n, or do a 'graceful disconnect' and then reconnect a few minutes later, because I know for a fact that at least once, and probably on two occasions, close to when I was having my original problems but I was getting sorted, so I was doing lots of regular checks (rather than just using the darn internet like an appliance - what a silly notion!)
doing a graceful disconnect while leaving the TG582n happily buzzing away with 240 volts surging through it (no, I know its knocked down to train set voltage really) did improve my upstream data flow so I assume it improved the SN up statistic. The 'why it did it before' and 'but it didn't do it this time' (Sunday) is what I find baffling. Sorry if the explanation is already given (which it probably is) but I'm still not 'getting it'.
Well, that's me done on the 'net for tonight. Off to Gloucestershire in the morning on automotive matters, not related to work.
Cheers
Hi Mick, hope you enjoy your trip to Gloucestershire. If it's motor related I guess it won't be the Cheltenham Real Ale festival or the 10km (Charity) Walk at the Badminton Estate Bourton-on-the-Water perhaps?
Whilst you have no doubt picked up a lot of knowledge since the start of this thread, I'll try and summarise (and explain) as simply as possible, most of the broadband basics in what is hopefully a logical order - don't be offended if some of it seems to be stating the obvious to you, it'll also be worded for anyone who maybe reading who has less knowledge..
Obviously a connection to the exchange is needed. It's the speed and stability of this connection that is usually the most significant factor in determining the quality of your broadband service. So the speed that you can connect with (called sync speed), will determine the maximum possible data speed that can be achieved. The sync speed will be determined by the length and quality of the cable pair to the exchange and any interference (noise) that it gets. There are 2 parts to the connection involved, the Downstream (DS) carrying the data to you, and the Upstream (US) for data you send. The DS is usually what most users find has the most significant effect on their connection, but a decent US is also important.
Whilst an ISP is responsible for the correct functioning of the broadband service you pay for, it does not own this infrastructure which is owned and maintained by BT OpenReach which the ISP has to rely on for any repair, maintenance or provision. Most (but not all) broadband problems are related to your connection to the exchange. Any problems with the line itself, which often manifest themselves as problems with phone calls, audible noise etc, will also affect the broadband and must be fixed first before correct broadband functioning can be fully restored.
Not at all. That is how the greater majority of broadband users will be using their connection. Most will be running with a trouble-free optimised connection. There will however be quite a few who will be blissfully unaware that theirs is (and perhaps always has been) running below par. Often a single minor fault doesn't result in a significant impact and may go unnoticed and it is only when a 2nd issue arises or the 1st gets worse, that a user realises a problem exists. With more than, and sometimes even with, one issue, it can often get quite complex to analyse.
Apart from the obvious checks to the phone service - quiet line tests etc - looking at the Full xDSL stats is probably the next most important aspect of this. The Uptime here is the most significant of the 3 times, as initially it can give an idea of connection stability as well as average error rate. When there is a loss of sync this Uptime and most of the error figures get reset. Errored Seconds (ES) don't and sometimes the Time since Power On/Reboot comes in useful looking at these.
Ah, it's not quite as simple as that and is one of the more difficult concepts to understand. It is as it says a Margin. A margin between the noise and wanted signal. The smaller that margin, the greater the susceptibility to errors when there are variations in noise/interference. It's all relative to the Target SNRM. This is the value that the exchange DLM (Dynamic Line Management) will use when sync is being established. The initial default for a line is 6dB. The required margin, along with line length and current noise levels, will determine the number of bits available for data transmission, this in turn defines the sync speed.
Once sync has been established, the margin will decrease if noise levels go up. If the SNRM decreases too much then errors will increase and it can reach a point where sync is lost. Because noise levels are high, for the same Target Noise Margin, less bits will be available and so when sync is re-established the speed will be slower.
The converse is also the case, when noise levels reduce.and the margin is somewhat higher than the Target, a resync will give a higher speed.
Noise (Interference) can affect only parts of the spectrum used by broadband ie.only DS or US, or indeed both. One can only guess that the recent problems with the electricity cables, and/or maybe the extensive issues at the Cab, produced noise primarily only affecting your US, hence the slower US sync speed when sync was previously established those 11+ days ago. Once the issues were fixed (noise gone), the US Margin rose significantly meaning many more bits were available and so a resync (which would take place at the Target SNRM) would mean a faster speed.
Note, If line quality is good enough, DLM can lower the Target to 3dB for the DS on a 21CN connection, but this usually takes several days/weeks with low errors and no drops for it to happen. That doesn't apply to the US. If line quality is poor DLM can raise the Target (in 3db steps).
OK, that's dealt with the connection to the exchange, now the connection to the WWW
For data to travel between you and the WWW there has to be a PPP session. (PPPoA to be precise on ADSL). Once synced to the exchange, programming at the exchange says your line should be connected to a particular ISP and your username and password is sent to the Radius Servers, and once authenticated, a Data path is then establish through to the ISP and their network to the WWW - your Internet Connection.
Indeed when you click 'Disconnect' within the TG582n, that drops the current Internet PPP Session and when you click Connect, that establishes a new one. That session is there whether your computer(s) are on or not. The Modem/router is chatting away periodically to the exchange and ISP to maintain the connection.
A misunderstanding. First, a "Graceful Disconnect" is dropping the PPP session through to powering off the modem/router. Secondly, when you drop a PPP session and establish a new one, the data path between you and Plusnet's network will most likely be different. Different end-points, different Gateway. There could have been something about a particular routing that resulted in poor throughput on a speedtest - in this case US, changing routing and Gateway most likely altered this and so improved the speedtest result. You probably made the incorrect assumption that the US margin and speed had changed which it won't from a PPP drop. Just dropping PPP and reconnecting to another Gateway 30 seconds or so later is what's called Gateway hopping. It doesn't affect the sync speeds in any way, which is the reason for the power down, so that when you power up again you establish new sync speeds.
As mentioned in the previously referenced reply #41, the reason for a "Graceful Disconnect" is to help stop the Exchange DLM from thinking your sync loss was a dropped connection. If you've been suffering a number of drops in your connection, then doing a few straight reboots to resync, particularly if combined with a high error rate, can result in DLM banding speed or raising the Target SNRM. It's a case of minimising that probability. If your connection is otherwise stable with low errors, you can happily get away with straight rebooting a couple of times.
I hope that's covered everything, I hope what's intended to be a fairly simple explanation has helped. Do ask away if anything isn't clear.
If you've managed to follow and understand that lot and would like some more in depth technical detail, rather than me re-invent the wheel, have a read here as a good starting point. There is plenty more there on the site if you want to delve further.
Bourton-on-the-Water perhaps?Whilst you have no doubt picked up a lot of knowledge since the start of this thread, I'll try and summarise (and explain) as simply as possible, most of the broadband basics in what is hopefully a logical order - don't be offended if some of it seems to be stating the obvious to you, it'll also be worded for anyone who maybe reading who has less knowledge..
Obviously a connection to the exchange is needed. It's the speed and stability of this connection that is usually the most significant factor in determining the quality of your broadband service. So the speed that you can connect with (called sync speed), will determine the maximum possible data speed that can be achieved. The sync speed will be determined by the length and quality of the cable pair to the exchange and any interference (noise) that it gets. There are 2 parts to the connection involved, the Downstream (DS) carrying the data to you, and the Upstream (US) for data you send. The DS is usually what most users find has the most significant effect on their connection, but a decent US is also important.
Whilst an ISP is responsible for the correct functioning of the broadband service you pay for, it does not own this infrastructure which is owned and maintained by BT OpenReach which the ISP has to rely on for any repair, maintenance or provision. Most (but not all) broadband problems are related to your connection to the exchange. Any problems with the line itself, which often manifest themselves as problems with phone calls, audible noise etc, will also affect the broadband and must be fixed first before correct broadband functioning can be fully restored.
Quote from: mickthefitter .....(rather than just using the darn internet like an appliance - what a silly notion!).......
Not at all. That is how the greater majority of broadband users will be using their connection. Most will be running with a trouble-free optimised connection. There will however be quite a few who will be blissfully unaware that theirs is (and perhaps always has been) running below par. Often a single minor fault doesn't result in a significant impact and may go unnoticed and it is only when a 2nd issue arises or the 1st gets worse, that a user realises a problem exists. With more than, and sometimes even with, one issue, it can often get quite complex to analyse.
Apart from the obvious checks to the phone service - quiet line tests etc - looking at the Full xDSL stats is probably the next most important aspect of this. The Uptime here is the most significant of the 3 times, as initially it can give an idea of connection stability as well as average error rate. When there is a loss of sync this Uptime and most of the error figures get reset. Errored Seconds (ES) don't and sometimes the Time since Power On/Reboot comes in useful looking at these.
Quote from: mickthefitter I'm back to recognising the SN Margin from the stats list and remembering from before, that high is bad, low is good.
Ah, it's not quite as simple as that and is one of the more difficult concepts to understand. It is as it says a Margin. A margin between the noise and wanted signal. The smaller that margin, the greater the susceptibility to errors when there are variations in noise/interference. It's all relative to the Target SNRM. This is the value that the exchange DLM (Dynamic Line Management) will use when sync is being established. The initial default for a line is 6dB. The required margin, along with line length and current noise levels, will determine the number of bits available for data transmission, this in turn defines the sync speed.
Once sync has been established, the margin will decrease if noise levels go up. If the SNRM decreases too much then errors will increase and it can reach a point where sync is lost. Because noise levels are high, for the same Target Noise Margin, less bits will be available and so when sync is re-established the speed will be slower.
The converse is also the case, when noise levels reduce.and the margin is somewhat higher than the Target, a resync will give a higher speed.
Noise (Interference) can affect only parts of the spectrum used by broadband ie.only DS or US, or indeed both. One can only guess that the recent problems with the electricity cables, and/or maybe the extensive issues at the Cab, produced noise primarily only affecting your US, hence the slower US sync speed when sync was previously established those 11+ days ago. Once the issues were fixed (noise gone), the US Margin rose significantly meaning many more bits were available and so a resync (which would take place at the Target SNRM) would mean a faster speed.
Note, If line quality is good enough, DLM can lower the Target to 3dB for the DS on a 21CN connection, but this usually takes several days/weeks with low errors and no drops for it to happen. That doesn't apply to the US. If line quality is poor DLM can raise the Target (in 3db steps).
OK, that's dealt with the connection to the exchange, now the connection to the WWW
Quote from: mickthefitter What is a 'PPP' session? Brackets 'Internet connection'? Is that every time I start up my laptop computer and get onto the internet? Regardless of the TG582n sitting there all day, powered up, plugged into the BT copper wires but having nothing to do? Or something else?........
Did my disconnecting my internet connection from within the Technicolor Gateway last Sunday night, for about three minutes, start a fresh 'PPP' session?
For data to travel between you and the WWW there has to be a PPP session. (PPPoA to be precise on ADSL). Once synced to the exchange, programming at the exchange says your line should be connected to a particular ISP and your username and password is sent to the Radius Servers, and once authenticated, a Data path is then establish through to the ISP and their network to the WWW - your Internet Connection.
Indeed when you click 'Disconnect' within the TG582n, that drops the current Internet PPP Session and when you click Connect, that establishes a new one. That session is there whether your computer(s) are on or not. The Modem/router is chatting away periodically to the exchange and ISP to maintain the connection.
Quote from: mickthefitter ........doing a graceful disconnect while leaving the TG582n happily buzzing away with 240 volts surging through it (no, I know its knocked down to train set voltage really) did improve my upstream data flow so I assume it improved the SN up statistic.
.................I'm not clear on the 'hopping gateways' reference.
Quote from: mickthefitter .............. What I'm losing here, is the difference between what happens (or is meant to happen) when I do a 'graceful disconnect' and then pull the plug on the TG582n, or do a 'graceful disconnect' and then reconnect a few minutes later, .......
A misunderstanding. First, a "Graceful Disconnect" is dropping the PPP session through to powering off the modem/router. Secondly, when you drop a PPP session and establish a new one, the data path between you and Plusnet's network will most likely be different. Different end-points, different Gateway. There could have been something about a particular routing that resulted in poor throughput on a speedtest - in this case US, changing routing and Gateway most likely altered this and so improved the speedtest result. You probably made the incorrect assumption that the US margin and speed had changed which it won't from a PPP drop. Just dropping PPP and reconnecting to another Gateway 30 seconds or so later is what's called Gateway hopping. It doesn't affect the sync speeds in any way, which is the reason for the power down, so that when you power up again you establish new sync speeds.
As mentioned in the previously referenced reply #41, the reason for a "Graceful Disconnect" is to help stop the Exchange DLM from thinking your sync loss was a dropped connection. If you've been suffering a number of drops in your connection, then doing a few straight reboots to resync, particularly if combined with a high error rate, can result in DLM banding speed or raising the Target SNRM. It's a case of minimising that probability. If your connection is otherwise stable with low errors, you can happily get away with straight rebooting a couple of times.
I hope that's covered everything, I hope what's intended to be a fairly simple explanation has helped. Do ask away if anything isn't clear.
If you've managed to follow and understand that lot and would like some more in depth technical detail, rather than me re-invent the wheel, have a read here as a good starting point. There is plenty more there on the site if you want to delve further.
Chris -
Wow, you've been busy! I think that work of reference will be there for others to see for years to come!
I've read it all, some of it went in first time, I'll read it again to make the rest go in later. Yes it appears I was misunderstanding the difference between starting a new PPP session and a re-synch. Seems I've got my internal wires crossed somewhere along the way. If I work my way back through some of the postings, I might be able to identify why. I do completely get though why doing a disconnection within the TG582n Gateway before pulling the plug gives me a better chance to avoid being banded rather than just wrenching the plug out. All that monitoring software. Watching. Waiting. Ready to pounce and destroy. Ooh, sorry, seen too many Terminator movies!
My trip to a farm in Gloucester was in connection with a Riley Elf for sale. I thought it was better than my Wolseley Hornet, which was also the subject of my paint re-touching the other night. It wasn't. Better. The Elf I mean. I would have been mad to swap my Hornet for that
That flow chart you've provided the link for, explaining how broadband works, looks remarkably similar to schematics for hydraulic systems in machinery and electrical diagrams. If I study properly I will follow it, though sadly I never did grasp electrical diagrams properly when Boots sought to train all their line technicians up to a basic electrical standard. I wasn't the only one. My mind works in an analogue, nuts-and-bolts fashion. Same with hydraulics. The practical side - dismantling, cleaning, renewing, putting everything back without losing any bits and making sure there are no leaks, I am good at. Designing or modifying a system to work differently - no. My enthusiasm for this kind of work ebbed away as machinery I was required to work on became more complex, more computerised, and was often purchased second hand with few or no manuals, or cheaply and, so it would seem, shoddily built. Then there were the times we had to mackle lines together from bits found in the 'rejects shed' - bits of machine other departments had thrown away! That, and dissatisfaction with how certain management levels did their job, are reasons why I now drive lorries. And why wasting half a day going to Gloucester to look at a Riley Elf that didn't look so good as it did in the pictures doesn't seem so bad when for over six months I was doing 2/3rds of that route every weekday!
Cheers,
Mick
Wow, you've been busy!
I think that work of reference will be there for others to see for years to come! I've read it all, some of it went in first time, I'll read it again to make the rest go in later. Yes it appears I was misunderstanding the difference between starting a new PPP session and a re-synch. Seems I've got my internal wires crossed somewhere along the way. If I work my way back through some of the postings, I might be able to identify why. I do completely get though why doing a disconnection within the TG582n Gateway before pulling the plug gives me a better chance to avoid being banded rather than just wrenching the plug out. All that monitoring software. Watching. Waiting. Ready to pounce and destroy. Ooh, sorry, seen too many Terminator movies!
My trip to a farm in Gloucester was in connection with a Riley Elf for sale. I thought it was better than my Wolseley Hornet, which was also the subject of my paint re-touching the other night. It wasn't. Better. The Elf I mean. I would have been mad to swap my Hornet for that
That flow chart you've provided the link for, explaining how broadband works, looks remarkably similar to schematics for hydraulic systems in machinery and electrical diagrams. If I study properly I will follow it, though sadly I never did grasp electrical diagrams properly when Boots sought to train all their line technicians up to a basic electrical standard. I wasn't the only one. My mind works in an analogue, nuts-and-bolts fashion. Same with hydraulics. The practical side - dismantling, cleaning, renewing, putting everything back without losing any bits and making sure there are no leaks, I am good at. Designing or modifying a system to work differently - no. My enthusiasm for this kind of work ebbed away as machinery I was required to work on became more complex, more computerised, and was often purchased second hand with few or no manuals, or cheaply and, so it would seem, shoddily built. Then there were the times we had to mackle lines together from bits found in the 'rejects shed' - bits of machine other departments had thrown away! That, and dissatisfaction with how certain management levels did their job, are reasons why I now drive lorries. And why wasting half a day going to Gloucester to look at a Riley Elf that didn't look so good as it did in the pictures doesn't seem so bad when for over six months I was doing 2/3rds of that route every weekday!
Cheers,
Mick
Well I'm glad you found my post of some help. I wouldn't worry to much about why you got your wires crossed, it's probably because a reply to you might have been worded better. I know I've changed the wording used in some of my standard replies/comments after some users have interpreted them in a different way to intended, I'll review the Graceful Disconnect one again - I think I could word it better.
Carry on watching the Terminator movies, they are more entertaining than some posts on here
I'll PM you about the "old bangers" rather than take your thread wildly off-topic I might get admonished by the Mods 
Carry on watching the Terminator movies, they are more entertaining than some posts on here
I'll PM you about the "old bangers" rather than take your thread wildly off-topic
I might get admonished by the Mods
Guess who? I'm back.
I actually performed a router shut down and start up, taking stats before and after, more than two weeks ago while I found the time, copying the results into my email program with the intention of posting them later when I found time.
(This was because there were suspected thermal issues with my router?)
Then when I started posting the stats results, I found one set of readings I'd completely botched by copying and pasting the wrong data from the router Gateway. The one after the restart. The important one. So I had no more time on that occasion and threw in the towel. Then last night while watching a rubbish 70s cop show parody called Top Coppers on iPlayer (that I actually find quite funny, but then I'm old and remember Starsky and Hutch from the first time around) the internet dropped and messed the whole thing up, meaning I'd got to re-boot my telly to get the software to load properly again, fast-forward iPlayer to the bit where my show actually cut off....so I decided to do that before-and-after stats exercise this morning.
Here we go then....BEFORE POWERING DOWN -
DSL Connection
Link Information
Uptime: 0 days, 10:19:21
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 828 / 8.599
Data Transferred (Sent/Received) [MB/GB]: 355,10 / 3,68
Output Power (Up/Down) [dBm]: 11,9 / 20,4
Line Attenuation (Up/Down) [dB]: 24,1 / 44,5
SN Margin (Up/Down) [dB]: 5,9 / 7,8
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / TSTC
Loss of Framing (Local/Remote): 18 / 0
Loss of Signal (Local/Remote): 2 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 1.286 / 10
FEC Errors (Up/Down): 36.515 / 47.279
CRC Errors (Up/Down): 1 / 23
HEC Errors (Up/Down): 0 / 134
Current line speed:
7.6 Mb
1. Best Effort Test: -provides background information.
Download Speed
6.43 Mbps
0 Mbps 7.15 Mbps
Max Achievable Speed
Download speedachieved during the test was - 6.43 Mbps
For your connection, the acceptable range of speeds is 2 Mbps-7.15 Mbps.
IP Profile for your line is - 7.58 Mbps
2. Upstream Test: -provides background information.
Upload Speed
0.45 Mbps
0 Mbps 0.83 Mbps
Max Achievable Speed
Upload speed achieved during the test was - 0.45Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
ON IMMEDIATE FIRING UP -
DSL Connection
Link Information
Uptime: 0 days, 0:01:28
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 780 / 9.248
Data Transferred (Sent/Received) [kB/kB]: 59,58 / 418,97
Output Power (Up/Down) [dBm]: 12,1 / 20,4
Line Attenuation (Up/Down) [dB]: 24,0 / 44,5
SN Margin (Up/Down) [dB]: 5,4 / 6,1
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / TSTC
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 0 / 0
FEC Errors (Up/Down): 108 / 0
CRC Errors (Up/Down): 0 / 0
HEC Errors (Up/Down): 0 / 0
Current line speed:
7.6 Mb
1. Best Effort Test: -provides background information.
Download Speed
6.54 Mbps
0 Mbps 21 Mbps
Max Achievable Speed
Download speedachieved during the test was - 6.54 Mbps
For your connection, the acceptable range of speeds is 4 Mbps-21 Mbps.
IP Profile for your line is - 8.16 Mbps
2. Upstream Test: -provides background information.
Upload Speed
0.46 Mbps
0 Mbps 0.83 Mbps
Max Achievable Speed
Upload speed achieved during the test was - 0.46Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
ONE HOUR AFTER RE-START -
DSL Connection
Link Information
Uptime: 0 days, 1:18:22
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 780 / 9.248
Data Transferred (Sent/Received) [MB/MB]: 1,18 / 15,34
Output Power (Up/Down) [dBm]: 12,1 / 20,4
Line Attenuation (Up/Down) [dB]: 24,0 / 44,5
SN Margin (Up/Down) [dB]: 5,3 / 5,9
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / TSTC
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 9 / 0
FEC Errors (Up/Down): 12.160 / 1.752
CRC Errors (Up/Down): 0 / 12
HEC Errors (Up/Down): 0 / 328
Current line speed:
7.6 Mb
1. Best Effort Test: -provides background information.
Download Speed
6.51 Mbps
0 Mbps 21 Mbps
Max Achievable Speed
Download speedachieved during the test was - 6.51 Mbps
For your connection, the acceptable range of speeds is 4 Mbps-21 Mbps.
IP Profile for your line is - 8.16 Mbps
2. Upstream Test: -provides background information.
Upload Speed
0.46 Mbps
0 Mbps 0.83 Mbps
Max Achievable Speed
Upload speed achieved during the test was - 0.46Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
The main thing I've noticed is that the BT line test result said my broadband speed range was 2Mb - 7.15Mb before the shutdown and now reckons its between 4Mb and 21Mb after! I'm not sure how that works!
Mick
I actually performed a router shut down and start up, taking stats before and after, more than two weeks ago while I found the time, copying the results into my email program with the intention of posting them later when I found time.
(This was because there were suspected thermal issues with my router?)
Then when I started posting the stats results, I found one set of readings I'd completely botched by copying and pasting the wrong data from the router Gateway. The one after the restart. The important one. So I had no more time on that occasion and threw in the towel. Then last night while watching a rubbish 70s cop show parody called Top Coppers on iPlayer (that I actually find quite funny, but then I'm old and remember Starsky and Hutch from the first time around) the internet dropped and messed the whole thing up, meaning I'd got to re-boot my telly to get the software to load properly again, fast-forward iPlayer to the bit where my show actually cut off....so I decided to do that before-and-after stats exercise this morning.
Here we go then....BEFORE POWERING DOWN -
DSL Connection
Link Information
Uptime: 0 days, 10:19:21
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 828 / 8.599
Data Transferred (Sent/Received) [MB/GB]: 355,10 / 3,68
Output Power (Up/Down) [dBm]: 11,9 / 20,4
Line Attenuation (Up/Down) [dB]: 24,1 / 44,5
SN Margin (Up/Down) [dB]: 5,9 / 7,8
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / TSTC
Loss of Framing (Local/Remote): 18 / 0
Loss of Signal (Local/Remote): 2 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 1.286 / 10
FEC Errors (Up/Down): 36.515 / 47.279
CRC Errors (Up/Down): 1 / 23
HEC Errors (Up/Down): 0 / 134
Current line speed:
7.6 Mb
1. Best Effort Test: -provides background information.
Download Speed
6.43 Mbps
0 Mbps 7.15 Mbps
Max Achievable Speed
Download speedachieved during the test was - 6.43 Mbps
For your connection, the acceptable range of speeds is 2 Mbps-7.15 Mbps.
IP Profile for your line is - 7.58 Mbps
2. Upstream Test: -provides background information.
Upload Speed
0.45 Mbps
0 Mbps 0.83 Mbps
Max Achievable Speed
Upload speed achieved during the test was - 0.45Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
ON IMMEDIATE FIRING UP -
DSL Connection
Link Information
Uptime: 0 days, 0:01:28
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 780 / 9.248
Data Transferred (Sent/Received) [kB/kB]: 59,58 / 418,97
Output Power (Up/Down) [dBm]: 12,1 / 20,4
Line Attenuation (Up/Down) [dB]: 24,0 / 44,5
SN Margin (Up/Down) [dB]: 5,4 / 6,1
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / TSTC
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 0 / 0
FEC Errors (Up/Down): 108 / 0
CRC Errors (Up/Down): 0 / 0
HEC Errors (Up/Down): 0 / 0
Current line speed:
7.6 Mb
1. Best Effort Test: -provides background information.
Download Speed
6.54 Mbps
0 Mbps 21 Mbps
Max Achievable Speed
Download speedachieved during the test was - 6.54 Mbps
For your connection, the acceptable range of speeds is 4 Mbps-21 Mbps.
IP Profile for your line is - 8.16 Mbps
2. Upstream Test: -provides background information.
Upload Speed
0.46 Mbps
0 Mbps 0.83 Mbps
Max Achievable Speed
Upload speed achieved during the test was - 0.46Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
ONE HOUR AFTER RE-START -
DSL Connection
Link Information
Uptime: 0 days, 1:18:22
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 780 / 9.248
Data Transferred (Sent/Received) [MB/MB]: 1,18 / 15,34
Output Power (Up/Down) [dBm]: 12,1 / 20,4
Line Attenuation (Up/Down) [dB]: 24,0 / 44,5
SN Margin (Up/Down) [dB]: 5,3 / 5,9
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / TSTC
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 9 / 0
FEC Errors (Up/Down): 12.160 / 1.752
CRC Errors (Up/Down): 0 / 12
HEC Errors (Up/Down): 0 / 328
Current line speed:
7.6 Mb
1. Best Effort Test: -provides background information.
Download Speed
6.51 Mbps
0 Mbps 21 Mbps
Max Achievable Speed
Download speedachieved during the test was - 6.51 Mbps
For your connection, the acceptable range of speeds is 4 Mbps-21 Mbps.
IP Profile for your line is - 8.16 Mbps
2. Upstream Test: -provides background information.
Upload Speed
0.46 Mbps
0 Mbps 0.83 Mbps
Max Achievable Speed
Upload speed achieved during the test was - 0.46Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
The main thing I've noticed is that the BT line test result said my broadband speed range was 2Mb - 7.15Mb before the shutdown and now reckons its between 4Mb and 21Mb after! I'm not sure how that works!
Mick
Hi Mick,
hope things are still OK, I see ejs helped you out there. Out of curiosity, how long was the 582n powered off before the restart? I'm still puzzling a bit over the way the US SNRM seems to behave initially, before it settles at around 5.4. Nothing to panic about
hope things are still OK, I see ejs helped you out there. Out of curiosity, how long was the 582n powered off before the restart? I'm still puzzling a bit over the way the US SNRM seems to behave initially, before it settles at around 5.4. Nothing to panic about