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 Qualcomm - a S&P500 company -- Ignore unavailable to you. Want to Upgrade?

To: Clarksterh who wrote (3263)	11/15/1999 12:53:00 AM
From: quidditch	Read Replies (4) \| Respond to of 13582

Well, gosh dang, guys, this is cause to celebrate: posts from Bux, w, Mq, Go*Qcom and Clark all within 10 posts, ON THE SAME THREAD, IN Q-4 1999. This is almost stuff of which Revivals are made. Response to Bux's question, since you were kind enough to direct me to Webcast of HDR (after a week in which I missed all the fun): I believe the reference was to the effect that: the 50-100milisecond delays in packet data in HDR will never be noticed, while comparable delays on voice would become very annoying (in context of decision to split data channel from voice). Cheers, guys. PS Mq, glad to see you've seen the light on CE. Welcome back, want to hear of your travels (not just Geneva, but China, Ramsey's spread, that kind of stuff--oops, I'm violating). Tarkan--CS Lewis and the Kingdom of Narnia.

To: Clarksterh who wrote (3263)	11/15/1999 9:53:00 PM
From: Maurice Winn	Read Replies (3) \| Respond to of 13582

Clark, I think I get it now that the peaks and troughs over 100ms periods are the main problem and applications crash if they don't get the data they expect, so it's how to minimize those peaks and troughs. So data queues are the key. It seems that software should be able to allocate priority to packets and that priority be defined by price and selected by the subscriber. They push 'Send' on their email button and the packets that emanate from that button get a "Don't be in a hurry with these packets" bit of code on the front of the packets and they are given a red light. When the freeway is clear enough, they get a green light and start roaring up the on-ramp. So far, it seems like a software management problem to me and subscribers should play the predominant role by defining their needs on their packets when they push 'send'. They'd define their needs by the price plans they select. Commodity traders who will buy in the troughs and sell on the highs will enjoy the cheapest overall deals, but have to use their wits to achieve those gains. The lazy, stupid or rich will just put 'urgent' on everything and make the service provider very profitable. I agree the pricing differential wouldn't be small. If you want a clear motorway, expect to pay serious money. What amazed me was that the price was quite low in Los Angeles for that splendid new freeway. They should probably have a lower tariff in off-peak hours and charge more in peak [didn't see the flow at peak time]. By squeezing a lot more packets into the spectrum, the prices can be lower. Competition will be fierce. 30c per megabyte won't hold for long. That's extorquerationate. Mqurice PS: Maybe WMolloy or other software aces could comment. On the flow on highways, the bunching occurs because overtaking is difficult and people often have to wait a little to do it. Slower vehicles pull out and slow faster ones. Stuff like that, so the front of the flying block stops the fast stuff, which gets stuck behind it all. So it ends up with a wave of traffic. Another mechanism is sheer critical flow rate, similar to Reynolds Number in fluid mechanics. Once a certain flow rate is reached, turbulence ensues. Cars zoom along steadily and happily then when the critical flow rate is reached and saturation occurs, the tiniest thing upsets the flow and because of reaction times and pyschology, the whole thing collapses down to the maximum slow flow rate for that road. So the traffic goes from 120 kph down to 20 kph even though nothing appears to impede the flow. Ghosts of events can linger for an hour. Somebody waves a flag on a bridge. Traffic slows so somebody can gawp at it. Then the flag waver leaves. Meanwhile, the first one slowing, creates a cascade of breaking and accelerating and for the next half hour [provided the flow of cars coming is solid] the ghost of the disruption stays there and people go slowly up to the point, then suddenly realize they are in the clear and off they go. The ghost remains until the traffic thins a little and somebody sees they are in the clear BEFORE they get to the ghost scene and the ghost point moves upstream along the traffic flow as thin flow occurs. That's my theory. Just for interest. [Was nearly a traffic engineer in my early civil engineering days]. I doubt that IP packets work like that.