I'm going to deliberately elide any portion of Rickard's spew in which he
makes a personal attack... which, unfortunately, is most of it...
With that said...
> I understand, and even agree to some degree. In fact, it's what I've been
> saying. And from what we can see, with a LOT of different paths, over a
> lot of different days, is that there is a huge difference between x2 and
> K56flex - specifically on the array of different paths that they will
> operate on. And I have no doubt you haven't seen it. You're looking in
> the wrong place to see it.
My customers aren't in the wrong place to see it, and they don't see it.
> Roughly, there were no K56 sites that had "excellent" connections. There
> were some calls that looked pretty good. We know that on any path that
> exhibited 0 rob bits, we got some form of K56flex PCM connection. If it
> has 1 rob bit, it had generally difficulty. If it had 2 rob bits it just
> almost never had a PCM connection.
Right there you have just demonstrated that you don't know what in the hell
you're talking about.
How do I know this? Because ALL OF OUR K56FLEX MODEMS ARE ON CT1 TRUNKS,
AND ALL OF THEM USE WINK START SIGNALLING, WHICH MEANS ALL OF THEM ARE ON A
TRUNK GUARANTEED TO ROB THE LOW ORDER BIT!
Guaranteed Jack. Not supposed, not might, GUARANTEED. We don't run modems
on PRIs. Never have.
Second, you CAN'T rob two bits. If you do, you're no longer complient with
anything, and further, you will find that DOV service fails as well (since
it relies on 7-bit transparency). Yet DOV does work here.....
If you have tampering in the 7-bit range, then the switch or its configuration
is BROKEN. Period. You can "digitally pad" DS1s, which will break them every
time for PCM, but that's not a "well, it works sometimes" situation - it will
NEVER work in that situation at all, and it doesn't matter if you're running
X2 or K56Flex..
Now, once again, explain how we get ANY K56Flex connections, much less the
huge number that we get, when EVERY ONE of our modem trunks is a robbed-bit
trunk......
Second, how would you *KNOW* how many bits are being robbed end-to-end? You
had equipment on the *OTHER SIDE* of the connection? Test hardware?
There's no other way to know for sure Jack.
> And the K56flex
> operates well on a much narrow range of paths than the x2 does.
Unproven by your own release of information, since you've admitted that you
don't know what hardware and software was on the central-site side.
> But in any event, we pick 5 POPs from each of 90
> ISPs. Now some of these are wittle bitty ISPs that have a footprint in at
> least 25 area codes, and some are indeed UUNET, MCI, and most notably in
> this case, GTE (BBN) who is fully deployed with K56flex. But whether large
> or small, they each get precisely five. One could account for 60,000
> ports, and another 6000 ports, they each look about like, in fact exactly
> like, precisely five ports to us.
Really?
I guess you'd wonder about us then - we have over 120 ports spread across
two LATAs, and guess what - all of the Chicago numbers, OVER 100 OF THEM,
map into one set of devices.
> No. Actually we have a pretty good idea. 90 ISPs, 450 theoretical ports,
> but actually 328 discrete phone numbers.
And how many discrete access servers? Do you know? CAN you know? No, you
can't. Why? Well, gee, I happen to have proof right in my computer room in
Chicago and Milwaukee that you can't possibly know. In fact, I have over
100 DID numbers in rate centers all across the LATAs involved that ALL
terminate in the same place.
Now, if I'm a reseller, maybe I give you a unique DID number to call. Its
smart in more ways than one, not the least of which is that it let's me
determine who's using the line (which ISP).
Does that mean that you hit 328 discrete devices? No. You might have hit
only 100 discrete devices. Or less. You just don't know.
Worse, you might hit two different devices on two different calls to the
SAME number. In fact, if you had called our numbers, you would be virtually
guaranteed to do exactly that.
> For a minority to pull the train, it would have to stand out sharply.
> Nothing does, other than the fact that the more of your ports that are
> K56flex, the lower the figures AND the poorer the connection rate.
Again, your evidence that you have admitted to having does not support this
conclusion. At all. It supports the conclusion that *the devices you were
calling had poorer connections from YOUR site over YOUR long-distance
carrier to THAT SPECIFIC device and firmware from your SPECIFIC modem and
firmware.
Without all of the blanks filled in, that's ALL you can legitimately say
about your "test".
What I have posited is that a *majority* pulled the train, and that majority
was made by a particular manufacturer. I might be wrong about that - its
based only on my experience with two particular vendors, with one of them
having what I *know* is a functional and properly operating PCM
implementation.
> Those aren't misleading results. Those ARE the results. Whatever code was
> extant in public, taking calls from paying subscribers at the time, was
> what was tested. It could be a mix of versions or they could all be your
> "bad" version. We do know that the modems we used had the latest publicly
> availlable software, both on January 1 and about January 22, and that we
> didn't have to make any changes between those two dates to the code.
The current firmware for the Zoom is of that time was 1.2 and is buggy.
I don't have a Diamond or Moto here in front of me.
> That it is IMPOSSIBLE to measure something
> we weren't trying to measure, from the data we did derive, sorta/kinda
> sounds like nonsense doesn't it Karl?
What you claim to be measuring and what you ACTUALLY measured are two
different things.
> > Your data does not support your conclusions Jack. Plain and simple.
>
> Since you haven't seen the data, how do you know whether or not it supports
> my conclusions Karl?
You have posted, publically, what data you have and don't have, and you've
said enough to draw the conclusions you ALSO publically posted.
> We keep coming back to this. If you want credibilty
> in this discussion you have to get out of the circular loop that "your
> conclusions are faulty because your methodology is severely flawed, and we
> know the methodology is flawed because we don't agree with your
> conclusions."
You've told us what you have and don't have in the way of information from
the central site. That's enough to know that you're lacking the critical
information to determine WHAT you were measuring in your "test".
> Now wait a minute. You just told me that PM3's were a small minority, with
> few installations, and hadn't been out that long. Now you have years of
> field experience with hundreds of ISPs running PM3's that are sure it's not
> a problem. Which is it?
I have years of field experience with various devices running RADIUS and the
logs to prove up every connection, including the termination reason, final
data rate, number of bytes passed in each direction, session ID, number
dialed (in some cases), and in some cases, ISDN in particular, the calling
number as well. All of it in a nice SQL database consuming something like
10GB of table space.
> In point of fact, I'm quite interested in how we could get results this
> poor, and ISP's could be this happy.
When you see this kind of disparity, it tells you pretty conclusively that
you weren't measuring what you thought you were measuring.
> What this is gravitating toward is
> precisely what they DO see when they run a central site equipment. If you
> had hundreds of callers getting stiffed, how would you know?
They pick up the phone. All of them. That's why we have a tech department.
If you think that our users go out and buy a new modem to get the higher
speed, don't get it, and remain silent I have this great bridge for sale in
Brooklyn.
> One of the
> things that has jumped out already, is that if a K56flex caller hits your
> port, and it drops to a V.34 session, do you detect this? Can you separate
> it in the logs from a V.34 call from someone with a V.34 modem?
Nope. But our customers can. And they do, not surprisingly, since they
expect to get what they bought. That should be obvious on its face.
> In fact,
> we're setting up a test with one of your private e-mail admirers here in
> Colorado. We're going to beat a single number bloody for a few days. He's
> going to send me his log and I'm going to send him my database and compare
> call by call what he sees and what I see. I'm guessing at this point that
> we see the same thing from very different perspectives.
Of course, you wouldn't want to actually pass data with someone like me now,
would you?
> Now someone just told me Zoom was just the thing to have. We had one Zoom
> modem from about January 22, that Rockwell brought out as being the "good"
> modem, and it didn't do any better or worse that we could detect. It had
> the same problem on the same paths. 0 rob bit looked good. 1 rob bit or 2
> rob bits, no PCM - fall back to V.34, after 40 seconds of screeching and
> howling and complaining.
How do you know how many bits were being robbed Jack?
And second, how come it is that you claim that 1 or 2 robbed bits and it
doesn't work, where the bottom line is that 1 robbed bit works here (and has
to, since all our trunks are robbed bit), and 2 is outside of the
specifications!
---- 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/>