Ghosting via TCP/IP
I have the following set up: Server: Win2000 Adv Server (SP2) (1) Promise SuperTrak 100 (6 channel IDE RAID) (4) 20GB ATA 100/7200RPM drives (1) 3C905B 10/100 NIC (1) TCP/IP protocol only Client: (1)IBM T22 (1) 30GB ATA100 5400RPM drive (1) Intel Pro 100SP NIC (1) DOS TCP/IP Boot disk Network: NetGear FS524 10/100 ...
I have the following set up:
Server:
Win2000 Adv Server (SP2)
(1) Promise SuperTrak 100 (6 channel IDE RAID)
(4) 20GB ATA 100/7200RPM drives
(1) 3C905B 10/100 NIC
(1) TCP/IP protocol only
Client:
(1)IBM T22
(1) 30GB ATA100 5400RPM drive
(1) Intel Pro 100SP NIC
(1) DOS TCP/IP Boot disk
Network:
NetGear FS524 10/100 switch
New CAT5 cables
No uplink to any other network.
I can connect to the server fine via DOS. However, when I ghost down from the server, I only get about 130MB per minute.
If I set up another T22 laptop with Win2K Adv Server (obviously no RAID), I can connect fine and ghost the same target PC at 400-450MB per minute.
I have 4 of these rack mount servers and they all act the same way. Is this an issue with the RAID card or configuration? I've set the block size on the raid card from 4k up to about 128k with no significant increase.
Any ideas?
Server:
Win2000 Adv Server (SP2)
(1) Promise SuperTrak 100 (6 channel IDE RAID)
(4) 20GB ATA 100/7200RPM drives
(1) 3C905B 10/100 NIC
(1) TCP/IP protocol only
Client:
(1)IBM T22
(1) 30GB ATA100 5400RPM drive
(1) Intel Pro 100SP NIC
(1) DOS TCP/IP Boot disk
Network:
NetGear FS524 10/100 switch
New CAT5 cables
No uplink to any other network.
I can connect to the server fine via DOS. However, when I ghost down from the server, I only get about 130MB per minute.
If I set up another T22 laptop with Win2K Adv Server (obviously no RAID), I can connect fine and ghost the same target PC at 400-450MB per minute.
I have 4 of these rack mount servers and they all act the same way. Is this an issue with the RAID card or configuration? I've set the block size on the raid card from 4k up to about 128k with no significant increase.
Any ideas?
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
This could be a function of the 3com drivers for the network card.
Or it **Could** be due to the RAID function of the Promise card (what is the raid configuration, etc.)?
Note though that even 450MB/min = ~8MB/sec sustained, which shouldn't tax even one of those hard drives. The 125MB/min = ~2.2MB/sec you are getting makes it seem like it is NOT a disk bottleneck.
Also, I assume all of the machines above have plenty of RAM?
Or it **Could** be due to the RAID function of the Promise card (what is the raid configuration, etc.)?
Note though that even 450MB/min = ~8MB/sec sustained, which shouldn't tax even one of those hard drives. The 125MB/min = ~2.2MB/sec you are getting makes it seem like it is NOT a disk bottleneck.
Also, I assume all of the machines above have plenty of RAM?
I had the Ovislink NICs in the servers before, so I tried the 3Com to be sure that it was not the NIC chipsets themselves.
It's now RAID5 (3+1) and it did the same thing in a RAID 0 config.
I've even tried a new RAID card. I thought that I read somewhere about a registry key that had to be modified to allow for faster DOS IP sessions. Any ideas there?
PIII-933MHz with 512MB PC133 memory.
It's now RAID5 (3+1) and it did the same thing in a RAID 0 config.
I've even tried a new RAID card. I thought that I read somewhere about a registry key that had to be modified to allow for faster DOS IP sessions. Any ideas there?
PIII-933MHz with 512MB PC133 memory.
Just on a side note, this is the article about the reg key:
SYMPTOMS
You may observe a long delay when you copy a file from an MS-DOS client to a Microsoft Windows 2000-based computer using the TCP/IP protocol.
NOTE: This behavior does not occur when you copy a file from an MS-DOS client to a computer running Microsoft Windows NT 4.0 or Microsoft Windows 95 or Microsoft Windows 98, or when you copy a file from Windows 2000-based computer to an MS-DOS-based computer.
CAUSE
This behavior occurs because the MS-DOS sender drops packets during the transmission. Windows 2000 uses a default TCP receive window size of 17 KB for Ethernet (8 KB in Windows NT 4.0). MS-DOS sends back-to-back packets in an attempt to fill the receiver's buffer that is flooding its network adapter. The MS-DOS real mode network adapter driver is unable to keep up with the stream of packets sent by the MS-DOS TCP/IP stack, which results in packet losses. The network adapter driver drops packets before they are placed on the wire.
RESOLUTION
WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
For information about how to edit the registry, view the "Changing Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT or Windows 2000, you should also update your Emergency Repair Disk (ERD).
To work around this problem, set the TCP receive window size in Windows 2000 to a value equal or less than 8 KB:
Start Registry Editor (Regedt32.exe).
Locate the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\Parameters
On the Edit menu, click Add Value, and then add the following registry value:
Value Name: TcpWindowSize
Data Type: REG_DWORD
Value: 8192
Quit Registry Editor & reboot.
SYMPTOMS
You may observe a long delay when you copy a file from an MS-DOS client to a Microsoft Windows 2000-based computer using the TCP/IP protocol.
NOTE: This behavior does not occur when you copy a file from an MS-DOS client to a computer running Microsoft Windows NT 4.0 or Microsoft Windows 95 or Microsoft Windows 98, or when you copy a file from Windows 2000-based computer to an MS-DOS-based computer.
CAUSE
This behavior occurs because the MS-DOS sender drops packets during the transmission. Windows 2000 uses a default TCP receive window size of 17 KB for Ethernet (8 KB in Windows NT 4.0). MS-DOS sends back-to-back packets in an attempt to fill the receiver's buffer that is flooding its network adapter. The MS-DOS real mode network adapter driver is unable to keep up with the stream of packets sent by the MS-DOS TCP/IP stack, which results in packet losses. The network adapter driver drops packets before they are placed on the wire.
RESOLUTION
WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
For information about how to edit the registry, view the "Changing Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT or Windows 2000, you should also update your Emergency Repair Disk (ERD).
To work around this problem, set the TCP receive window size in Windows 2000 to a value equal or less than 8 KB:
Start Registry Editor (Regedt32.exe).
Locate the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\Parameters
On the Edit menu, click Add Value, and then add the following registry value:
Value Name: TcpWindowSize
Data Type: REG_DWORD
Value: 8192
Quit Registry Editor & reboot.