Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : The *NEW* Frank Coluccio Technology Forum -- Ignore unavailable to you. Want to Upgrade?

To: ftth who wrote (369)	7/9/2000 12:49:44 AM
From: Raymond Duray	Read Replies (1) \| Respond to of 46821

Adagio, Andante, Allegro, Presto, PRONTO Hi dave, Well, it was a quiet day in the sage country. Found that there is a really kuhl battle brewing in the world of unclassical music. It seems that the Napster crowd, giddy on a recent $15MM cash infusion has hired one David Boies to represent them in the case pitting them again the Recording Industry of America and parts unknown. This description is a howler: music.cnet.com I can see that Alice-In-Wonderland may be having a fine time in these California courts soon. Logic turned on its pointed little head. It be mere bits, meager bytes, by what right do we have a fight? A turvy topped delight? Ah, must be a plush plan from the Greatfuel Dead.... But my point, and I did have one, is that there is a really kinda good analysis of SBC's Project Pronto at this URL: cimicorp.com I'm going to limit my search of the FCC site to 5 minutes max and see if I can find the original merger docs. Wish me luck. I won't bore you with the URL for SBC's web page for the Pronto Pup. Let's just say it's aimed at fourth graders. And I'm afraid they're all too sophisticated to care about this site. Besides, they're all about 105 pages into "Harry Potter and the Goblet of Fire". :) OK, back to Napping If the RIAA would only let me get beyond flint knapping...

To: ftth who wrote (369)	7/9/2000 2:26:02 PM
From: Frank A. Coluccio	Read Replies (2) \| Respond to of 46821

I had to resort to the patent paper, but at one point I thought I had another reference that was printed in plain English that spoke about the partitioning of users in the TB system. If anyone knows where to find the processed version that I'm referring to, which takes the patent application and translates it into unambiguous and specific terms, please advise. ------ "Bottom line is p-mp is shared bandwidth, p-p is not. Very much analogous to cable vs. DSL, respectively. It's all shared eventually, but we're talking the last leg. Agree? simple yes or no will suffice." Short dumb answer, which you apparently want here, is yes. The longer answer: A simple yes or no answer to your question would be meaningless unless you refined the definitions of the terms you used. Not only does TB do p-mp at the physical layer (which may or may not result in diluting link capacity based on sharing, because its not always the case that the same spectrum is being used to each user system), they also do it with a proprietary addressing scheme (which I suspect could be a form of VLAN), and also allow for a form of multicasting within the embodiments of their own invention. Of course, they would also support IETF multicasting protocols at Layer 3, just as they purportedly support open shortest path first (OSPF) routing protocols. Do they "share" the air link? They use no fewer than four different ways to sectorize or otherwise differentiate the central to user beams (cones). They use vertical and horizontal sectorization, in addition to using different channels/or wavelengths. Nonetheless, each cone can only support a limited number of users who, in the end, wind up sharing the total system capacity associated with the particular beam [of which, there may be many <cones>] in question. That is, the I/O port at the central site node operates in serial mode, and therefore must abide by some resource allocation scheme. If it's a contention scheme (based on criteria that allow users to attach at variable hold times based on the amount that they have to send, then it's like Cable modem. If its a scheme which supports deterministic scheduling, then it's like ATM-supported dsl. Which one they support is difficult for me to discern due to the variability which they present in their patent papers. Perhaps they permit both flavors. In all honesty, though, I've not printed this out and given it much diligence, but this is what I'm able to discern. If anyone has a better grip on TB's scheme please correct or comment here. To wit, there appears to be a token passing scheme timed by a TDM flywheel at the heart of a resource arbitration protocol in a central site controller unit. As such, it appears that every packet within a subnet reaches every end user system where it is read and either accepted or rejected based on the correctness of the packet address. It's not clear to me from the Patent paper whether this is a true representatin of an unbiased TDM token passing model, where every user system in the subnet (segment) gets equal time to send data, or whether the timing of each token pass is dependent on other factors such as prioritization, or amount of data that needs to be sent by the current holder of the token, for example, which would result in a variable period for each pass, hence a degree of lumpiness and the potential for contention-based bottle-necking. Comments and corrections welcome.