Poor single thread performance problems return? :: Zen Internet

User comments on ISPs
>> Zen Internet

Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | [11] | 12 | 13 | 14 | 15 | (show all)

Print Thread

Ixel
(member) Sat 02-Sep-17 02:24:16

Re: Poor single thread performance problems return?

[re: deleted] [link to this post]

Well, I just had an email again. They noticed that my line has re-synced a lot (some or maybe all of which was from me trying to identify the cause of the packet loss and slow single threaded download speed) and are possibly believing that my line is the main cause of this issue now. They want me to retry changing things like the cables, router, filters or such, and to confirm the dates and times I make these changes. They also want permission to perform intrusive line tests, I'm not 100% certain what that means though?

Finally they tell me if I'm unable to still stabilise the connection that an engineer should be sent out to investigate but charges may apply. I honestly don't know what to do at this point, maybe there is a fault on my line? I asked for some input on the Hlog and QLN I recently posted on another forum and here but I was told the Hlog seemed fine and the QLN graph indicates crosstalk. However, I realise these graphs might not always highlight a potential fault. I do know that I'm suffering a large amount of error seconds (almost one error second for every second of uptime last time I tried) if the HG612 is running with default settings (e.g. not capped), so maybe I should get this looked into and hope the engineer doesn't charge me for potentially 'no fault found' if an engineer is eventually sent out?

Any input welcome before I decide how to proceed. Thanks.

EDIT: Proceeded with this, nevermind.

Edited by Ixel (Sat 02-Sep-17 10:27:15)

Chrysalis
(legend) Sat 02-Sep-17 11:27:04

Re: Poor single thread performance problems return?

[re: Ixel] [link to this post]

I dont usually defend isps, but I am not convinced in your case.

When congestion is the cause I would expect a dusk hours test to be pretty much perfect, even a very loaded isp can avoid saturation at those hours as the network load is a fraction of peak time demand.

A network config issue can still look worse at peak because even without congestion there can be delays somewhere along the packet route at busier times due to cpu load etc. on the appropriate equipment which can yield the results you are presenting.

You really need to rule out a limited RWIN having a factor here, and then assess you got no MTU/MSS problems as well.

The ping graph looks a bit more damning but packet loss can be caused by interference as much as congestion on dsl. You seem to have no extra jitter/latency on that time range just the packet loss.

I would consider it a priority in your current diagnosis to get perfect results off peak, once you achieve that you are in a better standing to diagnose whats going on at peak.

Sky Fibre Pro BQM - IPv4 BQM - IPv6 BQM - IPv6 Backup

Edited by Chrysalis (Sat 02-Sep-17 12:26:57)

PaulKirby
(knowledge is power) Sat 02-Sep-17 11:51:52

Re: Poor single thread performance problems return?

[re: Ixel] [link to this post]

You will only get charged if the engineer finds the issue is down to internal wiring in your home.

I was talking to BT Home and also Business sections the other day enquiring about the price differences between the two lots of packages.
And while chatting about all the issues that use to have when I was on ADSLx with the line going dead when it rained etc.

Every time an engineer was sent out I was always worried about being charged that ~£129 if they couldn't find an issue due to it being an intermittent fault, I was told a charge will only occur when the fault is found to be internal, i.e. wiring in the home.

So I was never charged.

So I would check your wiring, extensions if any etc.

Paul

BTBroadband - Infinity 4 310Mbps (down), 31Mbps (up) FVA
TBB Speedtest | Linksys WRT 3200 ACM (BQM)

Ixel
(member) Sat 02-Sep-17 13:49:11

Re: Poor single thread performance problems return?

[re: Chrysalis] [link to this post]

Well, my packet loss is far less at off peak than it is at peak time. However, what I got from the call is that this absurd amount of error seconds I'm getting don't matter once DLM masks the problem (interleaving is applied).

Text

xdslcmd info --stats
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 0Last initialization procedure status:   0
Max:    Upstream rate = 13890 Kbps, Downstream rate = 54968 KbpsBearer: 0, Upstream rate = 13892 Kbps, Downstream rate = 55790 Kbps
 Link Power State:       L0
Mode:                   VDSL2 Annex BVDSL2 Profile:          Profile 17a
TPS-TC:                 PTM Mode(0x0)Trellis:                U:ON /D:ON
Line Status:            No DefectTraining Status:        Showtime
                Down            UpSNR (dB):        6.1             6.0
Attn(dB):        19.9            0.0Pwr(dBm):        6.9             6.8
                        VDSL2 framing                        Bearer 0
