So you are *deliberately* misleading people to state that "X2 is better
than K56Flex"?
Or did I miss something?
> And need I repeat that you offered a public bet of $1000 in this
> conference that NONE of the ports ran Livingston. We did present one, and
> indeed it does, and indeed I haven't received a check yet.
Statistically speaking Jack. Unfortunately, you can't statistically speak
to this, since you don't have the numbers to present.
Nor will you in the future, because "we don't care" in your own words.
See, that's the real problem. You just don't care what you malign and
whether or not your particular "conclusion" is actually demonstrated by
the evidence.
In point of fact, I don't believe that it is. At all. If your explanation
was valid I'd have returned all my K56Flex hardware a LONG time ago.
A few people do in fact have the experience of not getting a K56Flex
connection. They may call another ISP and get a PCM connect and not get
one with us. Of course, there are an equal number of people who come
to us because ISP-X can't get them PCM, and we do. There are call routing
differences within a LATA, not to mention between them, that cause this to
happen. Its not unexpected, in fact, its very much expected. You'd be
shocked at how many misconfigured trunks are out there.
But to argue that this is *systemic* to K56Flex ports is false in our, and
many other's, experience.
The problem I have with you, Rickard, is that you use data that has no
statistical validity for what you claim you found. Again, without knowing
what you're calling in a multivendor environment, your data documents
exactly nothing regarding K56Flex *as a protocol*.
Let's say that 5% of your "ports" were Livingston PM3s. Let's further say
that of those, all but one had excellent connect rates, and one had trashy
ones. Again, unless you know the details, including in some cases call
routing, the test is meaningless.
Let's further posit that of the rest, they were divided between Bay, CISCO,
ASCEND and a couple of others - but a plurality were in fact ASCENDs.
Finally, take those carriers who are long-distance companies and thus have
a serious advantage in terms of terminating circuits "correctly" - such that
they are not digitally padded, for example. Now, look at THOSE customers
and find me some PM3 users. What you'll find there are ASCEND TNTs and 3COM
Total Control systems, in many if not most cases only due to density issues
and false beliefs that putting 300+ ports (672 in some cases) into a single
chassis set is "smart".
This is probably pretty close to reality if you are testing against
multi-regional or national dial-in ports (ie: MCI, UUNET, etc). In fact,
"plurality" is probably not strong enough - "majority" is more accurate.
ASCEND, for example, claims a majority of *ALL* dial-in ports - including
those which you would exclude from that batch because they belong to
3COM/USR!
A realistic breakdown of likely distribution of K56Flex ports probably
looks something like:
70% ASCEND - concentrated in large telcos and national firms
15% PM3 - concentrated in regional and smaller firms
15% Everything else in a mix, with nobody being statistically significant
Why? Because the ASCEND MAX was there two years ahead of everyone else and
has a majority market share *for that simple reason*. The TNT is really the
only DS-3 capable datacenter concentrator in the real world right now, and
UUNET owns a boatload of them. Frankly, I think the design is stupid in
that it puts way too much to break in one box - but heh, that's me, and
telcos think differently. Now, add to this that many large shops simply
will not load code frequently, and that the central-site side on both
ASCEND and Livingston requires that you have current firmware if you
expect reliable performance.
Now, add into THIS equation the number of "resold" ports, in which case you
may dial four numbers and get the same box! Get bad call routing to that
device, and now you multiplied the result by 4, because you just don't know
that you were terminated in the same place even though you "thought" you
tried 4 different firm's numbers.
What does this mean? A *SMALL* swing in reliability in the majority port
concentrator device or a bad load of firmware screws EVERYONE'S statistics,
and to report that as a *protocol* problem is misleading.
Now, add into that the *fact* that Rockwell's 1.2 code is buggy as a roach
motel - that any other code in a K56Flex modem is preferrable, and you have
the ingredients for some VERY misleading results.
Likewise, PM3s running code prior to 3.7.2 had some significant problems
which could impact data rates. I could go over the litany of problems we
had with ASCEND firmware over nearly a year's time before we gave up,
but I won't.
By being *unable*, or *unwilling*, to disclose the hardware and firmware on
both ends you make it IMPOSSIBLE to figure out if you were measuring a flaw
in one device, one version of firmware, or a true protocol problem.
Your data does not support your conclusions Jack. Plain and simple.
FIELD EXPERIENCE from hundreds of ISPs running PM3s says that its not a
protocol problem. I'm going to post my statistics this week as soon as
I can get around to pulling them - we have online stats going back more than
two years, although for sanity's sake I probably will only dump 90 days
worth.
Ask someone who has a ZOOM running 1.2, and they'll tell you that it sucks.
---- 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 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>