Jump to content

Very slow backup of X client


Recommended Posts

A few days ago I posted some comments about my experience with extremely slow performance of one OS X client. A quick recap - I have R5 running on a G3 B&W running 9.2.2. My OS 9 and Windows clients all perform as expected. Two OS X clients also perform reasonably well (approx. 40 MB/min) but one OS X client is getting less than 1 MB/min. The interesting thing is that the two OS X clients that work are 10BaseT and the one that doesn't is 100BaseT. The Retrospect machine is also 100BaseT.

 

 

 

Yesterday I finally made time to do some testing. I switched the 100BaseT client to 10BaseT and instantly got the same 40 MB/min as my other two OS X machines. We happen to have a networking consultant/guru working for us right now helping with other networking issues so I discussed my problem with him. By the way, he is knowledgeable of virtually all platforms. His answer was quite simple, although the technical explanation certainly was not. The client, a G4 w/OS X, is just too fast on a 100BaseT NIC for the OS 9 machine. The culprit is the poor performance of OS 9 networking, causing major retransmission problems (which other posters already mentioned, I believe), effectively grinding communication to a virtual halt. His solution - just move Retrospect to OS X and the much superior BSD networking should fix the problem.

 

 

 

Fortunately, I had OS X installed and ready to go. All I had to do was reboot and launch Retrospect. Well, let me tell you, the difference was phenomenal!! With the OS X client machine back on 100BaseT, I am getting 240+ MB/min. I couldn't believe my eyes as I watched the progress bar just zip along, backing up about 8 GB of data in mere minutes, including the compare! I also tested a few other clients - OS X, OS 9, and Windows. All saw a significant performance improvement, especially the Windows machine which went from 30-40 MB/min to 150+. I believe that particular machine is also on 100BaseT.

 

 

 

I don't know that this is the solution for everyone's problems but it sure solved mine. And so easy to implement. Today I make the change permanent - unfortunately it appears I have to rebuild the client database in OS X which will take me an hour or so I figure. Small price to pay!

Link to comment
Share on other sites

Marsabo quoting networking guru: The client, a G4 w/OS X, is just too fast on a 100BaseT NIC for the OS 9 machine. The culprit is the poor performance of OS 9 networking, causing major retransmission problems (which other posters already mentioned, I believe), effectively grinding communication to a virtual halt. His solution - just move Retrospect to OS X and the much superior BSD networking should fix the problem.

 

 

 

I'm not a networking guru but that explanation doesn't hold up. TCP is designed to adapt to the relative speeds of each device based on dynamically adjusted round-trip timers, slow-start and congestion avoidance algorithms. I've tested systems in the lab where we deliberately throttled a receiving host down to 300 bits/second and TCP adjusted within 3 retransmissions and was quite happy to proceed at that rate without further retransmissions. When we removed the throttle, TCP ramped up to the maximum rate.

 

 

 

If that was not the case, you'd never be able to communcate between super servers and low-end computers, yet we do all the time just fine.

 

 

 

Moving Retrospect to X is not a solution, it's a workaround.

 

 

 

Fortunately, I had OS X installed and ready to go. All I had to do was reboot and launch Retrospect.

 

 

 

I don't know that this is the solution for everyone's problems but it sure solved mine.

 

 

 

Unfortunately, I can't move the server to X for reasons other than Retrospect. I don't think Dantz is really at fault in this problem because I suspect there is a problem with the PB G3 Bronze and its Ethernet implementation in such a way that the protocol stack(s) between 9 and X can't handle, but...

 

 

 

... I keep coming back to the fact that the Finder can copy at 450 MB/min, 100+ times faster than Retrospect, so Retrospect must be using TCP in a way that is different than the Finder. That's what I think Dantz needs to look at.

 

 

 

