<div>
So it is a wired and not wireless network.<br />
Firewall, AV?
</div>


<div>
Is there a switch connecting the servers with the workstations? That might be your bottleneck.
</div>


<div>
It is a wired lan<br />
Yes there is a switch <br />
Hmm, no, I didn't think of rebooting it. Darn.<br />
It's a 16 port D-Link switch<br />
I'll get a user to restart it tomorrow<br />
Thanks
</div>


<div>
A good reboot is always one of the best solutions. &nbsp;Also, if the reboot doesn't fix it, try testing from a different workstation. &nbsp;Make sure that the workstations NIC is set to the network speed/duplex setting of the switch.
</div>


<div>
Not nearly enough information.<br />
<br />
How many computers are on the network?<br />
<br />
Is is a single IP subnet?<br />
<br />
Brand, model, and number of switches.<br />
<br />
NIC speeds.<br />
<br />
If you think it is cabling, then make sure you have CAT5 if everything is 100 Mbps, or CAT5E or better if 1000 Mbps.<br />
<br />
If all switches are unmananaged, then all computers should be set to auto speed and auto duplex.<br />
<br />
If switches are managed, then the switches and the computers should be configured the same as the port they are connected to. &nbsp;Either both auto/auto, or both fixed speed and fixed duplex.
</div>


<div>
1. Restart the machine<br />
2. Restart the switch<br />
3. go into the nic properties and make sure as above it's set to duplex auto.<br />
3. try testing after each of these settings has been adjusted to see the improvement after each one<br />
<br />
because you said the other machine had been ok i would possible assume that the issue was the machine itself has not been restarted.. you can use pstools or check network status to see how long the machine has been up
</div>


<div>
We restarted the switch this morning<br />
<br />
And tonight I'm running Wireshark on the server<br />
<br />
I noticed during a file copy between a PC and the server I get pile load of &quot;TCP DUP ACK&quot;<br />
a spattering of &quot;SMB TCP RETRANSMISSON&quot;, and &quot;TCP ACKed unseen segment&quot; <br />
<br />
I also noticed before the file copy that there were a nimber of TCP KEEP-ALIVE<br />
<br />
I swimming in uncharted territory here; I know, you've got to start somewhere<br />
<br />
yann
</div>


<div>
If you can you may want to run a packet capture on both the server and client and then copy a file.<br />
<br />
&quot;TCP ACKed unseen segment&quot; can be normal if it appears at the start of a capture and it is on a TCP connection that was already established.<br />
<br />
&quot;TCP DUP ACK&quot; means that either that a packet was received out of order, or the receiver waited &quot;x&quot; amount of time for the next packet, it did not come, so it is resending the ACK.<br />
<br />
I will to read up o the &quot;TCP KEEP-ALIVE&quot;. &nbsp;I know what it is supposed to be used for, but I'm not sure why it would be used on a file copy.
</div>


<div>
RETRANSMISSION points at some packet loss being there, forcing the sender to re-transmit.<br />
<br />
What does a simple ping show?<br />
Any packet loss?<br />
<br />
Can you try with just the client and server connected (unplugg all other ports)?
</div>


<div>
I updated the LAN drivers on both the server and the workstation from which I was testing the filecopy : no difference.<br />
<br />
I ran another file copy and the 
<blockquote>
 Dup ACK (...) sddp &gt;&nbsp;microsoft-ds [ACK] 
</blockquote>
 reappeared in similar abundance<br />
<br />
PINGs are fine, no visible packet losses<br />
<br />
I ran LAN SPEED TEST from another workstation with 1 and 10 MB packets and got more or less the same result as before : 0.5Mbps Writing (Upload) and 80 Mbps Reading (download)<br />
<br />
During the speed test Wireshark was full of the following lines : <br />

<blockquote>
TCP Previous segment not captured<br />
TCP Fast Retransmission<br />
TCP Out of Order<br />
TCP Keep-ALive
</blockquote>
I beginning to believe that the switch could be the source of our problems.
</div>


<div>
Apparently the TCP Dup ACK are the result of brute force attacks on the server's port 3389 (Terminal server)
</div>


<div>
The sluggishness was finally due to Ethernet wiring issues
</div>


<div>
I've requested that this question be closed as follows:<br />
<br />
Accepted answer: 0 points for azurtem's comment <a href="https://www.experts-exchange.com/questions/28379284/Slow-LAN.html?anchorAnswerId=40009798#a40009798" rel="ugc">#a40009798</a><br />
Assisted answer: 0 points for azurtem's comment <a href="https://www.experts-exchange.com/questions/28379284/Slow-LAN.html?anchorAnswerId=39907168#a39907168" rel="ugc">#a39907168</a><br />
<br />
for the following reason:<br />
<br />
situation is fixed
</div>


<div>
<div class="content wysiwyg-content">
Hi<br />
<br />
I was at a client site today and was surprised at how slow file transfert was.<br />
<br />
I had simply copied a 4.5MB file over to the server, a Windows Server SBS 2008 R2, and had to wait an unusually long span of time for its completion.<br />
<br />
I installed 'Lan Speed Test' together with the LST Server module and ran some tests.<br />
<br />
The XP PC, on which I had first noticed the sluggishness during the file copy, the test utility never made it to the end of its 10 packet cycle. I tried various packet sizes but the issue was always the same after two or three packet I got an &quot;error writing to the server&quot;<br />
<br />
I then ran the same test from a W7 PC, at 1, 10 and 100MB packet sizes. The average writing (upload) throughput hovered close to 1 Mbps, while the reading (download) average was around 70 Mbps.<br />
<br />
My opinion is that this situation is the result of bad cabling, <br />
<br />
What is your opinion ?<br />
<br />
Thanks <br />
yann
</div>
</div>


Hi

I was at a client site today and was surprised at how slow file transfert was.

I had simply copied a 4.5MB file over to the server, a Windows Server SBS 2008 R2, and had to wait an unusually long span of time for its completion.

I installed 'Lan Speed Test' together with the LST Server module and ran some tests.

The XP PC, on which I had first noticed the sluggishness during the file copy, the test utility never made it to the end of its 10 packet cycle. I tried various packet sizes but the issue was always the same after two or three packet I got an "error writing to the server"

I then ran the same test from a W7 PC, at 1, 10 and 100MB packet sizes. The average writing (upload) throughput hovered close to 1 Mbps, while the reading (download) average was around 70 Mbps.

My opinion is that this situation is the result of bad cabling, 

What is your opinion ?

Thanks 
yann

Slow LAN

Networking is the process of connecting computing devices, peripherals and terminals together through a system that uses wiring, cabling or radio waves that enable their users to communicate, share information and interact over distances. Often associated are issues regarding operating systems, hardware and equipment, cloud and virtual networking, protocols, architecture, storage and management.

Networking

The Windows operating systems have distinct methodologies for designing and implementing networks, and have specific systems to accomplish various networking processes, such as Exchange for email, Sharepoint for shared files and programs, and IIS for delivery of web pages. Microsoft also produces server technologies for networked database use, security and virtualization.

Windows Networking

A switch is a device that filters and forwards packets of data between LAN segments. Switches operate at the data link layer or the network layer of the Open Systems Interconnection (OSI) Reference Model and therefore support any packet protocol. LANs that use switches to join segments are called switched LANs or, in the case of Ethernet networks, switched Ethernet LANs. A hub is a connection point for devices in a network. Hubs are commonly used to connect segments of a LAN. A hub contains multiple ports; when a packet arrives at one port, it is copied to the other ports so that all segments of the LAN can see all packets.