[ NNSquad ] Re: BT [UK] calls for action on net speeds

[Lauren Weinstein <lauren@vortex.com>]

One of the facets of my original GIMAA concept 
( http://lauren.vortex.com/archive/000303.html ) and carried over here
to the NNSquad project) is the development and wide deployment of
software to run on end-user systems that would (as just one factor
among a variety of NNSquad-relevant measurements) help to gather more 
accurate throughput and bandwidth data.  A key issue in most 
consumers' purchase of Internet access services is advertised
speed -- but what are they really getting for their money?

By using a vastly deployed end-user structure for such measurements
on essentially an opt-in P2P basis (rather than relying primarily on
subscriber-accessed central measurement servers) a more accurate
picture of such parameters over time should be possible (and these
distributed measurements can still be centrally coordinated 
for analysis and to minimize associated traffic loads).

--Lauren--
NNSquad Moderator


> Interesting article, as I know BT peers at linx with numerous folks. I 
> would like to hear more about the test criteria.
> 
> One thing that we (as techies and so on) even forget is that single 
> stream (session, tcp or otherwise) measurements of bandwidth are not 
> typically reliable.
> 
> MS windows up to and including windows XP, default IP stack tuning is 
> best suited to a 10Mbps shared (CSMA/CD) Ethernet low latency LAN. 
> Through a few minor settings changes, one can improve net performance by 
> 20% to as much as 50% depending on the usage profile of the user. (e.g. 
> you live on the east coast, but more of the websites you visit are in 
> the EU, or on the west coast, or you're 75% metric is less than 40ms 
> round trip).
> 
> Also, another limiting factor is the asymmetric nature of xDSL (and 
> cable) with "normal" (no p2p involved:-) ) activity, can lead to delay, 
> jitter, and dropping of packets which control the overall sequence. If 
> the sending end doesn't receive the next request for packets, they won't 
> be sent.  I had unending problems with VoIP and comcast when I would 
> simply send a 100k email while on the phone.
> 
> A decade ago, at AT&T worldnet, we built out a large dialup US 
> nationwide network. In direct response to traffic gaps (sub 500ms) our 
> own 'Customer QoS' measurements in the network indicated, we adjusted 
> our servers to provide a different window size, and a smaller MTU (IIRC, 
> we settled at 576bytes or so).  What this did for the typical dialup 
> customer, was to fill the gaps in their download of email or usenet 
> (remember usenet?) and effectively doubled throughput to our users, at 
> no additional expense to us.  Interestingly, I do similar tuning for my 
> own servers to either limit (according to bandwidth contract costs and 
> conditions) or speed up responses.
> 
> Similarly, your chosen settings (tuned or not) and the default 
> algorithms in control of your TCP stack significantly effect overall 
> performance and throughput. (note the default TCP algorithm in linux 2.6 
> kernel alone has been changed three times that I recall).
> 
> Try any of the speedtest sites out there from different computers (OS 
> type, or IP stack tuning) and you'll see statistically significant 
> performance differences between them on identical test criteria.
> 
> Best regards,
> andy
> 
> Russell Smiley wrote:
> > http://news.bbc.co.uk/go/rss/-/1/hi/technology/7292932.stm
> > 
> > "BT Wholesale, which supplies eight million people, said many customers
> > were disappointed by the mismatch between advertised and actual speeds.
> > 
> > An independent survey found that 15% of people who bought eight megabit
> > per second packages actually got the speed.
> > 
> > The firm said regulators needed to agree rules about how broadband
> > speeds could be sold to the public."
> >