| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2059.1 | | 12368::thomas | The Code Warrior | Fri Jun 07 1996 14:52 | 2 |
| WinNT is in need of an overhual. It's TCP implementation is not tuned for
high-bandwidth networking.
|
| 2059.2 | | NETCAD::STEFANI | | Fri Jun 07 1996 16:27 | 14 |
| >>Is my data off? Are the drivers is use of an overhaul? Would appreciate any
>>I/O here.
I won't say my device driver is the greatest thing since sliced bread,
but no, the device driver being overhauled won't help your performance.
The Windows NT 4.0 BETA that I've looked at seems to have improved
performance. At least, the Hardware Compatibility Test suite for NDIS
drivers indicates decent numbers for FDDI. Architecturally, NDIS 3
suffers from having to do buffer copies on all receive packets. This
is something Microsoft is addressing in their upcoming NDIS 4
specification.
- Larry
|
| 2059.3 | How fast is the transmit side using NT? | KEIKI::WHITE | MIN(2�,FWIW) | Fri Jun 07 1996 17:51 | 11 |
|
Larry,
In this simplistic test you say we are being limited by the
recipient of the copy operation.
Can we infer from this that the transmit performance of the NT
FDDI driver would be better than 3.x MBytes per second if we were
servicing multiple recipients simultaneously?
Bill
|
| 2059.4 | not to interject.... | KOZY::SARKOZY | Anyone know where Magyarorszag is? | Fri Jun 07 1996 18:08 | 16 |
| but, they are really interested in point-to-point performance. The customer is
moving lots of data between two servers (Raster Image Processing application).
So, aggregate throughput through multiple links wouldn't really help.
Does D-UNIX get up to 8-12MB/sec? Which piece of s/w is really hurting us here?
Do we know? Is there a h/w difficiency here? Does the DEFEA perform just as
well on a 2100? Is the T2 PCI host-bridge hurting us on this?
The customer feels they should be pushing at least 8MB/sec through this link.
They h/w is there and they feel s/w isn't this issue on a platform like the
2100. And, at 15 systems/month, well, hmmm....
Thanx for the I/O,
Ron S.
|
| 2059.5 | | 12368::thomas | The Code Warrior | Fri Jun 07 1996 18:24 | 8 |
| Digital UNIX has no problem saturating a FDDI. The 2100 this is typed on can
hit 8MB/s quite easily. Heck, an Intel Pentium can do 8MB/s (running one of
the BSD UNI).
The hardware is not the problem. The problem is NT. NT does not currently
timestamps and large windows which are needed for getting the most out of
FDDI. Couple that with having to copy buffers on receive, you just can't
get good performance.
|
| 2059.6 | | NETCAD::STEFANI | | Mon Jun 10 1996 08:26 | 15 |
| Matt's right. We knew from simulation as well as production products
like the DEFTA (FDDI TurboChannel adapter) that the DMA controller
that's common to the FDDI adapters (including DEFPA) can handle FDDI line
speeds. It is certainly not the hardware design that's keeping you
from achieving the performance you're looking for.
It's a sad fact Windows NT has some I/O performance problems, that
Microsoft is only now beginning to address. The device driver is
limited to what the NDIS sublayer allows it to do in terms of receiving
and transmitting packets. There *is* some tuning that you can do, for
example, increasing the window size on TCP/IP, that might help your
performance. There's probably other performance tuning that you can
do to help.
-Larry
|
| 2059.7 | NT: someone said it stands for 'neat toy' | BBPBV1::WALLACE | Whatever it takes WHO?(sm) | Wed Jun 12 1996 17:03 | 14 |
| Ron,
There's an interesting customer-readable whitepaper around on the
optimisations in the DEC OSF/1 (as it then was) TCP/IP driver. I wish I
could remember what it was called; maybe some kind soul can (or do an
internal Altavista search for some suitable keywords...)
Welcome to the world of hard reality. NT is not VMS++. NT is not Unix.
It does do a lot of things very nicely. You've found a Quality
Improvement Opportunity; your guess is as good as mine as to where this
is likely to be on Bill's ToDo list.
regards
john
|
| 2059.8 | How to set TCP/IP window size under Windows NT | NETCAD::STEFANI | | Wed Jun 19 1996 12:08 | 30 |
| FYI - To increase the TCP/IP window size under Windows NT, use the
Registry Editor by running REGEDT32.EXE. Go down the following tree
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
and add a new value called "TcpWindowSize" of type REG_DWORD.
The following description is taken from "Optimizing Windows NT" which
is part of the Microsoft Windows NT Resource Kit.
TcpWindowSize REG_DWORD number
This parameter determines the maximum TCP receive window size
offered by the system. The receive window specifies the number
of bytes a sender may transmit without receiving an
acknowledgment. In general, larger receive windows will
improve performance over high delay or high bandwidth networks.
For maximum efficiency, the receive window should be an even
multiple of the MTU of the underlying network less the size of
the standard TCP and IP headers (40 bytes).
Default: The smaller of: 0xffff OR the larger of: four times the
maximum TCP data size on the network OR 8192 rounded up to an
even multiple of the network TCP data size
Note: The MTU for an FDDI node is 4491 bytes including the MAC header,
but excluding the 4 byte CRC. The MTU is 4470 bytes if you also
exclude the 21 byte FDDI 802.2 SNAP LLC header for a TCP/IP frame.
I don't know which MTU "size" you should use for your calculations.
|