ForumAdmin wrote:austdata wrote:James wrote:Just curious, how much do you download in off peak?
G'day James,
Somewhere between 2 and 6 Gigabytes a month. I'm more than happy with the quota, it's terrific.
My problem is (usually) the speed after midnight. Of course, as I type this, the speed is looking great.
It's the same when I go to the dentist, the tooth is killing me when I make the appointment but when I get there it feels fine.
Cheers,
Mike
Like your experience when you made yourrecent post - every time I loook at the graphs after a post like yours I see no congestion anywhere.
Exetel adds bandwidth every month and we constantly watch the impact of adding new users.
The new load balancing (between Verizon and Optus) script written by an Exetel network engineer has added even more 'sensitivity' to the shifting of address blocks to ensure there is no congestion on either link and this is now done at 5 minute intervals 24x7.
We will commence installing the new P2P caching engine and raid arrays next week with the expectation that by the end of November that additional service will be operating in full trial mode.
If the P2P caching solution delivers the expected 300 mbps+ of additional direct 'bandwidth' then there will be over 2 gbps of bandwidth available for around 50,000 DSL users which is well over what the Telstra and Optus backhaul networks are planned to be provisioned at (30 mbps for Optus and some unknown number for Telstra but likely to be around the same as Optus; perhaps higher - no-one knows)
We see no congestion on any link we have deployed though there is, very clearly, backhaul congestion to/from many Optus ADSL2 exchanges that vary in time and location. There were also congestion problems on a number of telstra exchanges in the December 2006 - early March 2007 period.
Before getting too hot under the collar about carrier backhaul provisioning it must be remembered that networks around the world are feeling the strains imposed by the significant additional loads that new applications have brought to internet traffic.
If you were an early customer of BigPond (on the "massively fast" 512/128) service some 5-6 years ago you would remember just how slow (and how unreliable) that service was in the early stages.
It happens.
Don't hold me to gold on this, but how do you claim no congestion, when I look at the RRD graphs, I can see clearly they hit the peak for a sustained length of time in certain times.
You can see this clearly on the graphs, the links run at peak capacity at times. There's still more work on shifting that peak load, or trying to stop the links running at maximum capacity (they have and do run at 100% at TIMES).
An example, just so it doesn't appear to you that I am out to attack, but rather, highlight that the links do find themselves at 100% (congestion levels): Weekly graph, Tuesday AM, you can see that the green line has a FLAT on top of it, indicating sustained, flatline near 600Mbps access.
Everyone should know you won't actually reach that 600Mbps, due to overheads, etc, but the link does run at 100% capacity.
I'll tell everyone now so this doesn't look bad for Exetel, adding more capacity to those links, will only see them run at 100%, but at a higher speed usage, and therefore a higher cost base for Exetel.
The solution is there, in caching the higher bandwidth content. That would be P2P for many, and much would be repeat accessed content.
I'd be keen to review the link activity after the caching system is in. It'll be so exciting to see the drop off in high peak activity, and I trust Exetel will leave the links as is, so that the links simply run at a lower percentage (80% or less) for the time to allow for growth in usage.
The yearly graph (which has a great monthly guage) suggests they aren't at 100% all the time (due to the peaks, and drops), but look at the outgoing in September.
Exetel did something to reduce a large amount of upload traffic? Or was it something else that sparked a drop in outgoing traffic?
Actually, even better showing of 100% capacity, Verizon 750Mbps running past that.