Hi RobertoS,

You mentioned your forecast/actual speed:

In reply to a post by RobertoS:

My estimate from the BT Wholesale checker was and is 28.9/6.4Mbps. I get a 40000/10000kbps sync.

I'm scheduled to go live at the end of September and the checker gives exactly the same numbers - 28.9/6.4 - for my line. I'm curious to know your line length, if you have it, to see how it compares; mine (from walking it out, measuring with Google earth and allowing for up/down poles) is ~1650 ft. Obviously other factors such as line quality and crosstalk are important, although I don't know the extent to which the checker can model these.

Thanks,
Dave

...Thank you, kind sir!

I paced it at 500-550 yards. The engineer's JDSU reported approx 0.6 metres. Attenuation 17.7dB, SNRM 7.3dB. So we are very similar, and mine could go slightly faster than it does, if uncapped.

Thanks! Now it's wait-and-see time.

Dave

>>P2P can be hit quite hard, and things can slow down in the evenings.

I have noticed that Infinity punters report that p2p is throttled but I have not noticed punters reporting 'things slowing down in the evenings'

Indeed I have noticed punters of high priced providers reporting slow downs and high pings on 'big news days' including posts to 'live bqm's' that clearly show altcos struggling. Whereas Infinity punters appear to have been unaffected.

Given that Infinity would appear to be outselling altcos in droves. Perhaps you could point out where Infinity is slowing down in the evenings as compared to much higher priced altcos?

Edited by deleted (Tue 16-Aug-11 20:48:46)

In reply to a post by RobertoS:

I paced it at 500-550 yards. The engineer's JDSU reported approx 0.6 metres. Attenuation 17.7dB, SNRM 7.3dB. So we are very similar, and mine could go slightly faster than it does, if uncapped.

I measured mine to 550 metres, and the engineer reported 600-650 metres. Pretty much identical attenuation and SNRM figures.

My predicted speeds were around 31/6.1, and I'm getting approx 36/10 (although I got 40/10 at first, but with 4% packet loss). I'm pretty sure there's something fixable for that downstream speed, but nothings happened yet...

In reply to a post by RandomJointer:

Perhaps you could point out where Infinity is slowing down in the evenings as compared to much higher priced altcos?

Afaik Infinity doesn't slow down much in the evenings, as you say it only seems to affect those independent ISPs who are selling the BT product.

Odd, that.

Edited by billford (Wed 17-Aug-11 00:25:30)

I've never noticed any substantial slow down at any time. Obviously it can vary by a few megabits from time to time but there is no set period like "in the evenings".

The only thing I've found to be throttled in any fashion in Bit Torrent and even then it's not a blanket slowdown.

Mine is also about 600m.

From memory the JDSU had 27dB attenuation. Speed is about 23Mbit here.

TalkTalk are unlikely to resort to placing manual orders on Openreach's systems. Any company with ~4 million customer accounts / records to maintain and accurately bill is going to be fairly inflexible with regard to processing anything outside the "normal" provisioning flows from entry point (sales portals used by yourself or their staff if you call to order), to CRM, to supplier mediation platform to supplier.

Allowing staff to manually place orders directly on supplier systems as they see fit would at the very least be foolish. IME - It's those kind of ad-hoc processes that result in over-billing, inability to provide exit (MAC code production fails for example) and billing after leaving issues at some future date.

The entry protocol on ordering that may seem inflexible and possibly not quite up to date with supplier information perhaps at times from the outside, is actually a very sane approach when taken in an end to end customer lifecycle view.

With regulators quick to go for SP's jugular wrt MAC adherence and other customer exit protocols (rightly so!) it is only sensible for companies of this size to make sure their customer data is clean and "un-fudged" from the moment it is entered - rather than frigging through an order manually on some backend system with the very real risk that other upstream systems will never be brought up to date with pertinent data that they rely on.

Frustrating in some instances for sure, but it is an approach for the greater good overall.