sbiddle: The challenge for Chorus / LFC's and ISP's is actually engineering the CIR - in effect allocating 2.5Mbps of guaranteed traffic to users when this bandwidth will sit dormant for most of the time.

Apart from the odd issue EUBA has worked relatively well with no per user dimensioning.

It doesn't matter because probably no one is going to use the voip port on the ONT nor the CIR tagged traffic for consumer plans.

Pretty much every ISP is just using EUBA0, not bothering with vlan tagging and just sending voip over the best effort internet bandwidth then doing some QoS/management/engineering of traffic inside the ISP network to smooth things out.

This is probably going to continue for UFB

Having CIR's for special tagged traffic on the consumer bitstream offerings seem like a retarded waste of time to me.

Business plans sure.

maybe they should make regualr http traffic have the 2.5Mb/s cir, so that the guy down the road with the dedicated torrent machine doesn't slow down the tech savvyy grandma who likes to browse trademe quickly?

2.5megabit/sec isn't quick.

still better than nothing i guess, why even have it then, what's the point?

Non CIR traffic is treated "fairly" so someone leaching won't get "all teh bandwidths". If saturation is reached in any part of the network, packets will be queued and/or discarded at random from all connections.

Also, the network is provisioned so there is "at least" the CIR available per connection, and it's very unlikely that tagged traffic will ever saturate that.

You can't simply prioritise "all traffic" - it defeats the whole purpose. And defining more levels (ie. AFxx for HTTP traffic) would just add a lot of complexity for IMO little benefit.

freitasm: I mean someone told me there's a suspicion why some UFB connections are not performing as well as intended. Apparently not all ISPs are aware and some are investigating. Let's see what they find.

I've just caught something nasty on EUBA and I'm proceeding to investigate UFB with the same idea in mind. Surprising. I'm actually an advocate for Chorus' network normally, as overall I've seen very good performance in recent years (really since the 7302 upgrade/Ethernet backhaul project).

“I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success... Such emotions make a man forget food, sleep, friends, love, everything.” - Nikola Tesla

Disclaimer: Views expressed in my posts do not necessarily reflect those views of my employer.

Let me know the speed this downloads, both single-threaded and multi-threaded.

Can you also please PM me your username, so I can set up a graph of latency to you, also to track packet loss.

Thanks,Tim

“I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success... Such emotions make a man forget food, sleep, friends, love, everything.” - Nikola Tesla

Disclaimer: Views expressed in my posts do not necessarily reflect those views of my employer.

That speedtest.net result is possibly inaccurate. Snap seem to have started caching HTTP, including speedtest.net, so you can no longer use it to test international speeds. :( See here: http://www.geekzone.co.nz/forums.asp?forumid=90&topicid=111499

Lorenceo: That speedtest.net result is possibly inaccurate. Snap seem to have started caching HTTP, including speedtest.net, so you can no longer use it to test international speeds. :( See here: http://www.geekzone.co.nz/forums.asp?forumid=90&topicid=111499

speedtest.net uses unique requests for each "random image" that it uses to download, and so even if things force-cache the content, it'll just take up lots of cache space.

so you'll have a request like:

http://speed.snap.net.nz/speedtest/random1500x1500.jpg?

then a random number after the ? .. you can request the image yourself and see it just looks like random pixels.

but with the http download, you should be able to accomplish the same thing with that 100mb speed test in fremont (california) by appending ?129321039812903812 or some other random number to it, and increment it every time you do a new test.

I'd still really love somebody who's experiencing slow speeds and has the technical knowledge to run some tests using the high priority CIR on their connection rather than just their EIR.

I'm just curious if the connection is actually meeting the specs for the UFB product which is only around the CIR, not the EIR which at the end of the day is all best effort traffic and congestion could be occuring at many points along the way.

mercutio: speedtest.net uses unique requests for each "random image" that it uses to download, and so even if things force-cache the content, it'll just take up lots of cache space.

so you'll have a request like:

http://speed.snap.net.nz/speedtest/random1500x1500.jpg?

then a random number after the ? .. you can request the image yourself and see it just looks like random pixels.

but with the http download, you should be able to accomplish the same thing with that 100mb speed test in fremont (california) by appending ?129321039812903812 or some other random number to it, and increment it every time you do a new test.

I just tried this, with a bunch of different number strings. The MD5 of the files that it downloads are the same, and they all came in at line speed. Even when supposedly coming from Africa.