I ran into an interesting problem with my game PC over the weekend that I just solved yesterday.  I haven’t had much time for games lately, so it hasn’t been used in a while.  But I had a friend who wanted to transfer some tapes to CDs, and this system is the one that’s connected to the tape deck.  So I fired it up to make sure it had the latest Windows updates and to make sure that the audio capture stuff worked.  The system seemed to work fine, except for an exasperating hang whenever I tried to access a Samba share on my Linux system.  This was especially annoying since it was working fine the last time I used it.  Despite this problem, we were able to make CDs from the tapes.

What I eventually noticed is that this system refused to talk to the Linux system in general, either for Samba or for HTTP.  It would get about 1MB of data to flow before it would slow to a crawl (i.e. maybe a few bytes per second, if that).  This would cause Windows Explorer to hang if you were trying to browse a share via the GUI (sometimes it would come back with the message “the network name is longer available”).

It occurred to me that I hadn’t used the system since the network reorganization that took place during the FIOS TV saga and my struggle to get a wireless router that worked.  The main difference between then and now is that I had to plug everything into the D-Link DI-604 and that I now had a Belkin Pre-N router acting as an AP, where in the past I used a single unit (a Linksys WRT54G(S)).  The system could access the internet fine, which goes directly through the D-Link router.  It just couldn’t access the Linux system, which is across a wireless bridge. 

The system is built around an MSI K8N Neo2 Platinum, which has two gigabit ethernet controllers integrated into the motherboard.  One is part of the Nvidia nForce chipset, and the other is based on a Realtek chipset.  The ethernet wire was plugged into the Nvidia port.  I began to suspect, based on the symptoms, that there was something about the whole wireless bridged path that it didn’t like.  Some searching on Google turned up a few people who also had trouble getting a reliable connection using the Nvidia port.  Some were able to fix it by changing the driver settings so that the ethernet speed was locked, rather than autonegotiated (i.e. they’d set it to 100Mb/s Full Duplex).  Others got around it by switching to the Realtek port.  I first tried changing the ethernet speed setting, but as soon as I applied the setting the system rebooted (!).  So I went into the BIOS and disabled the Nvidia ethernet controller and re-enabled the Realtek one.  Sure enough, everything started working perfectly. 

So, I can only conclude that there’s something about the Nvidia controller or its driver that does not like crossing the bridge to the remote network.  Technically, a bridge is supposed to be transparent at the MAC layer, but it would introduce a bit more latency than if the connection were direct.  I didn’t investigate further to see if there were any driver settings that could be changed.  I was a bit afraid to mess around with it, given how badly the driver reacted.  It should be noted that this occurred with the latest driver available at the time, which was part of the nForce 3 Version 5.11 package.

Here’s how the systems are laid out.  The systems in question are “Game PC” (on the left towards the middle) and “dominion” (the Linux server).