Network transfer slow in X but not in 9
 

We have been having issues connecting to our file servers (NT and Snap) since upgrading to OSX (10.2.6). When connecting to any server using AppleTalk the transfer speed is extremely slow. But if I boot into OS9 the transfer speed goes back to normal. My IS department knows nothing of Macs so they continually blame the OSX. I need to use AppleTalk so the resource forks stay intact. One note I can copy to the server much faster than I can copy from. Any ideas would be extremely appreciated.

hmmm...

check the network settings for the Mac.

Open up terminal:-

ifconfig


en0 is the ethernet card...just check that you are connected as 100:FULL duplex..

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:fe77:62ec%en0 prefixlen 64 scopeid 0x4
inet 192.168.55.129 netmask 0xffffffe0 broadcast 192.168.55.159
ether 00:03:93:77:62:ec
media: autoselect (100baseTX <full-duplex>) status: active


This is what mine looks like... you can see the media is autoselect (100baseTX and full-duplex).. this is good..

Check yours and make sure you have the same.

Cheers,
--Zed :cool:

I am not too familiar with the terminal. But here is what I got:

[Dave-Knights-Computer:~] davek% ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:fe82:2086%en0 prefixlen 64 scopeid 0x4
inet 192.139.223.198 netmask 0xffff0000 broadcast 192.139.255.255
ether 00:03:93:82:20:86
media: autoselect (100baseTX <half-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <half-duplex,hw-loopback> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100baseTX <half-duplex,hw-loopback> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex> 1000baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex,flow-control> 1000baseTX <full-duplex,flow-control,hw-loopback>
[Dave-Knights-Computer:~] davek%


I hope you know what it means.

Thanks
Dave

yep that's what I needed...


FROM you config:

media: autoselect (100baseTX <half-duplex> ) status: active

This means that you are only connecting at half-duplex... this is why your system is going slowly..

You have two choices..

If you are connecting via a managed switch/hub.. you can ask the network people to set your connection to 100:FULL

or

You can make the setting on your Mac and the Switch should (will) make the change automatically..

I'm sorry but I can't remember how to set this for the mac atm... I'll have to get back to you on it.. or maybe someone else in the forum

Cheers,

---Zed :cool:

It is

sudo ifconfig en0 media 100baseTX mediaopt full-duplex

OK I did that and now it looks like:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:fe82:2086%en0 prefixlen 64 scopeid 0x4
inet 192.139.223.198 netmask 0xffff0000 broadcast 192.139.255.255
ether 00:03:93:82:20:86
media: 100baseTX <full-duplex> status: active


And that did nothing to improve my speed. In fact it slowed it more.

Any other thoughts?

Thanks...

I was away from my Mac and could not man the command...

Cheers,
--Zed :cool:

Really??? that surprises me...

how long after doing the change did you wait?

It can take some time for the switch at the other end to update it's self..

try your testing again... you might need to disconnect from the fileserver and reconnect too..

Cheers,
--Zed :cool:

I tried a full restart. With no luck:confused:

Restart will not help you..

the setting that we suggested you make will not last through reboots...

you'll need to make the setting again..

Cheers,
--Zed :cool:

I checked my settings and I am still at 100/FULL and I still have the slow transfer speed? Really slow. Slower than the orig settings.

What software do you have running?


Have you set up a firewall on the Mac?

how much memory on this Mac do you have?

What version of Mac OS X are you running?

Cheers,
--Zed :cool:

What software do you have running? Quark/Photoshop/Suitcase


Have you set up a firewall on the Mac? No

how much memory on this Mac do you have? 768Mg

What version of Mac OS X are you running? 10.2.6

And it applies to the 5 macs that are currently running X in our department.

Try transferring a file between two mac os X systems..

Both of which have to 100:FULL set..

see how long that takes over appletalk..

btw what is the server that you are trying to send to? is it a windows system or another Mac? and does it have 100:FULL set?

Cheers,
--Zed :cool:

Here is what my IS department gave me as far as network info.

The snap server is a Snap Server 4100, it is hooked up to a Cisco 2924XL
switch, it is set to Auto Negotiate. That switch is connected via
Gigabit Fiber to another Cisco 2924XL switch where your Mac is
connected. Your switch port is set to Auto Negotiate as well.

Mac to Mac tranfer worked good.

Do you think it could be the switch settings?

Set all to full?

Perhaps a definition of half-duplex and full-duplex is necessary here. Go to this address: http://searchnetworking.techtarget.c...212221,00.html. Now maybe the problem lies in machines at different duplex communicating. According to the reference, half-duplex and full-duplex are both bidirectional. But full-duplex can send and recieve data at the same time, while half-duplex cannot. So if the machine at half-duplex is sending data to the machine at full-duplex, and all of a sudden, the full-duplex machine decides to send data to the half-duplexed machine, then ( I am guessing ) maybe the half-duplexed machine will not recieve those packets. Causing the other computer to have to resend those packets resulting in latency. I don't know if this is right or not. But it may help explain what is going on. Let me ask you, try communicating between two macs. First set both at full-duplex, then set only one of them at full-duplex. Then see if there is a difference overall. As well, many things other than this may be affecting the connection. For one thing, the type of protocol used to communicate.
AtomicTuesday

That is correct. To be accurate, the half-duplex machine's MAC will declare a collision and back off.
It may decide to retransmit the interrupted frame if the false collision occurs within the first 64 bytes of the frame (I'm ignoring the Start Frame Delimiter and Preamble.)
If the 'collision' occurs after that point, the MAC will interpret it as a late collision and drop the frame with no attempt to retransmit.
When a frame is dropped because of a late collision, the upper layers of the stack have to work out the necessity of a retransmission for themselves. This will take on the order of seconds, as opposed to the microsecond time frame that the Ethernet MAC takes. A duplex mismatch is a killer.
Brief reminder: never force full duplex. Let autonegotiation do its job. To do otherwise is to guarantee that you've got a duplex mismatch in your future.

Breen

Thanks for the reenforcement breen. The truth is that knight was having problems with speed even before the duplex issue was brought forward. If I had to guess, I would say this problem is due to the type of protocol used to transfer the files. The way that files are sent, and the length and type of messages, (and thus packets), that are sent influence overall speed. I have an SMC router at home which network two computers. When I would transfer a whole directory from one to the other, it would take longer than sending a single file of the same size. The theory I have is the following. When sending a directory, packets need to be sent to confirm that each file has finished downloading. As well packets need to be sent to start the download of the remaining files. As well, packets which contain the listing of the directory need to be sent to the downloading machine so that it decides which one to ask for next. The procedure used in this varies from protocol to protocol. Whereas when sending a single file only a very small amount of packets need to be sent on top of actual file data. Now by how much this affects speed I cannot really say, but I can say that individual file downloads were much faster than directory downloads. You should test this, and see if there is a speed difference.
AtomicTuesday

Is this AFP over AppleTalk or AFP over IP? It could be the differenct between the two multitasking implementations between OS X and OS 9. I have seen similar performance drops between OS versions going to my SAN. When I look at the SAN's performance meeters, OS X writs in spurts wheras OS 9 will stream the write faster due to it only being focused on the one task.

I'm having the same problem at my company on 12 macs. see thread 'Really Slow Network Connection From Nt Server' in Sytem. I am starting to see alot of threads reagrding slow network speeds to and from NT servers. the problem definately arose at our place after we installed a security update or 10.2.8. I cannot determine which as both were done at the same time. We have one machine that does not have the problem but i cannot see any differences on the configuration as to why? I have spoke to Apple but they deny any problem. HELP PLEASE????

Just to add from my last reply. Below is the text when running IFCONFIG from the terminal window. One Mac is fine and one really slow. I can see differences but do not how to change or if I should change these settings on the slow machine. Any help would be greatly appriciated.

WORKS FINE
Last login: Tue Feb 3 08:22:05 on console
Welcome to Darwin!
[Mike-Firths-Computer:~] mikefirth% ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::20a:95ff:fe9f:53a6%en0 prefixlen 64 scopeid 0x4
inet 10.0.0.229 netmask 0xffffff00 broadcast 10.0.0.255
ether 00:0a:95:9f:53:a6
media: autoselect (100baseTX <full-duplex>) status: active
[Mike-Firths-Computer:~] mikefirth% opback> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex> 1000baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex,flow-control> 1000baseTX <full-duplex,flow-control,hw-loopback>
[Mike-Firths-Computer:~] mikefirth%

VERY SLOW
Last login: Tue Feb 3 11:35:27 on console
Welcome to Darwin!
[Stuart-Osbornes-Computer:~] stuartos% ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::203:93ff:fe68:d37a%en0 prefixlen 64 scopeid 0x4
inet 10.0.0.243 netmask 0xffffff00 broadcast 10.0.0.255
ether 00:03:93:68:d3:7a
media: autoselect (100baseTX <full-duplex>) status: active
[Stuart-Osbornes-Computer:~] stuartos% f-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex> 1000baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex,flow-control> 1000baseTX <full-duplex,flow-control,hw-loopback>
[Stuart-Osbornes-Computer:~] stuartos%

thanks

Just a thought for people having slow network problems....what Mac are you using? If the Mac is not that new then the limiting factor could be the speed of the hard drive coupled with OSX virtual memory demands! How long does a duplicate take in OS9 and then OSX?

Just my two bits worth... :rolleyes:

Just an idea...

Ask the IT dept. to check to see what the port settings are on the switch. I had to do this on a couple of computers (mac and PC) that had issues getting the autonegotiation correct. The switch was set at one thing and the computer was another. It resulted in extremely poor speeds on network transfers.

So make sure that the switch and computer settings are the same.

- Aaron