cancel
Showing results for 
Search instead for 
Did you mean: 

Why is it 88.2% re IP speed vs sync speed?

AndyH
Grafter
Posts: 6,824
Thanks: 1
Registered: ‎27-10-2012

Re: Why is it 88.2% re IP speed vs sync speed?

I'm synced at 100Mbps, my IP Profile is 96.54 Mbps and my Current Line Speed is 300 Mb. Around 95Mbps is the max I see on multi-threaded speed tests and 1-2Mbps lower on single threaded.
lf2k
Grafter
Posts: 46
Registered: ‎12-05-2015

Re: Why is it 88.2% re IP speed vs sync speed?

@Andy: what's your latency when pinging 8.8.8.8?
I'm guessing you're on FTTP, so no copper and no CRCs/G.INP/Interleaving?
AndyH
Grafter
Posts: 6,824
Thanks: 1
Registered: ‎27-10-2012

Re: Why is it 88.2% re IP speed vs sync speed?

Quote from: lf2k
what's your latency when pinging 8.8.8.8?

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.385/4.578/4.764/0.126 ms
Yeah FTTP, so no interleaving/CRCs/G.INP/copper.
I've read that PPPoE at higher speeds is very CPU intensive so you need a decent, up-to-date router.
lf2k
Grafter
Posts: 46
Registered: ‎12-05-2015

Re: Why is it 88.2% re IP speed vs sync speed?

4ms?!  Shocked  Do you live in Telehouse/Linx or something?!  Grin
That's very respectable (OK, I'm officially jealous!), but roughly where are you (guess South East near London)?
Three questions then:

  • Do you mind the 1-2Mbps you lose off your downstream because of the QoS?

  • What router are you using, since I'm guessing you're also using PPPoE despite being on FTTP?

  • Assuming you're on plusnet (since you're commenting on a QoS thread), which package are you on?

Soz for being nosey...  Grin
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: Why is it 88.2% re IP speed vs sync speed?

If AndyH's Plusnet current line speed was 300, higher than their BT IP Profile, then Plusnet's traffic management would not be the limiting factor on the speed. I don't know if any speedtesters include bytes used by the TCP and IP headers when calculating the speed, I doubt they do. Without being limited by the Plusnet profile, if you measure the speed accurately and include the TCP and IP headers, then the speed should be very close to the BT IP profile.
AndyH
Grafter
Posts: 6,824
Thanks: 1
Registered: ‎27-10-2012

Re: Why is it 88.2% re IP speed vs sync speed?

    Quote from: lf2k
    4ms?!  Shocked  Do you live in Telehouse/Linx or something?!  Grin
    That's very respectable (OK, I'm officially jealous!), but roughly where are you (guess South East near London)?

    Milton Keynes - my exchange is also a core node (Bradwell Abbey), which probably also has some baring on things.
    Quote from: lf2k
    • Do you mind the 1-2Mbps you lose off your downstream because of the QoS?

    • What router are you using, since I'm guessing you're also using PPPoE despite being on FTTP?

    • Assuming you're on plusnet (since you're commenting on a QoS thread), which package are you on?


    - I don't mind or notice at all.
    - Asus DSL-N66U with the Openreach supplied Huawei ONT (HG8240), but will upgrade the router in the not too distant future.
    - I'm on fibre unlimited. There are quite a few of us on the FTTP "trial".
lf2k
Grafter
Posts: 46
Registered: ‎12-05-2015

Re: Why is it 88.2% re IP speed vs sync speed?

I believe that the profile is set by BT, but the fibre is provisioned at 300Mbps - similar to how your line might be capable of 80/20, but BT profile it down to fit with a 40/10 product.
That said, Plusnet are a bit different; they always provision 80/20 then shape it down to 40 down (if that's what you're paying for).
I'd be a very happy bunny if I could buy a link like Andy's... (Sadly, not available in my part of Norfolk)
legume
Rising Star
Posts: 179
Thanks: 12
Registered: ‎21-07-2013

Re: Why is it 88.2% re IP speed vs sync speed?

Quote from: AndyH
The frame sized used by the ISP makes a difference also:

I don't think frame size is an ISP thing - the variation of throughput for smaller packets is just revealing the fixed part of the per packet overhead.
AndyH
Grafter
Posts: 6,824
Thanks: 1
Registered: ‎27-10-2012

