• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Slow LAN traffic on Foxconn 6150K8MA-8EKRS (Vista)

Basilisk

Senior member
Built a computer awhile ago for a friend: Foxconn 6150K8MA-8EKRS, 3800+ [X1], 2GB, Vista. I occasionally use it, and it''s always seemed slow in web accessing (Comcast) -- which I don't recall on the previous computer I'd built for them.

Is this a "known problem" of the chipset (6150+430), or a one-off board problem?

I've never had to diagnose a "slow LAN" before, so if there are any standard fixes/articles I should know of, I'd appreciate the pointers.


I'm also unable to get the DVI port to work with the 22"WS dual-input monitor -- so it's using VGA for the moment. Cable switching hasn't helped, and I think I tried another monitor a month ago. 'Don't see any BIOS switches that would interfere. Sigh.


Well, I have a back-up board, though I loathe to totally pull a system apart for the test. Maybe I can find an old PCI LAN card to try. And I can pop in a PCIe card to test the video.... What a bother!
 
It has the Marvell 88E1115 chip -- Which doesn't appear on the Marvell site as far as I can search! The suffix 1115 is closest to the Alaska single-port code (1111) and unlike the Yukon (80xx).

The latest drivers Foxconn's posted for these boards have release dates > 2 yrs ago. I believe I loaded them... but they are, of course, pre-Vista... if that means anything.

The nVidia Network driver is 65.7.4.0

Re-downloading those drivers, just now, I'm getting 20KB/s. Yuck. Could be their site, however. In general, HTML pages fill languidly... feels more like DSL's sluggishness than cable's throughput.

If there's a better driver source than Foxconn, I'd like to know!

Thanks....
 
I think I saw some recent Vista drivers on the Marvell website, but they were for the Yukon, no Alaska drivers at all. But I also saw this on the "PC Connectivity" page that describes their networking products: "A single driver for the complete product family, enabling quick adoption and easy implementation of the latest technologies."

Either way, it was a really small and quick download for me, even with DSL, so it might be worth a shot.
 
I've downloaded the s/w I found on Marvell -- I think it's what you're referring to.

But I haven't installed it: as I downloaded it, it the throughput was ~600KB/sec! Almost 30x what I often experience. WTF!?

'Think I'll wait for a slow-download period and try some experiments, like turning off the Wireless side of the router -- thus taking any insanity elsewhere in the house out of the equation.
 
Those are some pretty impressive drivers Marvell has cooked up...you don't even need to install them to get a speed boost 😛.

From hearing that, I think it's more likely there's someone in that household that has a habit of downloading a whole lot of data (what that data might be, I'll leave to your imagination 😉. Or even a neighbor hijacking the link if there's no encryption.
 
Finally got back to the problem, and have a probable answer:
- When I encountered the problem again, this morning, I shutdown the wireless router, and the problem ended.
- 'Saw one of the boys, shortly thereafter, and he said the other runs (s)Limewire -- "but only on rcommand, not at boot."
- But the culprit almost never shuts his system down... so once it's started, the problem remains for days and days.

Haven't been able to locate the other boy to verify the details... but yet another reason to avoid sLimewire. I've refused to let either of the boys load that merde on -my- systems, but they've now got their own computer and each has run into problems with it. I presume it's saturating the Comcast up-link so that other computers' requests are being delayed. Another clue in that direction: one of the throughput tests I'd run the other day failed to complete its upload phase, and the download phase was running at dial-up speeds.
 
Back
Top