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 : The New QLogic (ANCR)
QLGC 16.070.0%Aug 24 5:00 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: iceburg who wrote (12914)12/4/1997 11:17:00 AM
From: George Dawson  Read Replies (2) 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.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext