Jules - Re: " How does the 100mhz bus stack up against a DEC 64bit PCI?"
There are a lot of intertwined details here.
First, Windows NT. The ability of NT to handle a contiunual burst of data, coming in on an adapter card at 1 GigaBit/Sec, is the first bottleneck.
NT is not a real time operating system. As such, it does a lot of housekeeping things sequentially and each task has its own latency times. These system tasks cause it to be unable to service the adapter card often and quick enough to allow more than a few hundred MegaBITS/Sec to be received and read out from the card. The NT driver will send a bit stream, via the adapter card, to HALT transmission until NT can return to service adddtional data coming from the card.
Better interrupt handling and quicker task switching need to be added to NT to improve this.
Second - 64 BIT PCI. This version of PCI, 8 bytes wide instead of the "standard" 4 bytes, has been implemented by several manufacturers - DEC, Micron (?) and a few others. There is an effort to make this a standard although I'm not sure if it has achieved any ISO or IEEE standardization.
Another wrinkle is the PCI clock speed. Currently standard 8 byte (32 bit) PCI is spec'ed at 33 MHz and some supporters are trying to double this to 66 MHz - some efforts are trying to standardize BOTH 66 MHz and 64 bit.
Back to the 100 MHz 440 BX chip set. I believe this chip set supports standard 33 MHz/32 bit PCI - so there will be no advantage from the I/O adapter card using the 440 BX. the 100 MHz is divided down by 3 internally and the PCI bus is driven by this 100/3 (= 33 MHz) speed.
However, 1 Gigabit/Sec is only 125 MegaBYTEs/sec. The PCI bus can "theoretically" handle 4 bytes/read resulting in 31.25 Million Bus cycles/sec. The 33 MHz speed is the top speed - not cycle time of read operations.
Now - DEC has PCI controller chips/bridge chips which Intel may have rights to via the pending DEC/Intel "technology" sale arrangement.
Out of all this confusion, the 1 Gigabit/Sec will not be a reaility on Intel servers until faster/Wider PCI buses are available and Windows NT is speeeded up for I/O preocessing.
Interestingly, the AGP-2 spec should handle >512 MEgaBytes/sec. I wonder if it woudl be easier to add a second (or third) AGP card and use it for high speed serial data communications instead of graphics. In a server environment, I would assume that graphics speed is immaterial (no monitor!) so maybe the second generation AGP-2 port can be adapted for this purpose.
Another possibility is the new fast Firewire 1394 version that Intel supports - this should appear in a new chip set for Katmai. It may handle serial bit streams in the GigaHertz range.
Paul |