The PB G3 Bronze was not one of Apple's greatest laptops. Already I've had the CPU card replaced under a hidden Apple warranty (after wasting 40 hours with reinstalls and restores) because it would crash several times an hour running X, whereas 9 was fine. X doesn't support the video chip in the PB so the GUI is slow and I can't play DVDs. Combined with the Retrospect problem, I'm tempted to get a new Titanium, which is exactly what Steve wants me to do. Reward him for producing a defective product that's not properly supported by X by buying more hardware. The PB is less than 3 years old.

Link to comment
Share on other sites

Sheppard, I guess I should have made it clear that I was paraphrasing and interpreting (mostly), not quoting, what this networking expert told me. He's a real gearhead and he sort of lost me after the first few minutes so I may have gotten a lot of it twisted! He did talk about the legacy Mac OS's lack of multitasking and how that relates to networking deep in the OS (my words again), and of Apple's less than stellar implementation of TCP, about OS X's (as in Unix) much superior architecture and networking, etc, etc. Heck he even got off topic and started saying less than flattering things about Microsoft networking (that was worth a chuckle at least). I am technical but not anywhere near that level so it's a bit difficult for me to grasp everything he said, let alone repeat it, if you know what I mean! I will try to get him to explain it again, and again if need be, so that I can understand it better and therefore relay it more accurately. Anyway that will be awhile because I'm away for a couple of weeks.

 

 

 

What I do know is he wasn't guessing, or fishing for ideas when he told me to move to OS X. Maybe you had to be here to appreciate this, but armed with the facts, he didn't just think it would work, he knew it would work. Oh, and you weren't here for the "I told you so" either when I showed him the results! And by the way, I've known this guy for many years and have come to trust his knowledge and expertise so even if I don't understand or agree with him at first, I will always give him the benefit of the doubt. This time it really paid off.

 

 

 

Moving to OS X was not a workaround. This machine is a dedicated Retrospect server and moving to OS X was planned (I did mention this in my first post) - this was just the kick in the pants to get it done. It was virtually effortless, especially after I read the documentation and discovered that I could salvage my client database and scripts, unlike what I said in my previous post.

 

 

 

And I certainly didn't mean to imply that this was a cure-all for everyone faced with this problem. I suppose in my exuberance over finding such a simple solution (in my case) I may have left that impression. But it is food for thought perhaps for some of the other folks experiencing this problem. Or at the very least another clue for Dantz in trying to fix this problem.

 

 

 

 

Link to comment
Share on other sites

Try setting the Cisco switch port to "auto". There is a problem with Apples way of setting network options. Apple insist on "auto negotiation" while most others like "hard coding" the network speed and duplex mode. If the switch port is configured (hard coded) to "100Mbps full duplex" the mac tries to "auto negotiate" the speed and duplex, but gets no reply. It assumes the duplex is "half" (simplex) and sets the duplex to "half". (Speed is measured by electricity and becomes correct.) As the switch is set to "full" and the mac to "half" you get an inconsistency, and the network performance becomes weeeeery slow.... (Lots of networks collisions)

 

 

 

