Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: shadow4dog on September 20, 2020, 03:38:37 PM
-
My line was one of the first lines to be activated on the ECI cabinet some 7 or 8 years ago. At that time I was able to get the full sync 80/20 with attainable in the 130Mb. We're physically about 100m from the cabinet, though the modem says it's about twice as far. The line has been on fastpath continuously apart from when changing ISP...
When my neighbors found out about FTTC, the crosstalk started and my lines sync dropped down from 80Mb to about 61Mb today.
Featured Products Downstream Line Rate(Mbps) Upstream Line Rate (Mbps) Downstream Handback
Threshold(Mbps) WBC FTTC Availability Date WBC SOGEA Availability Date Left in Jumper
High Low High Low
VDSL Range A (Clean) 80 71.1 20 19 65.3 Available Available --
VDSL Range B (Impacted) 80 68.9 20 19 62.2 Available Available --Recently we had a power cut, during which period my modem reconnected super quickly and achieved 77Mb sync but with a 0db margin. That night DLM resynced it back to 60Mb.
As an experiment I thought I'd play about with my Draytek 130 and asked it to resync the line with a 3db margin... my line speed went up to 74Mb and my errors went up to about 10 ES per hour. At 61Mb it errors at around 3 ES per hour. The CAB that night resynced the line, but as my modem was set at 3db it stayed at the same sync rate.
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 73993000 bps US Actual Rate : 20000000 bps
DS Attainable Rate : 80607704 bps US Attainable Rate : 23805000 bps
DS Path Mode : Fast US Path Mode : Fast
DS Interleave Depth : 1 US Interleave Depth : 1
NE Current Attenuation : 12 dB Cur SNR Margin : 3 dB
DS actual PSD : 1. 3 dB US actual PSD : 1. 5 dB
NE CRC Count : 967 FE CRC Count : 502
NE ES Count : 914 FE ES Count : 466
Xdsl Reset Times : 0 Xdsl Link Times : 3
ITU Version[0] : fe004452 ITU Version[1] : 41590000
VDSL Firmware Version : 05-07-09-0F-01-07 [with Vectoring support]
Power Management Mode : DSL_G997_PMS_L0
Test Mode : DISABLE
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 11 dB Far SNR Margin : 6 dB
CO ITU Version[0] : b5004946 CO ITU Version[1] : 544eb206
DSLAM CHIPSET VENDOR : < IFTN >
5 days later the line seems ok. I started to get worried that the DLM will put interleve on so I've resynced it at a 4db margin, which has taken the line sync to 70Mb. I'm hoping that the decrease in errors will make DLM less inclined to interfere...
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 70493000 bps US Actual Rate : 20000000 bps
DS Attainable Rate : 70720408 bps US Attainable Rate : 24012000 bps
DS Path Mode : Fast US Path Mode : Fast
DS Interleave Depth : 1 US Interleave Depth : 1
NE Current Attenuation : 12 dB Cur SNR Margin : 4 dB
DS actual PSD : 1. 2 dB US actual PSD : 1. 4 dB
NE CRC Count : 1 FE CRC Count : 505
NE ES Count : 1 FE ES Count : 469
Xdsl Reset Times : 0 Xdsl Link Times : 4
ITU Version[0] : fe004452 ITU Version[1] : 41590000
VDSL Firmware Version : 05-07-09-0F-01-07 [with Vectoring support]
Power Management Mode : DSL_G997_PMS_L0
Test Mode : DISABLE
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 11 dB Far SNR Margin : 6 dB
CO ITU Version[0] : b5004946 CO ITU Version[1] : 544eb206
DSLAM CHIPSET VENDOR : < IFTN >
>
What I'm after is the compromise between reliability and speed. With sync at 74 I increased my download speed without massive line errors, and at 70Mb I feel more comfortable, but I wanted to know what others might recommend.
vdsl status more
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Near End Far End Note
Trellis : 1 1
Bitswap : 0 1
ReTxEnable : 0 0
VirtualNoise : 0 0
20BitSupport : 0 0
LatencyPath : 0 0
LOS : 2 0
LOF : 0 0
LPR : 0 0
LOM : 0 0
SosSuccess : 0 0
NCD : 0 0
LCD : 0 0
FECS : 17 5359 (seconds)
ES : 1 469 (seconds)
SES : 0 0 (seconds)
LOSS : 0 22 (seconds)
UAS : 41 542 (seconds)
HECError : 0 0
CRC : 1 505
RsCorrection : 0 0
INP : 0 0 (symbols)
InterleaveDelay : 0 0 (1/100 ms)
NFEC : 255 255
RFEC : 16 16
LSYMB : 5410 18890
INTLVBLOCK : 255 255
AELEM : 0 ----
>
Thanks
Tim
-
We don't really know. My worse line seemed stable at 3.4dB but after many months DLM enabled interleaving. This only went away when I got into the G.INP trial where I had to go back to 6dB as my Home Hub 5A wasn't stable with G.INP.
My better line also seemed to run fine, never got interleaved but got banded to 6dB for no obvious reason.
-
My last stats, for reference:
Type ? For command help
> v s
---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 79995000 bps US Actual Rate : 20000000 bps
DS Attainable Rate : 89316472 bps US Attainable Rate : 22633768 bps
DS Path Mode : Fast US Path Mode : Fast
DS Interleave Depth : 1 US Interleave Depth : 1
NE Current Attenuation : 10 dB Cur SNR Margin : 5 dB
DS actual PSD : -1.-7 dB US actual PSD : -1.-6 dB
NE CRC Count : 0 FE CRC Count : 302
NE ES Count : 0 FE ES Count : 72
Xdsl Reset Times : 0 Xdsl Link Times : 2
ITU Version[0] : fe004452 ITU Version[1] : 41590000
VDSL Firmware Version : 05-07-09-0F-01-07 [with Vectoring support]
Power Management Mode : DSL_G997_PMS_L0
Test Mode : DISABLE
-------------------------------- ATU-C Info ---------------------------------
Far Current Attenuation : 10 dB Far SNR Margin : 6 dB
CO ITU Version[0] : b5004946 CO ITU Version[1] : 544eb206
DSLAM CHIPSET VENDOR : < IFTN >
I did v snr to between 4 to 4.9dB to chase full performance - like you I had no difficulty achieving 80/20 when I was the first on the cabinet, but it drifted down as other VDSL connections were added. 120m direct to cabinet, 140m or so ducted line length.
The biggest change for me was running the 'tweaked for ECI' alternative firmware load. With that installed I could remove all the snr delta, hit 5dB and max out with a good margin above the capped rate. Worth checking that you are on the latest v3.8.4.1 'alternative' load and not the 'BT' version that works better with Huwaei cabinets:
https://www.draytek.co.uk/support/downloads/vigor-130/send/257-vigor-130/1809-v130-3841-579f17
I did have a period where the speed slowly decayed and the dreaded interleave plus banding appeared. A simple re-termination at my cabinet fixed that.
-
Thank you both for your very helpful advice.
When I first installed the Vigor 130 I was quite disappointed. My line had synced at 69Mb with the Fritzbox that Zen had supplied, but then with the Vigor it was down to 61Mb. And then I discovered the alternative firmware which seemed to allow it to sync slightly higher.
I needed the Vigor because I also run pfSense in load balancing between a Zen and Sky FTTC connection. The Fritzbox kind of cheats with PPPoE passthrough but restricts the line to an MTU of 1492 and for whatever insane reason, I like my MTU to be 1500!
Thanks again.
Tim
-
The performance difference with smaller packets is probably not huge but I agree, 'let packets be packets'. Anyway baby jumbo frames seem to confuse our US cousins, so there is that too. ;D
-
I had to roll back Baby Jumbo on my setup as for some reason it suddenly stopped playing nice on my Zen line.
-
That's unfortunate; I had presumed Zen and other ISPs on the Openreach backbone would be obliged to support them.
-
@Robbie full 1500 byte IP packets are fine on the BT network. After all, all single box users with combined modem-routers send them and PPPoA as used by old-fashioned ADSL/ADSL2/2+ sends full size 1500 byte PDUs. I seem to remember vaguely something about BT supporting 1600 byte ethernet PDUs on their network to allow for tunnel protocol overheads and other overheads. But don’t quote me on that; it was a long time ago and my memory is very fuzzy. Note that users who are on ADSL with old 20CN exchanges and who have two-box setups (ie with a separate modem and router) cannot use 1508 byte PPPoE packets; they are restricted to IP 1492 max.
I use 1508 byte PPP MTU on my Andrews and Arnold ADSL2 lines which are PPPoEoA. I am on 21CN and I use separate modems and router.
-
That's unfortunate; I had presumed Zen and other ISPs on the Openreach backbone would be obliged to support them.
Probably every line is different as I have no issues with baby jumbo on my Zen line... :fingers:
-
@hushcoden - I wouldn’t say every line is different; not at all :) It’s down to the combination of your router and modem, the dslam or exchange and then the ISP or carrier’s network. If you are on 21CN or FTTC then it’s down to your kit, the carrier’s and ISP’s equipment, but beyond that, every line is not just randomly different.
-
I seem to remember vaguely something about BT supporting...
2.1.2 Ethernet Frame Size
The maximum supported Ethernet frame size is 1530 bytes (excluding IFG and pre- amble and single/double tag – see 2.1.3). The maximum supported Ethernet payload size is 1500 bytes.
[Inc FTTC, G.fast, FTTP etc. For services provided to customer ISP equipment Openreach require a minimum of 1522 bytes, with up to 2000 bytes on request.]
-
That's unfortunate; I had presumed Zen and other ISPs on the Openreach backbone would be obliged to support them.
I think there was a temporary glitch that stopped it working on one ISP, both are fine now except one of the changes I made to pfSense or the network itself since has caused a problem. I get huge hangs when trying to browse, and pinging 1500 packets leads to 100% packet loss.
So I've given up as it honestly makes no practical difference using 1492 as most online services aren't expecting the full 1500 packet size anyway. Nintendo even set the Switch to something nuts like 1450 where increasing it to 1492 actually DOES make a slight speed difference.
-
There is still an elegance when frames remain contiguous after their existence as packets, especially if packet handling is the limiting factor or the bandwidth is perishingly small. This is especially true if the additional size is just down to the additional headers provided by ISPs first hop PPP or VLAN tags, ensuring that the resultant packet size is 'back to normal' for subsequent hops. Openreach's baby jumbos at least frees the customer from the ISP-side baggage. But yes, for most 'middle bandwidth' users it just isn't something most users would even know about.
Of course, for those in the UK still stuck on very low bandwidth connections (due sympathy expressed as there are many in my county) then baby jumbos can make quite a difference when latency is of critical concern (eg VOIP). At 1Mbps a single packet takes around 13ms, so letting packets be packets can make all the difference! :fingers:
-
There's an elegance when end-to-end is pure ethernet with no silly PPP encapsulation, and elegance to a zero-jitter latency, it doesn't mean its worth the effort of trying to attain that or realistic to expect it.
-
Indeed and I suspect that those that like to tweak or have reasons to push their connections tend to gravitate to forums such as this. For every one of us there are countless others who have no concept of what their bottleneck is between their mobile wifi device and the wider internet and settle for whatever their ISP's combi-box provides.
Achieving a 'normal' 1500 MTU over PPPoE is desirable to me as I have a noticeable and unfavourable interaction between it and my download QoS when constrained to a smaller MTU, predominantly with IPv4/NAT. Not everyone's need is the same.
-
Even though I have an IPv4 MTU of 1500 bytes achieved through PPPoE 1508 byte baby jumbo frames, we have to remember that as far as IP is concerned these numbers are just arbitrary. Some IPv6 applications, iirc, just stick to 1280 bytes because that is guaranteed to work in the IPv6 standard, and don’t bother with trying to get up to the path MTU. The number 1500 only comes from ethernet, and has nothing to do with IPv4 or IPv6. Having said all that, I wanted a 1500 byte IPv4 MTU for largely illogical reasons, wanted best byte overhead efficiency, and best compatibility with IPv4 applications. For IPv6, for reasons that have been discussed in earlier threads, I use an MTU of 1408 though.
-
Things are getting better with ipv6 in recent times and I don't constrain it now. I also run with scissors.
Frame 98: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface en0, id 0
Internet Protocol Version 6, Src: ######.net (2a04:::###), Dst: 2a02:390:8641:3:cd5a:::#### (2a02:::####)
Payload Length: 1460
Transmission Control Protocol, Src Port: 80, Dst Port: 49285
I didn't read how you got to an MTU of 1408 but it looks like a pretty good number to balance between performance vs avoiding pmtud / icmp pitfalls, so I totally get it.
Cloudflare did a blog on the subject a couple of years ago - for those that may have missed it:
https://blog.cloudflare.com/increasing-ipv6-mtu/
I should probably add that my MTU interaction with QoS is probably down to me using HTB+FQ_Codel. I understand that the later generation (eg CAKE) does not have this hesitation, but I have yet to try.
👍
-
See :
https://forum.kitz.co.uk/index.php/topic,22812.msg387967.html#msg387967
https://forum.kitz.co.uk/index.php/topic,22630.msg385743.html#msg385743
for a very boring story.
MTU 1408 + overhead is a multiple of 48 bytes, so it is an efficient choice, but it’s not my choice because of its efficiency- it’s only chosen because I have to live with reduced MTU.
-
Things are getting better with ipv6 in recent times and I don't constrain it now. I also run with scissors.
I didn't read how you got to an MTU of 1408 but it looks like a pretty good number to balance between performance vs avoiding pmtud / icmp pitfalls, so I totally get it.
Cloudflare did a blog on the subject a couple of years ago - for those that may have missed it:
https://blog.cloudflare.com/increasing-ipv6-mtu/
I should probably add that my MTU interaction with QoS is probably down to me using HTB+FQ_Codel. I understand that the later generation (eg CAKE) does not have this hesitation, but I have yet to try.
👍
they back on 1280 now, there is a more recent blog entry where they discovered 1500 was breaking things, my suggestion for ipv6 is 1280.