• 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.

network seems slow...

I've got two computers on a 100BaseTX network using a Linksys 4 port switch/router. I seem to be getting transfer speeds of around 1.5 megabytes per second. That seems really slow to me. The computers are a PII@333 and a Celeron@850, so they ought to have enough speed to transfer faster, right? The NIC's are a Kingston and a SOHOware, which obviously aren't the top brands. Would busting out my Linksys and 3Com NICs make any difference? I seem to be getting 10BaseT speeds here... although it will burst past 2.5 MB/s, so I'm pretty sure everything is running at 100BaseTX. The ports on the switch light up red, which the Linksys manual says means they are connected at 100Mb/s.

Any thoughts?

BTW, I know the diff between MB/s and Mb/s, but 1.5 MB/s is only around 12 Mb/s... I should be getting much much faster transfers, right?
 
Just like Nothingman stated, your harddrive in the systems are most likely the bottleneck, especially if the harddrive in the PII 333 is around 3 years old.
 
hmm i also think its your harddisks in combination with your computer

i used to have a p166 with a 5400rpm hdd. on a 10mbit network, i could only send to the p166 at about 600k. i could receive from it at around 700k.
when i tried with another beafy computer....i was hitting over 1000k/s, so the p166 was definitely the bottle neck

 
The disk in the Celeron is a 7200 RPM 40GB Maxtor. The disk in the PII is a 5400 RPM 8GB Seagate. But even doing things like streaming video from the fast box to the other, where the slow drive is not really in use, the transfer can't keep steady above 1.5 MB/s. I've used the old drive in the same computer with the new one, and even on the same IDE channel, they could transfer at around 3 to 4 MB/s.

Also, when doing file transfers, neither computer's disk access LED stays lit all the time.

However, it may still be possible that the disks might be limiting it. I used to run the old disk in a P166 MMX, and the transfer speeds were the same. I thought I'd get a boost when I moved it to the PII, but there was no change. (The NIC and hard disk and cables were the only components that moved to the PII from the P166).
 
Make absolutely sure you cables are good (ie don't make them).

then check and make sure you are not getting any errors on the network cards. I'm not familiar with these cards but there should be some sort of control program that will have error counters like FCS, alignment, RUN, CRC. You want ZERO in a full duplex environment, if you don't have zeros something is awry. Also make sure your cards are set to auto-negotiate speed/duplex.

Could just be the slow processor.
 
Cables are good (I bought them 😉 ). I will check for lost packets and errors, etc.

But you think a PII 333 would be slow enough to limit the transfer speeds?
 
But you think a PII 333 would be slow enough to limit the transfer speeds?

God no, all the transfer speed problems I have are collision and disk speed related, mostly disk. I can pull >5MB/s from a K6-2 300 and the disks may still be an issue cause they're only IDE.
 
The cards don't come with any software other than their drivers. One thing I will try is the DSLReports tests on both computers, but does anyone know of any programs that can test the connection between two computers of your choosing?

Would running Netstat on the Win2000 box give me any clues?
 
DSLReports packet testing thing didn't work cause my IP isn't pingable (on a router). I can ping between the two computers using IP and NetBIOS names with no latency and no packet loss (although thats only 4 packets per execution).
 


<< are there any programs that can test the speed between two computers without using the disks? >>



Yes. Qcheck from netiq, (formarly ganymede) will allow you to test throughput without the disk subsystem bottlenecks.

You are on the right track. Report your results.

Regards;

Doug
 
Hum, just another thought... Are you using TCP/IP? That protocol is pretty heavy, and ends up consuming alot of your computing power. I remember many many years ago we were doing tests on a couple of P166s (when they were the hottest things around) with 3C905s, and 100BaseTx, and couldn't transfer more than 800 kbytes/s with close to 100% cpu utilization while using TCP/IP. But, in UDP, we had about 5.5 mbytes/s. Would anybody with more up-to-date knowledge care to comment? Could be worth trying some other protocol to see what happens...
 


<< Hum, just another thought... Are you using TCP/IP? That protocol is pretty heavy, and ends up consuming alot of your computing power. I remember many many years ago we were doing tests on a couple of P166s (when they were the hottest things around) with 3C905s, and 100BaseTx, and couldn't transfer more than 800 kbytes/s with close to 100% cpu utilization while using TCP/IP. But, in UDP, we had about 5.5 mbytes/s. Would anybody with more up-to-date knowledge care to comment? Could be worth trying some other protocol to see what happens... >>



I have NetBUEI on both machines, but I'm pretty sure it's been using TCP/IP for the file sharing.
 
gonna give QCheck a try as soon as I find it.
edit: found it and downloading...

edit:

OK, I ran it. The response time, using the maximum data size, and 10 tries, averaged at 1 ms.
The network throughput, using the maximun data size, seems to hover around 93 Mb/s. So the computers can transfer nice and fast.


So it looks like it just might be the disks. Or perhaps the processor overhead needed to run the disks and network at max capacity (plus the normal stuff) could be putting the squeeze on the PII...
The thing I did to try it out without using the disks was play a DVD .vob file over the network. The processing power needed to decode the .vob could have been the bottleneck.
 
Back
Top