Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Kymmy its when a high amount of data packets are being buffered on a network, it causes high jitter and latency when a network can't decide if it should buffer the packets of data or not :P

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Not being condescending here, but google it:

http://www.google.co.uk/search?q=bufferbloat

Some very good descriptions and resources there. VM uses excessively high (bloated) buffers which causes excessively high latency and jitter (your graph) when your connection is under load. I can't explain it better than Wikipedia already does, so quoting el wiki:

"Normal" connections with "normal" buffers don't do this. The excessive buffering VM uses degrades your service and everyone else's, while being a pain in the proverbial basckside for network administrators. Whereas heavy downloading like you mentioned should only increase latency by 20-40ms, on VM it increases by well over 100ms and anywhere up to 1500ms in bad cases.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

I didn't think you were being condescending.. I've been out of IT properly now for 8 years and had never heard the term so was just wondering it's implication here :D

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

example of buffer bloat?

http://www.pingtest.net/result/57681817.png

https://www.cableforum.co.uk/images/...2012/02/13.png

my connection was idle during both tests ack at the speed, but the port is obviously highly utilised and as such I assume its buffer is been maxed out.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

https://www.cableforum.co.uk/images/...2012/02/12.png

Superhub XXL

https://www.cableforum.co.uk/images/...2012/07/31.png

30meg vmng

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Tbh people make alot of hot air about buffer bloat.. The reason for VM's jitter/pings relates to the operation of DOCSIS and the fact they don't utilize any QOS for your upstream..

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

But surely if they applied QoS to the upstream, jitter would still exist for demoted upstream calls.

And that assuming that QoS applications themselves in a locality don't get congested among themselves.

Also, what is the operation of DOCSIS that causes jitter? Would be interesting to know.

]---------- Post added at 00:34 ---------- Previous post was at 00:29 ----------

http://www.thinkbroadband.com/ping/s...26-02-2012.png

http://www.thinkbroadband.com/ping/s...26-02-2012.png

Mind you, the boy got some good MW3 in on VM this evening; didn't have to switch to BT Infinity.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

I am officially stealing your Infinity conn Seph :P

(still can't get that in my area yet)

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Apart from a couple of glitch days a couple of weeks ago (I posted the TBB somewhere) the Infinity chart has been like this for 15 months now.

Cheers

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Except that the 1500ms upstream buffer is on the local side and NOT on the DOCSIS side of the connection.

---------- Post added at 04:12 ---------- Previous post was at 04:08 ----------

S'pose I might as well post my live TB graph now that I've got a router connected to it...

https://www.cableforum.co.uk/images/...2012/02/11.png

P.S. Seph, when's the last time you rebooted your Infinity router? Your ping's higher than mine despite being 300 miles closer to London than I am. I've noticed differences of up to 5ms between reconnects depending on which BT central my PPPoE session gets connected to.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Isn't it a fact of life that TDMA upstream always leads to some jitter - especially when run as hot as VM do theirs.

Look at any TBB graph you like - if there's significant jitter then the odds are it's cable. If there is negligible jitter then it's xDSL.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

QOS can only do so much. ultimately if someone is trying to eg. shove 80mbit of bandwidth up a 18mbit pipe then things are going to get messy.

Docsis has all the timeslot issues and such but things like varying pings will always be more evident on smaller shared pipes. I expect VM have to use large buffers to maximise throughput in congested areas, the alternative I suspect would be significant packet loss.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

All strategies have something analogous at least to upstream timeslots. On an uncongested upstream, you get the opportunity to inject your data; on a congested upstream, less opportunity. It's the frequency plan of the upstream and how many channels are provided under any system that matter. AFAIK, Infinity's upstream/downstream frequencies all lie in the same "band" (for want of a better term).

Also I don't think that large buffers maximises throughput except in a locality. A limiting resource somewhere else has the same effect on total round trip as at the point of buffering.

Then to address qasi's comment; TDMA is not confined to DOCSIS. So I'd still like to know what it is about DOCSIS that causes jitter.

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

Re: Think Broadband Ping Monitor Results (POST YOURS)
 

I don't think my point was addressed at you - but in any case, it's the CSMA nature of DOCSIS TDMA that makes it jitter. A modem wanting to transmit upstream data must request a timeslot. To do so it first checks if any other modem is transmitting on the channel, and if so, it aborts the request and then waits a random amount of time before trying again. Modems also don't get allocated fixed timeslots but timeslots are allocated on-demand and in a seemingly random manner, so in a loaded network the time from one slot to the next can be vastly different.

xDSL and 3G both don't use TDMA let alone CSMA hence jitter is lower in both cases. In both these cases a modem wanting to transmit simply transmits immediately, and can do so at any time. It doesn't have to wait, request a timeslot, then wait again until that timeslot is granted. GSM (2G) telephony also sees next to zero jitter as each call is given a fixed, dedicated timeslot. Only the initial call setup uses CSMA, whereas on VM cable (I say that as it's not an absolute requirement of DOCSIS - only that VM haven't implemented the alternative) CSMA is used for just about single upload request.

GPON (i.e. BT Infinity FTTP) I don't know enough about but I believe it operates on a similar timeslotting arrangement to cable, hence why I've said in the past it brings several of the same disadvantages as cable. I've not seen enough actual numbers from PON tech to make any kind of judgement on it though.

That's jitter. Latency on the other hand is a different matter. Excessive latency is simply a result of excessively long buffers, which aren't required as part of DOCSIS. VM simply chooses to stick excessively long buffers in place. It helps the performance of only those using excessively high amounts of bandwidth and degrades the performance of everyone else. It's completely unneccessary.