🚀 go-pugleaf

In article <6d6ug4$lnn@newsops.execpc.com>,  <curt@execpc.com> wrote:
>Many people question us on "56k" modems, and more recently, v.90, the
>new standard for the "56k" modems, or PCM modems.
>
>The cover article from the March, 1998 Boardwatch magazine has information
>that anyone even slightly interested in modems should read.  It can be found at:
>http://www.boardwatch.com/mag/98/mar/bwm24.html
>
>Not only does the article go into the new v.90 technology, it shows some
>comparisons between k56flex and X2, which should be quite suprising to
>some of you (it wasn't to me).
>
>Some people have claimed various things about the two technologies in
>this newsgroup.  This article pretty much puts all the arguements to rest.
>
>-------------------------------------------------------------------------- 
>  Curtis V. Shambeau  |  curt@execpc.com  |  http://www.execpc.com/~curt 
>                        Executive Vice President, Exec-PC, Inc.
>-------------------------------------------------------------------------- 

Note several things about the Boardwatch "article":

1)	They never signed into anywhere.  Therefore, there are several
	problems with the so-called "data":
	a)	There's no independant verification possible from the other
		side of the connections.  Without RADIUS logs, there's just
		no way to know if we're really getting good data from
		Rickard or not.
	b)	There is no indication of what devices were on the other 
		end of the connections, because Rickard didn't bother
		coordinating these tests with the other side of the link.
		There is ALSO no indication of what FIRMWARE is on the other
		end of the links, and that, for some manufacturers, is
		critically important.

2)	USR is known to connect at a higher rate than it can actually
	support, and then downshift.  This is NOT new behavior; USR modems
	have done this for years.  But it leads to misleading "statistics"
	if you look at the "connect rate" at origination, rather than
	termination, of the call.

3)	K56Flex is known to typically (in most implementations anyway)
	connect at a LOWER rate than it can actually support, and then
	upshift over the next couple of minutes.  This exacerbates the
	discontinuity that (2) would result in.  Rickard actually
	acknowledges this.

4) 	Long-distance connections are NOT typical of the usual ISP user
	profile.  Yet that is *ALL* that Rickard tested.  This gives insane
	advantages, for example, to the carrier that the tester uses for IXC
	carriage!  Why?  Because there is at least one "crossing" between
	the LEC network and the IXC network that don't have to take place,
	and probably *TWO* such crossings.  This is going to grossly skew
	the results and likely invalidate them entirely in the realm of
	local access users.

	Further and most paradoxially, connections between two IXCs might 
	be the best of all!  Why?  Because they tend to have newer equipment,
	the DACS they traverse tend to be channel-aligned (resulting in
	fewer robbed bits in the LSB, and really more by accident - IXCs
	tend to concentrate at their entry to a city, and that leads to DACS
	which do full DS1 or even DS3 mappings with few discontinuities,
	which is what leads to the bit robbing misalignment), and those trunks 
	are monitored - and fixed when they break.  It is VERY common for LECs 
	to ignore alarms for literally months, leading you to wonder if they 
	even wire the ALARM output on their switches to anything!

5)	In the realm of K56Flex, Rickard doesn't know about the S202=32 
	init switch (primarily because he never called any of the tested 
	ISPs tech desks).  That's an undocumented, but VERY important 
	switch to turn on in some Rockwell versions.

	The Zoom and TDK CyberExpress5600 modems, in particular, DO work 
	in a 2-bit robbed environment.  I know this, because I get these
	connections *all the time* and the firmware reports 2 or even 3 bits
	robbed a good bit of the time.  Rickard and whoever he claims to have
	talked to are simply wrong on this.  However, you *DO* need S202=32
	in the init for a whole bunch of those firmware revisions for it to 
	work in a 2-bit robbed environment.

6)	For those who buy their time from others, Rickard just billed them
	for hundreds of minutes of time without their consent and not as
	their customer.  This looks an awful lot like theft of service,
	absent informed consent.  If I were paying by the minute, I'd be
	looking for someone to be indicted over this.

7)	We, and many others, just don't see anything close to what Rickard
	claims is happening.  We have hard logs in our DBMS for every call
	- including ACTUAL data transmission rates.  I've got data going
	back to April of 1996, when we first switched to RADIUS from our
	proprietary system, on both V.34 ASCEND and K56Flex
	Livingston/Lucent hardware.

	His data is simply non-representative of the real world, and I know 
	of a whole lot of other ISPs who are saying the same thing.  We're 
	not alone on this.

8)	If, in fact, any of these resellers were connecting less than 2/3rds
	of the time, I'd argue that they'd all be out of business.

Bluntly, the entire "test" simply isn't representative of the typical 
local Internet Access User, or our documentable results.  Further, the 
results have no peer review, are flawed in terms of methodology, and fail 
to control for known issues inherent in both technologies as well as the 
telephone network.

Finally, its all irrelavent - V.90 is due out on the central site side for
virtually everyone's gear within 60 days, and these results, even if they
ARE "correct" for some set of conditions, will have nothing to do with V.90
results!

Rickard likes to claim that USR will have the "best" V.90.  We'll see...

I'll put *ACTUAL* throughput *AND* connection rates of our K56flex plant 
up against X2 any day of the week, and anyone who would like to run a REAL
test is welcome to get ahold of us.

--
-- 
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/          | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex support on ALL modems
Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS
Fax:   [+1 312 803-4929]     | *SPAMBLOCK* Technology now included at no cost