🚀 go-pugleaf

Karl Denninger wrote:
> 
> 
> 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.

The objective of Rickard's test wasn't to sign on anywhere which he said
in
his article, "Our objective with the testing was call completion rates
among
ISPs."  Rickard explained how he came up with his data and he even let
K56FLEX
representatives try to improve the results from their equipment.  I
think the
data in his article was good.

>         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.
> 
For K56Flex, it shouldn't have mattered what was on the other end of the
connections.
The K56Flex consortium came up with their own standard and it should
have worked no
matter who made the equipment.  If this is indicitive of how well they
can make
modem equipment to a standard, I would hate to see how they comply to
the V.90
standard.

> 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.
> 
 
Rickard already tells us this in his article, tested this, and came to
this
conclusion, "The claim has some merit - just not enough by an order of
magnitude
to support the observed performance differences. "

> 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!
> 
Rickard also mentioned that long distance connections should be better.
He made
calls long distance with both X2 and K56Flex modems.  If the connections
should
be better, why did the K56Flex modems perform so poorly.

> 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.
> 
If this is so important, why didn't the K56Flex modem people document
this.
Actually, if this is so important, why doesn't the K56Flex standard
negotiate
this setting when they connect or at least make this the default
setting.

>         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.
> 
Rickard paid to make his calls, I doubt very much if most of the ISP's
lost that
much money from his test.

> 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.
> 
Rickard asked for real world data from ISP's, even from one's that
Livingston
and Rockwell suggested.  As he said in his article, none of the K56Flex
ISP's
came through with their data, only X2 ISP's did. 

> 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.
> 
Bluntly, I think the "test" was more than representative of the typical
Internet user.  Rickard bought the lastest models of the modems of the
shelf
and made sure they were running the latest code, which in itself is more
than
what the "typical local Internet user" would do.  I find most typical
Internet
users don't even know what the difference between modem protocols are,
let
alone getting the lastest code and tweaking 's' register settings for
their
modems.

> 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!
>
I think it is relavent because it shows that K56Flex manufactures
couldn't
make modems that conformed to their own standard.  Why would I think
they could
make modems that conform well to the V.90.

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

Jim Oliver
oliver@execpc.com