SI
SI
discoversearch

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 : USRX

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Rich who wrote (16724)3/26/1997 9:13:00 AM
From: Pullin-GS   of 18024
 
Most likly the standard selected will be influenced by the technologies we are familiar with (X2, etc), but the standard will hopefully be more compatable with current async standards (A well-thought out standard includes a smooth transition from one to the other on dirty lines)...perhaps one that queues data during times of poor line conditions (makes actual data throughput less "bursty", and more tollarent to applications that work well in a non-bursty environment such as voice and video...cool!), and possibly even a connection-oriented standard (much like X.25) that will resend data during poor line conditions, and at a pre-dedermined point throttle back to a more forgiving line speed. Current standards do not support packet loss. Once a packet is dropped the data is lost forever, unless your application requests a packet to be resent. Throttle-back does not happen at all accept on the initial handshake when establishing a connection. Also the new standard will involve the FCC in determining a maximum download capacity (perhaps greater that 56K??) that will exist well within current FCC allowable EE eminations as specified by it's regulations. In summary I don't expect (IMO) to see a current proprietary standard adopted as the ITU-T, IEEE, or ANSI async standard.

PRB
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext