Network Capacity hit by minority of users
Thank you Barry,
Correct me if I am wrong - and I am sure you or someone else will
- but I thought that traffic balancing between segments of a central pipe was automatic so the capacity limit was by central pipe not segment which gives more latitude.
Notwithstanding that 5 centrals starting getting significant gold packet loss mid afternoon yesterday. My point is really that the apparent headroom for gold traffic must be much less than 950/5 = 190Mbps or put it another way it would appear that gold traffic on the affected centrals jumped by about 20% (making some alliowance for the centrals which didn't overload).
The part I would like a bit of guidance on is the proportion of the bandwidth allocated to gold traffic (I thought it was less than 50%) and why the dynamic controls didn't jump in to allocate a higher proportion to gold.
Correct me if I am wrong - and I am sure you or someone else will
- but I thought that traffic balancing between segments of a central pipe was automatic so the capacity limit was by central pipe not segment which gives more latitude. Notwithstanding that 5 centrals starting getting significant gold packet loss mid afternoon yesterday. My point is really that the apparent headroom for gold traffic must be much less than 950/5 = 190Mbps or put it another way it would appear that gold traffic on the affected centrals jumped by about 20% (making some alliowance for the centrals which didn't overload).
The part I would like a bit of guidance on is the proportion of the bandwidth allocated to gold traffic (I thought it was less than 50%) and why the dynamic controls didn't jump in to allocate a higher proportion to gold.
Actually, it gets more complicated than that 
Each 622Mbps pipe is split into 4 segments and each segment into 3 LTSs (L2TP Tunnel Switches) so there are 12 LTSs in total, per central. Depending on the load on each LTS you could have 2 customers on the same gateway but different LTSs seeing very different performance. I *believe* traffic will balance across same-segment LTS, but not cross segment (and definately not cross-central)
As I understand it, the way that the traffic management works is that titanium gets all the bandwidth it needs then x% goes to gold, y% to silver, etc. and that's done on a per LTS basis rather than per gateway.
The queue weightings for Gold, Silver, Bronze/Best-Effort etc. are assigned a minimum value. This minimum value represents the lowest possible bandwidth allocation to be assigned to that queue at any particular time. Think of it as the lowest it can get squeezed to. The way it would generally work is:
- Network becomes busy
- Bronze/Best effort squeezed to lowest weighting, if more capacity required then ..
- Silver traffic squeezed to lowest weighting, if more capacity required then ..
- Gold traffic squeezed to lowest weighting
The Titanium queue always takes precedence over the others and I think it works in a slightly different way. AFAIK it's the only queue that could theoretically squeeze the others below their minimum weightings.
However, if I could wake Tommo up, I suspect he could answer with a greater degree of accuracy
B.
Each 622Mbps pipe is split into 4 segments and each segment into 3 LTSs (L2TP Tunnel Switches) so there are 12 LTSs in total, per central. Depending on the load on each LTS you could have 2 customers on the same gateway but different LTSs seeing very different performance. I *believe* traffic will balance across same-segment LTS, but not cross segment (and definately not cross-central)
As I understand it, the way that the traffic management works is that titanium gets all the bandwidth it needs then x% goes to gold, y% to silver, etc. and that's done on a per LTS basis rather than per gateway.
The queue weightings for Gold, Silver, Bronze/Best-Effort etc. are assigned a minimum value. This minimum value represents the lowest possible bandwidth allocation to be assigned to that queue at any particular time. Think of it as the lowest it can get squeezed to. The way it would generally work is:
- Network becomes busy
- Bronze/Best effort squeezed to lowest weighting, if more capacity required then ..
- Silver traffic squeezed to lowest weighting, if more capacity required then ..
- Gold traffic squeezed to lowest weighting
The Titanium queue always takes precedence over the others and I think it works in a slightly different way. AFAIK it's the only queue that could theoretically squeeze the others below their minimum weightings.
However, if I could wake Tommo up, I suspect he could answer with a greater degree of accuracy
B.
Quote Shows what a shocking waste of bandwidth transmitting TV over the web is
I'm afraid I have to side with this. The network configuration of the interweb is not well suited to mass distribution activities. Every time there's a "big thing" (sporting events, news events, patches released, aliens discovered, etc.) there's a problem. Since the material is already freely available via a TV aerial, which 99.9% of the population already have, I really cannot see the point of TV over the internet.
[quote=Barry Zubel]I personally use the iPlayer because it allows me to timeshift very conveniently
I have a PVR. Does the same thing except is easier to use, plays on my normal living room TV rather than hunching round a pokey computer monitor, has full res images (OK - not very good res on some Freeview, I'll admit!), and doesn't eat up all my broadband quota...
Quote from: Barry
However, if I could wake Tommo up, I suspect he could answer with a greater degree of accuracy
B.
Near enough, although the ERX side is done per pipe rather than per LTS, so the queue weighting applies to the whole pipe not each individual LTS, but because there's room for each LTS to flex against each other it doesn't really make much difference, although with less segments lit there's less room for the flexing on each pipe. Of course the dropped traffic applies on a per LTS basis rather than the whole pipe...
