Okay, here we go again...
Alright. Collisions will ALWAYS occur if the ethernet devices (the ethernet card and the hub/switch) are set to half-duplex. This is normal.
Half-duplex IS going to be slower than Full-duplex by nature, but if you're plugged into a switch, things shouldn't be very much slower than with Full-Duplex, unless you're trying to transfer files both directions at the same time. I'd expect to see about 10% performance loss when using half-duplex and plugged into a switch. You're seeing about 98% speed loss.
Hubs do NOT support full-duplex. Only switches do. Chances are that your Linksys is NOT a hub - it's a switch. This makes a big difference. What model # is it?
Here's the absolute biggest, most common cause of performance problems in Ethernet. Sorry it's so wordy, but it's good info:
If you've configured one side of an Ethernet link (the Ethernet card or hub/switch) to full-duplex, and left the other side at "auto-negotiate", your transfer speeds will be TERRIBLE. If, for example, you configured the Mac to "auto" (default in OS X), and configured the switch to "full", you'll see slow performance both directions, but will see ESPECIALLY slow performance when copying from the Mac to other devices.
The reason that hard-coding full duplex on one side and leaving auto-negotiation turned on the other side causes problems, is that when you specify full-duplex on an ethernet device, auto-negotiation is DISABLED on that device. People mistakenly think that the side of the link that is set to auto-neg will be able to detect that the other side is set to full-duplex. This is wrong. The auto-neg side of the link will still be able to figure out what speed the other side is running at (10mbps or 100mbps), but it has no way to know what duplex the other side is set to (since auto-neg is disabled on that side), and automatically selects <b>half-duplex</b>.
This creates a situation called "duplex-mismatch". The reason that "duplex mismatch" (when one side is set to full, the other side is set to half) causes problems is this: When an Ethernet device is set to "half-duplex", he sits and watches to see if the other side of the link starts sending data while he is sending his own data. If he detects that both sides of the link send at the same time, he'll consider a "collision" to have occurred. When this happens, he stops sending the data he was sending, queues it, and tries to send it again after a random, but very short period. He assumed that the other side of the link does the same thing.
Instead, the other side of the link (which is set full-duplex in our case), has no clue that a collision occurred, and continues to send his "chunk" (or "frame") of data. This chunk is ignored by the half-duplex device, and is effectively "lost". Also, since the half-duplex side stopped sending data in the middle of a "chunk", the full-duplex side will see this chunk as an error (usually a "CRC" or "framing" error). You can view number of input errors in OS X by running "netstat -i", or in Windows with "netstat -e".
This is really slow because when a chunk (frame) is lost in this way, the computer that was sending it has to rely on slow methods to realize that the data never got to the receiver, and that it needs to be retransmitted. This delay, in addition to the fact that the data has to be resent a second time (wasting bandwidth), brings CIFS (windows file sharing) to its knees - I've found that performance usually drops to about 50-300kBytes/s.
Also:
In theory, an Ethernet link can push 1.25MBytes/s, Fast ethernet can push 12.5MB/s, and gig - 125MB/s. However, depending on what protocol you're using (CIFS (Windows), AFP (Apple), NFS (Unix), FTP, etc), you can toss away 10-25% of that due to "overhead". Realistically I expect to see 10MB/s of data transfer with CIFS if everything's working right.
Make sure that for some reason <b>one</b> of the cards isn't coming up at 10Mb/s (note the "small b", which means "bits". Capital B means "bytes").
Watch out for CPU utilization, too. CIFS can take up a lot of CPU power, and that may be limiting some of your transfer speed. I don't know how well SAMBA in OS 10.1 does, performance-wise, though it's usually pretty efficient in other OSes. What are you using as file-sharing software on your Mac?
Unfortunately I don't know how to check what duplex you're running on Mac OS X, and I don't know how to change the settings.
Also, do you have another Win machine that doesn't run Win2k or WinXP that you can test with? There's a known problem that causes terrible performance problems between Win2k (and XP, since XP is basically 2000 with some removed/added features, and ugly color scheme) and WinNT that could be affecting the implementation of CIFS you're running on the Mac. (Basically it's due to the fact that raw SMB mode is no longer supported in Win2k). To get around this problem, you may want to try another implementation of CIFS (like SAMBAX like was suggested earlier), or:
Start Registry Editor on the PC (regedit.exe)
Find the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\
Add the Value:
Value Name: SizReqBuf
Data Type: DWORD Value
Radix: Decimal
Value: 65535
Or, like Steve said, the SMB implementation that comes with 10.1 may just suck, but I don't think that is your only problem.
Let's see... I guess that's it. Chances are that you're having one or more of the problems above.
Ian