The workaround for this is to "please" the mac, and set the switch port to "auto". If the mac is directly connected to the switch you will get a "100 full" connection in both ends. If there is a hub between the mac and the switch, you will get a "100 half" connection (because hubs by nature can't communicate in full duplex).

 

 

 

By doing this you will se a speed increase, not only for backup, but for all other network activities.

 

 

 

PS: In mac Os 9 there was a "plug-in" you could put in the system folder to "hard code" the speed and duplex mode. As until now there is no way you can hard code this on Os X.

Link to comment
Share on other sites

Only the router is Cisco. The switches are Asante FriendlyNet unmanaged switches. They have no way to set the port to auto that I'm aware of. I'll check their website for documentation. Perhaps they are already "auto." I'm aware of the OS9 full duplex patch.

 

 

 

It seems my only solution is new network hardware? Not a bad solution by the way, except for the capital expenditure.

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

Another interesting tidbit. Printing to my Epson 800N, Ethernet connected printer, is dog-slow too. We're talking minutes per page with long gaps between the print head moving. It's connected to a 10BT hub which is uplinked to my 100BT switch that the X client is connected to.

 

 

 

When I moved my X client to this hub, the backup to the switch connected server was 10 times faster. So I decided to try printing while the client was connected to the hub. Well, whadda ya know! It prints normally now.

 

 

 

So here's another example of a program that is extremely slow to send data out of the client, just like Retrospect. Since Finder copies are lightning fast, what is it about Retrospect and the Epson driver that's different from the Finder? Hmm...

 

 

 

...Tom

Link to comment
Share on other sites

  • 2 months later...

I have just upgraded to R5 work group. I use a DP800 2HD, 1 for backup, 1.5 G ram. OS10.1.5

 

 

 

Clients; A Windows 98 over 100t network at average 100MB Min, a Powerbook Pismo, OS 10.1.5 768 ram over AirPort at average 40 MB Min, a PowerCenterPro 210 W/G3 466 processor 512 ram 10t to 100t network.

 

 

 

The PCP has 2 HD a 9gig IBM 7200 rpm and a Quantun Atlas 10K 36gig 2 partitions 50/50 in size, OS 9.1, PCI card is Adaptec 29160N. the 9gig drive will backup at 50MB min, the 36gig average 3MB min. Backups are to the 2nd HD on the DP800. The average backup directly to NS20 tape under R4 is 48Mb min and 28MB min in R5.

 

 

 

I tried using the 9gig as a startup disk and still get 3MB speeds. Tried the DP800 in OS9.2.2 with 3MB again. I setup a base OS 9.1 system with R5 client installed with 3MB speed, So the network appears to be OK. Only one drive is slow in the workgroup. both drives BU to tape at the same speed using the 10MB motherboard SCSI port. Both drives are on the same 29160N card. R5 is slower that R4 in OS9.1

 

 

 

I disconnected the 9gig and still 3MB min.

 

 

 

Is my 36 gig bad or failing? Or?

 

 

 

Thanks Chet

Link to comment
Share on other sites

  • 2 months later...

Hmm, wish I'd caught this thread sooner. =)

 

 

 

I had the same problem. It plagued an iMac on my network for a long time, and it was since fixed, returning the backup speed to its former glory. No software changes were made to the iMac (MacOS X 10.2) or the Mac running Retrospect (MacOS 9.1) in server mode. (A PowerBook and slot-load iMac do not have this problem; the problem iMac is a tray-load 333.)

 

 

 

To make a really long story short, it was a duplexing problem between the iMac and the network. The switch in use is a Cisco Catalyst. The iMac was able to receive traffic with no problem, but transmitting was horrible; a lot of CRC errors. As such, backup speeds were dismal. The same thing was evident with any kind of network related task, (like file copying over the network) but the problem was only present under MacOS X. Network performance booting up in 9.x was problem free.

 

 

 

Ultimately I locked the port speed/duplex in the Cisco switch to 10/Full to solve this problem. Any other combination of speed or duplex caused the massive amount of CRC errors (and poor performance) to return. A farm 10/100 hubs and 10Base-T only hubs were inserted into the network and they too caused the iMac to suffer the same problem, however, they lacked the diagnostic information available on the Cisco Catalyst.

 

 

 

My conclusion (opinion?) is that Apple wrote a really bad Ethernet driver for the BMac chipset present in the tray loading iMac 333. Unfortunately my solution doesn't leave much for those who don't have a switch that is capable of forcing the speed/duplex of a port.

 

 

 

(You may ask, "why not force duplex on the iMac side?" That'd be nice, but in Apple's wisdom, this function is not supported on the BMac chipset under MacOS X. There's a utility for 9.x, but that's not really any use since the problem was restricted to MacOS X while working fine under 9.x. There's a technote in their developer docs to this effect, search apple.com/developer/ .)

 

 

 

~Seth

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...