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 QLogic (ANCR) -- Ignore unavailable to you. Want to Upgrade?

To: iceburg who wrote (12914)	12/4/1997 10:35:00 AM
From: KJ. Moy	Respond to of 29386

Ice, <<<K.J., I am trying to make sure you are wrong about the 2048 bytes minus FC headers frame delimeters . I will post later when I find out for sure. For software and hardware reasons and IMO that would be a terrible design and I don't think that is accurate, but I am making sure so we can all rest easy. I am hoping each frame has 2048 bytes plus FC headers and frame delimeters and I'm sure I will find this is the case.>>> Thank you for calling Cal and correcting me. That's why I use the word 'about' in front of my statement. I was terrified also when I read that. If it was read at face value, that means a 1 gig switch can only deliver 25% throughput. We may as well quit. I wanted to send out that reply asap this morning and fill in the exact numbers later(or fill in by you). Thanks again. KJ

To: iceburg who wrote (12914)	12/4/1997 11:17:00 AM
From: George Dawson	Read Replies (2) \| Respond to of 29386

Steve, Thanks for calling Cal. According to Benner, the MTU (Maximum Transfer Unit or maximum frame size on the physical network) for FC is 2112 bytes. Using the numbers from the redone MKII page: ancor.com You get: 1.0625 Gbps x 2112 (payload)/2148 (payload + overhead) x 1 byte/10 encoded bits = 100.4 MBps Using the 512 byte payload and the same number of bytes overhead (36 bytes) you get: 1.0625 Gbps x 512/548 x 1byte/10 encoded bits = 99 MBps To me the throughput would drop slightly, because the proportion of frame used for overhead increases as the payload frames get smaller. This is actually one of the arguments for FC over ATM where the frame size is 53 bytes and the header is 10%. For the FC frames above the percentages of overhead are 2% and 7% respectively. For some applications this difference won't be great. But in others, especially where larger frames from another protocol need to be mapped onto FC frames - larger frames will be faster. I think we may be seeing a replay of the great latency debate with the detractors from this summer. In case anyone forgot - Ancor won that one. My statements as always are qualified by - I know what I read and I am not an engineer. George D.