Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jelv]

Pro add-on will at best only have the effect of making you £5 poorer per month - and we have seen cases where it made speeds worse.

[jelv]

Watch out for a problem with Max Premium where when the phone rings for an incoming call you get huge numbers of errors in the upstream and probably disconnections. If you see that post back and I'll give you the full information you need.

Has Max Premium actually been added to your line? It normally takes Plusnet ages to pick up the tickets requesting it and then it's an overnight order to activate it.

[huwwatkins]

To my immense surprise they picked up the ticket within a couple of hours! (but still havn't responded to my fault ticket 72 hours ago...)

Should go live tomorrow.

The Pro-Addon is different to the ADSL Max Premium addon - they are two separate things and it confused me. I had to check with their online chat before I was pointed to this website to get it:

http://trials.plus.net/

I'm aware of the phone dropping issue with Marconi DSLAMS. Does this still cause an issue even if there is no phone connected?


Hmmm, latency on the up again...

ply from 212.58.244.22: bytes=32 time=350ms TTL=53
Reply from 212.58.244.22: bytes=32 time=483ms TTL=53
Reply from 212.58.244.22: bytes=32 time=598ms TTL=53
Reply from 212.58.244.22: bytes=32 time=546ms TTL=53
Reply from 212.58.244.22: bytes=32 time=241ms TTL=53
Reply from 212.58.244.22: bytes=32 time=355ms TTL=53
Reply from 212.58.244.22: bytes=32 time=430ms TTL=53
Reply from 212.58.244.22: bytes=32 time=595ms TTL=53
Reply from 212.58.244.22: bytes=32 time=503ms TTL=53
Reply from 212.58.244.22: bytes=32 time=580ms TTL=53
Reply from 212.58.244.22: bytes=32 time=695ms TTL=53
Reply from 212.58.244.22: bytes=32 time=817ms TTL=53
Reply from 212.58.244.22: bytes=32 time=765ms TTL=53
Reply from 212.58.244.22: bytes=32 time=500ms TTL=53
Reply from 212.58.244.22: bytes=32 time=381ms TTL=53
Reply from 212.58.244.22: bytes=32 time=484ms TTL=53
Reply from 212.58.244.22: bytes=32 time=593ms TTL=53
Reply from 212.58.244.22: bytes=32 time=789ms TTL=53
Reply from 212.58.244.22: bytes=32 time=686ms TTL=53
Reply from 212.58.244.22: bytes=32 time=643ms TTL=53
Reply from 212.58.244.22: bytes=32 time=401ms TTL=53
Reply from 212.58.244.22: bytes=32 time=418ms TTL=53
Reply from 212.58.244.22: bytes=32 time=458ms TTL=53
Reply from 212.58.244.22: bytes=32 time=568ms TTL=53
Reply from 212.58.244.22: bytes=32 time=437ms TTL=53
Reply from 212.58.244.22: bytes=32 time=496ms TTL=53

Also looks like im seeing packet loss:

http://www.thinkbroadband.com/ping/share/13bdb63984379952057e95cd65196a86-08-12-2016.html

[jelv]

Ah, you've heard of the issue before. Yes the Marconi issue does cause problems without a phone plugged in. In fact one of the engineers went back to the exchange and connected to my line in there with his test equipment and saw loads of errors when the phone rang.

You can tell if you are on Marconi because if you look at the bit loading there's a bigger than normal gap between upstream and downstream - if I remember correctly tones 33-36 are not used.

Edit: Found the old topic on community: https://community.plus.net/t5/Broadband/Sync-drops-when-phone-rings-subject-was-quot-Is-this-a-record/td-p/974668

Here's a graph from it:

[Ronski]

That is on 21CN exchanges so totally irrelevant here!

So sorry, didn't know that!!! 

[Chrysalis]

these latency figures for when the line is in use is expected, the smaller the capacity of the line, the more latency is affected when utilised.

[huwwatkins]

I think it must be.

Pro addon enabled. It doesn't seem to have made much difference....

Here is latency whilst streaming a 480p yourtube video:

Reply from 212.58.244.22: bytes=32 time=229ms TTL=53
Reply from 212.58.244.22: bytes=32 time=239ms TTL=53
Reply from 212.58.244.22: bytes=32 time=202ms TTL=53
Reply from 212.58.244.22: bytes=32 time=237ms TTL=53
Reply from 212.58.244.22: bytes=32 time=144ms TTL=53
Reply from 212.58.244.22: bytes=32 time=200ms TTL=53
Reply from 212.58.244.22: bytes=32 time=224ms TTL=53
Reply from 212.58.244.22: bytes=32 time=208ms TTL=53
Reply from 212.58.244.22: bytes=32 time=231ms TTL=53
Reply from 212.58.244.22: bytes=32 time=207ms TTL=53
Reply from 212.58.244.22: bytes=32 time=215ms TTL=53
Reply from 212.58.244.22: bytes=32 time=224ms TTL=53
Reply from 212.58.244.22: bytes=32 time=206ms TTL=53
Reply from 212.58.244.22: bytes=32 time=202ms TTL=53
Reply from 212.58.244.22: bytes=32 time=180ms TTL=53
Reply from 212.58.244.22: bytes=32 time=195ms TTL=53
Reply from 212.58.244.22: bytes=32 time=209ms TTL=53
Reply from 212.58.244.22: bytes=32 time=214ms TTL=53
Reply from 212.58.244.22: bytes=32 time=220ms TTL=53
Reply from 212.58.244.22: bytes=32 time=199ms TTL=53
Reply from 212.58.244.22: bytes=32 time=223ms TTL=53
Reply from 212.58.244.22: bytes=32 time=12ms TTL=53
Reply from 212.58.244.22: bytes=32 time=12ms TTL=53
Reply from 212.58.244.22: bytes=32 time=12ms TTL=53
Reply from 212.58.244.22: bytes=32 time=13ms TTL=53
Reply from 212.58.244.22: bytes=32 time=12ms TTL=53

I think maybe my expectations are too high!

I noticed though when it was buffering the video it was maxing out the line. I'm guessing I could set QoS to prevent this.

[aesmith]

Pings while streaming Youtube @720p ..

64 bytes from 90.155.53.94: icmp_seq=84 ttl=61 time=61.064 ms
64 bytes from 90.155.53.94: icmp_seq=85 ttl=61 time=50.102 ms
64 bytes from 90.155.53.94: icmp_seq=86 ttl=61 time=91.869 ms
64 bytes from 90.155.53.94: icmp_seq=87 ttl=61 time=77.810 ms
64 bytes from 90.155.53.94: icmp_seq=88 ttl=61 time=85.579 ms
64 bytes from 90.155.53.94: icmp_seq=89 ttl=61 time=64.189 ms
64 bytes from 90.155.53.94: icmp_seq=90 ttl=61 time=48.816 ms
64 bytes from 90.155.53.94: icmp_seq=91 ttl=61 time=44.635 ms
64 bytes from 90.155.53.94: icmp_seq=92 ttl=61 time=63.915 ms
64 bytes from 90.155.53.94: icmp_seq=93 ttl=61 time=177.362 ms
64 bytes from 90.155.53.94: icmp_seq=94 ttl=61 time=66.239 ms
64 bytes from 90.155.53.94: icmp_seq=95 ttl=61 time=55.153 ms
64 bytes from 90.155.53.94: icmp_seq=96 ttl=61 time=117.981 ms
64 bytes from 90.155.53.94: icmp_seq=97 ttl=61 time=102.243 ms
64 bytes from 90.155.53.94: icmp_seq=98 ttl=61 time=75.543 ms
64 bytes from 90.155.53.94: icmp_seq=99 ttl=61 time=77.129 ms
64 bytes from 90.155.53.94: icmp_seq=100 ttl=61 time=46.760 ms
64 bytes from 90.155.53.94: icmp_seq=101 ttl=61 time=64.437 ms
64 bytes from 90.155.53.94: icmp_seq=102 ttl=61 time=88.673 ms
^C
--- time.aa.net.uk ping statistics ---
103 packets transmitted, 103 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 42.644/64.328/190.702/30.191 ms

[kitzuser87430]

QoS to prevent this

Yes set line speed to 70-80% of throughput my upload is set at 360 kbps upload (sync 448) and 5000 kbps download (6848 sync)

If I am downloading an iso or something similar and in a rush i sometimes disable QOS  for a bit of a speed increase.
 

[aesmith]

If your kit is capable of it, prioritising small packets in the upload direction can be completely effective in combating latency due to heavy upload traffic.  Of course it won't necessarily address the Plusnet specific issue of sometime going to ratshit under moderate upload.

[huwwatkins]

Well, its saturday afternoon. I have Qos turned on prioritising small packets and limiting upload and download speeds to less than my line rate and its not looking great.

As you can see from the screenshot there isn't a huge amount going on on my connection and my ping is all over the place. I also have the 832k upload now.

[Chrysalis]

832kbit is still not much bandwidth, but you have to set the actual upload limit on asus QoS enough to be effective so there is a buffer of unused bandwidth.

Also use codel if its available on your asus firmware.

[huwwatkins]

Hi
Yup, I've set the upload at 0.6Mbps. What is codel? I've not heard of that before.

On the graph the latest data is on the right. Virtually nothing happening on the connection.

Thanks

Huw

[ejs]

This may sound silly, but what are you actually trying to achieve?

Does the ping time when you're not doing anything with the connection actually matter?

Or to put it another way, ping results might be useful to investigate some other issue, but I wouldn't keep looking for things to fix just for the sake of having nice looking ping results.

[aesmith]

Might be worth installing PRTG if your router supports SNMP, get proper statistics directly from the PPPoA interface.

Just looking at your figures, my RTT doesn't vary that much, although the baseline is higher.  For example RTT and traffic from midnight to 06:00 ..

Edit - on the ping graph I've selected only Max, meaning each point is the maximum from a batch of 5 pings at the time shown.