Date: Sat, 21 Dec 1996 23:21:42 -0700 From: alex huppenthal <alex@aspn.net> To: dg@root.com Cc: freebsd-isp@freebsd.org Subject: Re: UUNET vs Netcom Message-ID: <32BCD376.31D@aspn.net> References: <199612220338.TAA21948@root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > > >> > We left UUNET for sprint. UUNET had much better customer service, but > >> > with sprint we rarily need any customer service whereas with UUNET we did > >> > (they dropped alot etc) > >> > >> On the other hand, Sprint seems to have a lot of routing problems... > > > >I dont agree. Sprint is often blamed for routing problems, but most > >problems, when tracerouted etc were at MAE points. And places like > >ftp.cdrom.com no long route thru them etc. > > The routing issues with Sprint seem to have improved a little, but it > wasn't but just a few months ago that the Sprint network flapped so badly > that it was usuable. I think these problems have mostly been isolated and > dealt with (there was a flakey router in Dallas/FW that was lots of trouble, > plus various IOS problems in DC and Stockton). I was very happy when my > ISP here changed to default to MCI rather than Sprint...especially since > MCI had just done some major upgrades that helped things a bunch. > CRL peers with Sprint at the PB-NAP to avoid congestion that Sprint has > at MAE-west (and probably for other reasons, such as load balancing their > own circuits). Last time I looked, MCI peered with Sprint on the west coast > through a dedicated circuit. > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project According to my last discussion with Sprint, they recently upgraded several fiber rings, along with the Stockton location. We experienced lost packets and other problems with Sprint until just the past month. Our connection in Denver now peers with both Sprint and BBN. BBN periodically has troubles in the Bay area with significant delays. Anyone have a global measurement tool that would take minute by minute sample routes and create one report we can all share? Sprint claims they drop ICMP ping packets during congestion on purpose. Thus ping is not a good test tool. My experience is that Sprint historically didn't oversell capacity. Our local MCI clients have been complaining to us loudly. The ongoing upgrades each 'backbone' provider is undertaking makes picking one and expecting it to perform determisitically unrealistic. We used Netcom for some time and found them horrible this Spring. Over the period June-Aug their performance exceeded Sprints. Now Sprints is ahead. Cheers, -Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32BCD376.31D>