Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Ticket open since 28th FEB; OK now I'm asking.....
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Feedback
- :
- Plusnet Feedback
- :
- Re: Ticket open since 28th FEB; OK now I'm asking...
Ticket open since 28th FEB; OK now I'm asking.....
03-05-2011 7:45 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I have had an on going issue and ticket open since the Monday 28th Feb.
Since that time I have three engineer visits and now have a rather lenghty ticket No. #40313333 re constant sync but dropping ppp. new routers 3 of my own 2 of PNs new face plate fitted by BT My d and e side have been replaced more recently BT have failed to carry out the requested tie pair modification. etc.
I have been advised of call backs on friday and last night requested one today. Neither call back has been received.
All weekend since the last BT visits I have updated my ticket with line stats etc to show the ever increasing errors on my line something which PN had said they would raise with the BT person under whom my issue was being investigated and had agreed to the tie pair modification.
All my line stats show sync of over 6500, yesterday PN post an updated my ticket below all my provided line stats with a line speed of 1500 (approx) and a tag line saying all is OK. Looking at the line stats on the ticket would clearly have indicated al was NOT OK.
Concerned about the massive drop in line speed I called PN and last night PN were able to remotely check my line and advised on line speeds around the 6500 mark as is norm. I have returned home and my line is sync as below.
BT gives a line speed of over 5500 which was what i was getting previously.
What is my gripe?
A call to advise why tie pair was not carried out as requested has still to be received; a call requested for tonight has still to be received the ticket has not been updated to explain the next step re the tie pair request or why my line was passed as OK when the speed was clearly of 5mb down on normal. No notification has been posted to advise that my request for a call has been received.
I have been paying for this service for 3 months and I have spent more time trying to get it fixed than I should need too.
Could someone from PN please take control of the ticket and help.
Regards,
podman
DSL Connection
Link Information
Uptime: 0 days, 11:50:08
DSL Type: G.992.5 annex A
Maximum Bandwidth (Up/Down) [kbps/kbps]: 864 / 7,104
Bandwidth (Up/Down) [kbps/kbps]: 446 / 6,912
Data Transferred (Sent/Received) [kB/GB]: 256.00 / 211.96
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 26.5 / 41.0
SN Margin (Up/Down) [dB]: 24.0 / 4.5
Vendor ID (Local/Remote): TMMB / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 3 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 4 / 0
FEC Errors (Up/Down): 101 / 2,856,803
CRC Errors (Up/Down): 0 / 467
HEC Errors (Up/Down): 0 / NA
Since that time I have three engineer visits and now have a rather lenghty ticket No. #40313333 re constant sync but dropping ppp. new routers 3 of my own 2 of PNs new face plate fitted by BT My d and e side have been replaced more recently BT have failed to carry out the requested tie pair modification. etc.
I have been advised of call backs on friday and last night requested one today. Neither call back has been received.
All weekend since the last BT visits I have updated my ticket with line stats etc to show the ever increasing errors on my line something which PN had said they would raise with the BT person under whom my issue was being investigated and had agreed to the tie pair modification.
All my line stats show sync of over 6500, yesterday PN post an updated my ticket below all my provided line stats with a line speed of 1500 (approx) and a tag line saying all is OK. Looking at the line stats on the ticket would clearly have indicated al was NOT OK.
Concerned about the massive drop in line speed I called PN and last night PN were able to remotely check my line and advised on line speeds around the 6500 mark as is norm. I have returned home and my line is sync as below.
BT gives a line speed of over 5500 which was what i was getting previously.
What is my gripe?
A call to advise why tie pair was not carried out as requested has still to be received; a call requested for tonight has still to be received the ticket has not been updated to explain the next step re the tie pair request or why my line was passed as OK when the speed was clearly of 5mb down on normal. No notification has been posted to advise that my request for a call has been received.
I have been paying for this service for 3 months and I have spent more time trying to get it fixed than I should need too.
Could someone from PN please take control of the ticket and help.
Regards,
podman
DSL Connection
Link Information
Uptime: 0 days, 11:50:08
DSL Type: G.992.5 annex A
Maximum Bandwidth (Up/Down) [kbps/kbps]: 864 / 7,104
Bandwidth (Up/Down) [kbps/kbps]: 446 / 6,912
Data Transferred (Sent/Received) [kB/GB]: 256.00 / 211.96
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 26.5 / 41.0
SN Margin (Up/Down) [dB]: 24.0 / 4.5
Vendor ID (Local/Remote): TMMB / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 3 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 4 / 0
FEC Errors (Up/Down): 101 / 2,856,803
CRC Errors (Up/Down): 0 / 467
HEC Errors (Up/Down): 0 / NA
4 REPLIES 4
Re: Ticket open since 28th FEB; OK now I'm asking.....
03-05-2011 8:38 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
since the last post approx 2hrs ago. Last week Pn advised they were going to contact BT re the on going errors on the line here are the increases in 2 hrs.
DSL Connection
Link Information
Uptime: 0 days, 13:46:56
DSL Type: G.992.5 annex A
Maximum Bandwidth (Up/Down) [kbps/kbps]: 864 / 7,204
Bandwidth (Up/Down) [kbps/kbps]: 446 / 6,912
Data Transferred (Sent/Received) [MB/MB]: 7.81 / 47.07
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 26.5 / 41.0
SN Margin (Up/Down) [dB]: 24.0 / 5.5
Vendor ID (Local/Remote): TMMB / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 3 / 0 (this is new today)
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 4 / 0 (does this not mean errors every 4th second!)
FEC Errors (Up/Down): 222 / 3,069,145
CRC Errors (Up/Down): 0 / 545
HEC Errors (Up/Down): 0 / NA
DSL Connection
Link Information
Uptime: 0 days, 13:46:56
DSL Type: G.992.5 annex A
Maximum Bandwidth (Up/Down) [kbps/kbps]: 864 / 7,204
Bandwidth (Up/Down) [kbps/kbps]: 446 / 6,912
Data Transferred (Sent/Received) [MB/MB]: 7.81 / 47.07
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 26.5 / 41.0
SN Margin (Up/Down) [dB]: 24.0 / 5.5
Vendor ID (Local/Remote): TMMB / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 3 / 0 (this is new today)
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 4 / 0 (does this not mean errors every 4th second!)
FEC Errors (Up/Down): 222 / 3,069,145
CRC Errors (Up/Down): 0 / 545
HEC Errors (Up/Down): 0 / NA
Re: Ticket open since 28th FEB; OK now I'm asking.....
03-05-2011 8:43 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Error seconds. It ink means now long in total the router has been in an "error state". Eg. If each error occurred took 1second to sort itself and you'd had 10 errors, then error seconds would say 10.
Re: Ticket open since 28th FEB; OK now I'm asking.....
03-05-2011 11:26 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Déjà vu
Hope it gets sorted, and I'll swap those line syncs and speeds
Hope it gets sorted, and I'll swap those line syncs and speeds
Re: Ticket open since 28th FEB; OK now I'm asking.....
03-05-2011 11:53 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
An "errored second" (ES) is a second-long period where at least one error occurred. A "severe errored second" (SES) is the same second-long period where a severe number of errors occurred. Something like 30% of the blocks transmitted within the period are faulty.
So broadly, an ES just indicates that something happened (such as one or more CRC error), while an SES indicates that something very concentrated happened. Some ES, without SES, is perfectly natural.
podman - you mention "ongoing errors on the line", and show the increase over 2 hours. Which errors on there are you looking at, to get worried about? Or are there worse examples in your archive?
The FEC aren't errors - they are small blocks of data that the "forward error correction" process has fixed. The number is high, but your line is coping with the stuff just fine. FEC is enabled at the same time as interleaving, so it certainly appears that you want to leave that turned on!
The CRC are proper errors. These are the cases where something happened badly enough that FEC couldn't fix things, and require a (larger) block of data to be resent. You're getting about 40 an hour there, which is not massively significant, about 0.02% I think. The strange thing is that your ES counter isn't increasing. I suspect your router is not counting all the stats properly, which is an unfortunately common experience.
Note too that there is a scale difference. FEC blocks are much smaller than CRC blocks, I think 68x.
But overall, those don't seem to be bad numbers, that would have a bad effect on PPP.
My line (without interleaving) runs at about 8 CRC errors per hour, and 6 ES per hour, with no SES. But very occasionally, I can get a huge burst of CRC errors - last month the worst was a burst in a 15 minute window of 850 CRCs with 130 ES and 5 SES. But there were no obvious effects on the connection.
So broadly, an ES just indicates that something happened (such as one or more CRC error), while an SES indicates that something very concentrated happened. Some ES, without SES, is perfectly natural.
podman - you mention "ongoing errors on the line", and show the increase over 2 hours. Which errors on there are you looking at, to get worried about? Or are there worse examples in your archive?
The FEC aren't errors - they are small blocks of data that the "forward error correction" process has fixed. The number is high, but your line is coping with the stuff just fine. FEC is enabled at the same time as interleaving, so it certainly appears that you want to leave that turned on!
The CRC are proper errors. These are the cases where something happened badly enough that FEC couldn't fix things, and require a (larger) block of data to be resent. You're getting about 40 an hour there, which is not massively significant, about 0.02% I think. The strange thing is that your ES counter isn't increasing. I suspect your router is not counting all the stats properly, which is an unfortunately common experience.
Note too that there is a scale difference. FEC blocks are much smaller than CRC blocks, I think 68x.
But overall, those don't seem to be bad numbers, that would have a bad effect on PPP.
My line (without interleaving) runs at about 8 CRC errors per hour, and 6 ES per hour, with no SES. But very occasionally, I can get a huge burst of CRC errors - last month the worst was a burst in a 15 minute window of 850 CRCs with 130 ES and 5 SES. But there were no obvious effects on the connection.
Plusnet Customer
Using FTTC since 2011. Currently on 80/20 Unlimited Fibre Extra.
Using FTTC since 2011. Currently on 80/20 Unlimited Fibre Extra.
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Feedback
- :
- Plusnet Feedback
- :
- Re: Ticket open since 28th FEB; OK now I'm asking...