Re: Why is it 88.2% re IP speed vs sync speed?

This is what it says in the BTw handbook:
Quote
The downstream rate achieved on the service will include a small element of bandwidth used to support traffic management. The bandwidth utilised for traffic management will vary according to the frame size used by the CP for transmitting IP packets.

legume
Rising Star
Posts: 179
Thanks: 12
Registered: ‎21-07-2013

Re: Why is it 88.2% re IP speed vs sync speed?

Fair enough - I haven't seen the BTW handbook only read the SIN, which does also give differing throughputs for different frame sizes - of course in the SIN case they are talking about frame size that is determined by what size packets the users connection is using eg. if I set my mtu/mss low then there will be more % fixed overhead. I guess the QOS thing you quote could be something entirely different, although IIRC the SIN was also talking about accounting for different frame sizes WRT QOS in the sense of ISPs not sending too much for the link speed.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: Why is it 88.2% re IP speed vs sync speed?

Yes that's what the handbook says. So what does it mean? The byte(s) used to store the priority markings in the VLAN tags would be a fixed sized overhead on each frame. As a percentage of the total bandwidth, the overheads would be higher for smaller packets.
The WBC FTTC handbook is publicly available, probably by accident.
legume
Rising Star
Posts: 179
Thanks: 12
Registered: ‎21-07-2013

Re: Why is it 88.2% re IP speed vs sync speed?

Thanks for the link. As to what it means - Hmm, it could be just a confusingly worded way to say that there is a BRAS rate with "traffic management" in the sense of not sending more across the BTW network than the link can actually handle. The link by its nature having less throughput for smaller frame sizes.
"the frame size used by the CP for transmitting IP packets" may not mean there is a setting somewhere that the ISP uses - it could just be a confusing way of saying it depends on frame size - it seems strange to show as low as 64 bytes if it is a setting. Saying that though the figures/rates given seem hard to reconcile with those in SIN 498 and I notice that the BTW doc says IP frame size and goes up to 1522 - it may really be possible, but it's a coincidence that 1522 is the "user side" ethernet frame size of pppoe + mini jumbos, which I use, so I know they work.
I know the doc mentions "proper" QOS elsewhere - but that could be a different (chargeable like it was on ADSL?) thing.
As always I don't know the real situation - just speculating.
AndyH
Grafter
Posts: 6,824
Thanks: 1
Registered: ‎27-10-2012

Re: Why is it 88.2% re IP speed vs sync speed?

I think the QoS markings are the standard vs elevated traffic preference at the BRAS. But there are also QoS tags on the OR side:
Quote
GEA-FTTC is delivered on a single Virtual Local Area Network (VLAN), via a 1Gbit/s connection from a Layer 2 Ethernet switch at the Point of Handover (PoH), through a DSLAM located near the local cabinet, to your end customer’s premises. 
All traffic on the GEA Cablelink will be presented using single tagging or double tagging on a per VLAN basis. Both options can be used on the same GEA Cablelink on a per GEA order basis. The tagging option to use for a specific GEA order is explicitly selected by you when ordering GEA.
The VLAN used for your customers (End User) traffic is referred to as a “CVLAN”. You may optionally choose to use an additional level of tagging so that CVLANs can be grouped within another VLAN, referred to as an “SVLAN”
Single Tagged Handover - The Outer VLAN is the CVLAN.
Double Tagged Handover - The Outer VLAN is the SVLAN, and the Inner VLAN is the CVLAN
3.3 Traffic shaping
Downstream
You should shape traffic on your handover equipment to ensure that it doesn’t exceed the capacity of the product. You can do this using priority markings at the handover port. The following markings are available:
• 802.1p = 3, 2, 1 – should not drop
• 802.1p = 0 – can drop
Please note that:
• Unmarked traffic will be treated as can drop
• Values 4, 5, 6 & 7 are unsupported and would be remarked to 3. This will ensure that congested traffic is discarded based on its marking
• Markings are also used to schedule traffic from the Digital Subscriber Line Access Multiplexer (DSLAM) to the Network Terminating Equipment (NTE).
Upstream
Upstream traffic ignores any .1p markings. Where an SVLAN exists, we police the link up to product capacity. There’s no buffering of packets. Where no SVLAN exists, we shape the traffic up to product capacity. Once again, there’s no buffering of packets.