MSGc:           18              18B:              239             238
M:              1               1T:              64              21
R:              0               16S:              0.1369          0.5475
L:              14024           3726D:              1               1
I:              240             255N:              240             255
                        Counters                        Bearer 0
OHF:            5890625         1502528OHFErr:         29797           2
RS:             0               135598RSCorr:         0               12
RSUnCorr:       0               0 
                        Bearer 0HEC:            122794          0
OCD:            4242            0LCD:            4242            0
Total Cells:    1388898485              0Data Cells:     20594630                0
Drop Cells:     0Bit Errors:     0               0
 ES:             7279            2
SES:            0               0UAS:            268             268
AS:             12955 
                        Bearer 0INP:            0.00            0.00
INPRein:        0.00            0.00delay:          0               0
PER:            2.19            8.65OR:             87.30           22.17
AgR:            55877.72        13914.49 
Bitswap:        7118/7123               0/0 
Total time = 3 hours 40 min 23 secFEC:            0               12
CRC:            29797           2ES:             7279            2
SES:            0               0UAS:            268             268
LOS:            0               0LOF:            0               0
LOM:            0               0Latest 15 minutes time = 10 min 23 sec
FEC:            0               0CRC:            1326            0
ES:             350             0SES:            0               0
UAS:            0               0LOS:            0               0
LOF:            0               0LOM:            0               0
Previous 15 minutes time = 15 min 0 secFEC:            0               0
CRC:            2047            0ES:             492             0
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
LOM:            0               0Latest 1 day time = 3 hours 40 min 23 sec
FEC:            0               12CRC:            29797           2
ES:             7279            2SES:            0               0
UAS:            268             268LOS:            0               0
LOF:            0               0LOM:            0               0
Previous 1 day time = 0 secFEC:            0               0
CRC:            0               0ES:             0               0
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
LOM:            0               0Since Link time = 3 hours 35 min 53 sec
FEC:            0               12CRC:            29797           2
ES:             7279            2SES:            0               0
UAS:            0               0LOS:            0               0
LOF:            0               0LOM:            0               0

I'm fairly certain that these error seconds are coming from the mid to upper end of the D3 band, as when I've stopped using that section of D3 on the HG612 (by capping the speed) or disabling D3 on the ASUS I don't get this constant and absurd amount of error seconds anymore. I can't believe heavy crosstalk is simply the cause of this as surely bitswapping should to some degree workaround it?

However, going back to the packet loss I've also changed routers to knock out the possibility that it's a router issue. I've monitored the DrayTek stats in regards to CPU usage and it's fine. I've not had this problem until recently and I've done nothing here that should cause an increase in packet loss mostly at peak time. Zen did state originally that the continuous ping tests they did on my connection and some other Zen connections at my exchange were producing similar amounts of packet loss at similar times, based on early indications, so while indeed there might be an issue with my line around the D3 band I don't feel it's related to why I'm getting packet loss along with some other Zen customers at my exchange (based on their results).

I will do some other checks to determine if I have a bad MTU but I honestly doubt it. The DrayTek is being pinged after all, and that has a setting of 1492 on the PPPoE connection which should by all means be correct. The DSL connection isn't stressed out, just general surfing, VoIP, the odd download such as a driver, YouTube or iPlayer on one or two devices generally. No torrents or related that could really stress the router or the connection itself.

I'll see how the next week or two goes in regards to my current problem with the D3 band, if that remains unresolved and just accepted by DLM masking with interleaving then I might pay the early termination charge and move over to A&A. I hear they have a good history at getting problems resolved, but hopefully it won't come to that. Just right now I'm not too convinced, especially as I see some others are having packet loss issues with Zen.

The packet loss was still occurring mostly during peak time when I didn't have the amount of errors I have now (as I've uncapped the modem). It's perhaps a little worse now but that's understandable given the stats above!

In reply to a post by PaulKirby:
You will only get charged if the engineer finds the issue is down to internal wiring in your home.

I was talking to BT Home and also Business sections the other day enquiring about the price differences between the two lots of packages.
And while chatting about all the issues that use to have when I was on ADSLx with the line going dead when it rained etc.

Every time an engineer was sent out I was always worried about being charged that ~£129 if they couldn't find an issue due to it being an intermittent fault, I was told a charge will only occur when the fault is found to be internal, i.e. wiring in the home.

So I was never charged.

So I would check your wiring, extensions if any etc.

Paul

Thanks Paul. Zen told me something different, that they could charge if there's no fault found. However I'll go along with what you said rather than what I was told by Zen smile

. Regarding internal wiring, there's no extension wiring or such, just the master socket with a MK3 SSFP.

Edited by Ixel (Sat 02-Sep-17 13:53:00)

Chrysalis
(legend) Sat 02-Sep-17 14:12:48

Re: Poor single thread performance problems return?

[re: Ixel] [link to this post]

those ES are way too high to ignore.

I think given the high ES presented, and the fact you cannot get off peak to perform well, you need to move away from the congestion claims at least for now.

Sort out your ES and sort out your off peak problems.

Can you get yourself on MDWS so we can see what time of day these ES are occuring?

Also if you have found disabling D3 fixes the ES, why have you enabled it again.

Your options for the ES seem to be.

1 - Fix yourself via capping sync rate, disabling problematic tones.
2 - Allowing DLM to mask the issue via FEC+interleaving at cost of latency and sync speed.
3 - Getting openreach to fix the underlying problem, probably difficult with zen.

This should be your first priority.

When ES is under control, retest off peak, if it remains poor assess your LAN setup, I dont think zen are to blame if you getting that performance in the morning.

RWIN - depends on OS.

Windows XP - ancient OS shouldnt be used now days, but if you are you deffo need to pump RWIN manually, default is designed for dialup.
Windows vista+, make sure you dont disable auto tcp tuning.
Linux - default configuration is good, boot a live cd open up a browser and run the TBB speedtest.

http://justbrowsing.info/

Router MTU in my opinion can bet set to 1492 but is better to also set client devices to lower MTU, so you not relying on MTU detection algorithms which can be unreliable. More of a pain in the backside to do this way but performs better. Is a big reason I am using sky now to get away from pppoe MTU troubles.

good luck.

Sky Fibre Pro BQM - IPv4 BQM - IPv6 BQM - IPv6 Backup

Edited by Chrysalis (Sat 02-Sep-17 14:24:00)

Ixel
(member) Sat 02-Sep-17 14:19:21

Re: Poor single thread performance problems return?

[re: Chrysalis] [link to this post]

I see, yeah I agree this is a problem that currently needs sorting before packet loss can be looked into.

I'm already on MDWS - my username is Ixel - you should see at the moment for the last few hours that I'm consistently getting around 2000 ES per hour by the looks of it while the modem is uncapped and fastpath.

Edited by Ixel (Sat 02-Sep-17 14:20:45)

Chrysalis
(legend) Sat 02-Sep-17 14:24:30

Re: Poor single thread performance problems return?

[re: Ixel] [link to this post]

I just edited with more info, please try the live cd I put in the post. (best to after you sort the ES).

I see you only just started MDWS earlier today so I will wait for at least 24 hour of data plots to analyse more. smile

Sky Fibre Pro BQM - IPv4 BQM - IPv6 BQM - IPv6 Backup

Edited by Chrysalis (Sat 02-Sep-17 14:28:21)

Ixel
(member) Sat 02-Sep-17 14:34:24

Re: Poor single thread performance problems return?

[re: Chrysalis] [link to this post]

Thanks for that, that looks handy, I'll give that a try once the ES problem is dealt with. Yeah I started it once I responded to Zen this morning to confirm I'm in the test socket at the moment with a microfilter and running the HG612. I'm also curious to see if the error seconds will stop or otherwise significantly decrease before DLM intervenes, I just have a feeling they won't. They'll be getting back to me on Monday but yeah I agree, option 3 might be tricky with Zen where A&A would probably get it done I imagine. If it's absolutely necessary I'll pay an ETC and move to them and hope, but I'd rather not if I don't have to. On the other hand it might kill two birds with one stone if I had to do that in the end. Either way I can't really accept the problem can be classed as resolved if interleaving will just be masking it.

Chrysalis
(legend) Sat 02-Sep-17 15:45:33

Re: Poor single thread performance problems return?

[re: Ixel] [link to this post]

your ES is horrific, hard to think that wont be service affecting, DLM I expect will be taking action within a day.

Also the zen attitude to the ES doesnt surprise me given previous reports about issues on here and their t&c that strongly discourages openreach callouts.

Sky Fibre Pro BQM - IPv4 BQM - IPv6 BQM - IPv6 Backup

tommy45
(knowledge is power) Sat 02-Sep-17 15:47:20

Re: Poor single thread performance problems return?

[re: Ixel] [link to this post]

Some support staff are better than others at Zen, I found that once you have managed to convince them that there is a fault that requires an engineer visit, they will offer that, subject to you accepting to pay the BTOR charges should no fault be found ect
Though it can be frustrating in the early stages when reporting faults

Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | [11] | 12 | 13 | 14 | 15 | (show all)

Print Thread

Jump to