SLOW Connection between Server and Mac Clients

[mmw]

 

I'm running Retrospect Workgroup 6.0.193 on Server 10.3.3. All of a sudden the Mac clients (6.0.108) are backing-up SO slowly, connection speed is around 1.7 MB/minute. A couple times I was no longer see the Mac clients on the network. Rebooting the sever and the clients makes them visible again but so far nothing has fixed the connection speed problem.

 

The Windows clients are being backed-up as expected, normal speeds.

 

Help please!

[natew]

Hi

 

Did you perform any updates or run any optimization software on these machines? To determine if the problem is client side or server side, try installing Retrospect on another mac and running a test backup to a file backup set.

 

Thanks

Nate

[nemoinis]

I have the same problem: 2 or 2.2 MB/min performance from Mac clients (to a Mac host), where I used to get many times that before Retrospect 6. Install from scratch on a virgin client (no other third-party software installed, just Apple stuff) makes no difference. Backups from Windows client works at full speed.

[natew]

Hi

 

I fought with my powerbook for a long time until I figured out that the network driver could not handle full duplex 100Mb. Try slowing the speed of you client network adapter using cocktail and see if you have better results. I found that scanning worked fine and compares were fast but backups just crawled. Is that what is happening for you?

 

Thanks

Nate

[Sheppard]

Quote:

---

I fought with my powerbook for a long time until I figured out that the network driver could not handle full duplex 100Mb. Try slowing the speed of you client network adapter using cocktail and see if you have better results.

 

---

 

Agreed. I have a PowerBook G3/400 Bronze (Lombard) that can do things like Finder copies fine on 100BT FD but is very slow with Retrospect. When I move it to a 10BT HD hub, the backup is actually much faster, close to the network maximum.

 

I don't like it but it's a fact of life with my machine. I don't think this is a Retrospect problem but rather an OS X networking problem with my computer.

[cclauset]

How can this be an OS X networking problem when a Finder copy across the network is considerably faster than using Retrospect Client? I have an iMac (rev D; tray-load) using Retrospect Client 6.0.108 connected to a PowerBook G4 (DVI) running Retrospect Desktop 6.0.193 using either via a direct cross-over or through a 10/100 Switch (Netgear and/or Linksys) and consisently get 4.4 MB/min throughput with Retrospect Client. A Finder copy to a mounted afp volume is more than 2x faster than Retrospect Client! So who's at fault?

[Sheppard]

Quote:

---

How can this be an OS X networking problem when a Finder copy across the network is considerably faster than using Retrospect Client?

 

---

 

That's a very good question. Back in the 5.0 days when it was first released, I had a long posting about the very slow backup via the released R. client even though both Finder and beta R. clients were much faster. Perhaps it has something to do with the packet size used by Retrospect and/or the speed at which packets are sent. I'm guessing.

 

Amazingly, the long thread is still on the forum at:

http://forums.dantz.com/ubbthreads/showflat.php?Cat=0&Board=Desktopworkgrupx&Number=6868&Forum=All_Forums&Words=&Searchpage=0&Limit=25&Main=3609&Search=true&where=bodysub&Name=1525&daterange=1&newerval=3&newertype=y&olderval=&oldertype=&bodyprev=#Post6868

 

Anyway, I've just accepted the fact that things are the way they are. I do that a lot with Retrospect.

[cclauset]

When I said that Finder copies were 2x faster than Retrospect Client, I really meant to say was that Finder copes are 42x faster (10.5 MB/sec Finder copy; 4.4 MB/min Retrospect client)... big difference. And slow to the point to make it not feasible (250 MB/hour via Retrospect client!). Has anyone had experience with BRU by Tolis Group? This looks like it's the only alternative.

[cclauset]

more information... the amazing slow down <u>only</u> occurs during the copy phase of the backup. When Retrospect is scanning the client volume for files/folders/icons/permissions, or when it is verifying the data, the throughput is a much more respectable ~115MB/min rather than the abysmal ~4MB/min. I can't fathom that this is a problem with the OS X networking stack, or the fault of the hardware.

 

For a comparison, I rebooted the iMac back into Mac OS 9.2.2, installed the Retro 5.1 client and then did a test backup. A reasonable ~62MB/min over a 600 GB test run.

 

I also installed IPNetMonitorX on both the client (rebooted back into 10.3.3) and the server end and noticed that during the copies that the client side is having to retransmit way too many segments (1499 segments during a 48 MB test run).

 

I just can not accept the fact that things are the way they are. Something's just not right with the Retrospect Client.

[natew]

Hi

 

I ran into the exact same trouble you did. Indeed scans and compares worked fine but copies failed miserably. I know the hardware is good because it works in OS9 (just like your case). I know the client works the same on every machine so the only variable left to consider in my case was the network driver.

 

The client itself is really basic and uses standard TCP/IP. It operates at the application layer so it isn't even aware of link speed per se. That should be handled by the OS and network drivers. The fact that lowering the speed of the connection makes everything work normally tells me it is a network problem.

 

Another thing is that I was unable to use cocktail or any other network script adjustments to make changes to the network settings in OSX. That tells me the Nic works in OSX but not in a standard way.

 

I can get 60MB/ Min backup on 10 Mb connections. Agreed it stinks but thats life with my Bronze G3.

 

Nate

[cclauset]

I just can't see how it's a networking driver issue since other data transfers (via the Finder, etc.) operate at normal speeds. Nor can I see how it's a networking driver issue if the scanning for files/folders/icons/permissions is also at normal speeds.

 

Granted, I understand that Apple has used different NICs in different Macs which means that the OS X network driver(s) vary depending on the underlying hardware. But what I find unacceptable is that Dantz doesn't/hasn't provided a technote or a workaround on this. The hardware is definitely capable of handling the load, and it's only under a specific condition (i.e., copying data with Retrospect Client 6 under Mac OS X) that this occurs, so it seems reasonable to me that Dantz should provide a fix.

[cclauset]

Just on a lark I tried reversing the situation. Using Retrospect 6 Desktop on the iMac rev D (tray load) and Retrospect 6 Client on the PowerBook G4 (DVI). Totally different experience. I do get some retransmit errors, but not during the copying (avg. ~ 82.1 MB/min, peak ~108 MB/min), this time it is during the initial communication when setting up the client and/or attempting to define a subvolume on the client side (486 retransmit segments during setup and two aborted attempts to define a subvolume). No compression, no link encryption, and no slowness during the actual immediate backup.

 

So does this change the opinion that it's the Mac OS X network stack that is the root of the problem?

[Sheppard]

Quote:

---

Just on a lark I tried reversing the situation... So does this change the opinion that it's the Mac OS X network stack that is the root of the problem?

 

---

 

I reread the thread on this same problem that I started for R 5.0 back on 2002-04-04 (over 2 years ago with no solution so I'm not expecting one now). I'm still convinced it's an X stack problem but R may be sending data in such a way as to trigger that fault.

 

My earlier report is too long even to list highlights here. If it's not an X stack or NIC problem then why does it dramatically improve when using 10BT HD instead of 100BT FD? Retrospect should be totally oblivious to that fact. Like you found, the problem is not symmetric in that I can restore much, much faster than I can backup from my Lombard PB while using 100BT FD or even HD.

 

The usual solution put forth for these symptoms is that it's a HD/FD/auto negotiation problem and to force the client into whatever mode works best. Well, I set the Network preferences to every combination without success.

 

I'm also seeing a high retransmit packet count, but retransmits are taken care of totally in the protocol stack. R has nothing to do with that. Is R sending massive amounts of data to the stack keeping it busy buffering data instead of sending it? I have no idea. Dantz knows what they're doing different between the 5.0 beta 2 and the release verions of 5.0 in how they talk to TCP but they haven't "fixed" it. Looks like the 6.0 client has the same problem.

 

Dantz/Apple need to answer the question as to why Finder copies are at 3-6 MB/second while Retrospect backups are at 3-6 MB/minute all else being equal. Until that question is answered, we won't see a fix, and since it's been over two years since this was reported, I'm not holding my breath. I am using 10BT because I can only bang my head against the wall for so long.

[cclauset]

I'm pretty confident that it is not a X stack problem because I can do a Finder copy at 3-6 MB/sec at the same time that Retrospect 6 Client is crawling along at 3-6 MB/min. If it were a stack problem then I shouldn't be able to do that. And if the Finder is able to workaround whatever stack problem there is, then should Dantz be able to work around it too?

 

Just to be thorough, here is my exact configuration again:

 

iMac G3/333MHz (rev. D, tray-load), 320 MB RAM, Mac OS X 10.3.3, Retrospect Client 6.0.108

- connected via Cat5e to

Netgear MR814v2 802.11b wireless router (10/100BaseT)

- connected via Cat5e to

PowerBook G4/667MHz (DVI), 1 GB RAM, Mac OS X 10.3.3, Retrospect Desktop 6.0.193

 

But just for kicks I'm going to borrow a 10BaseT hub and insert it inbetween the iMac and the Netgear router to test to see how that changes things. I'm definitely not a satisfied customer at the moment...

[Sheppard]

Quote:

---

I'm pretty confident that it is not a X stack problem because I can do a Finder copy at 3-6 MB/sec at the same time that Retrospect 6 Client is crawling along at 3-6 MB/min. If it were a stack problem then I shouldn't be able to do that.

 

---

 

Not necessarily. It's possible that Retrospect is using the stack in a different way than the Finder, perhaps through the choice of some options or the rate at which it makes stack calls or who knows what. Well, actually, Dantz knows for sure because they did have a much faster client with 5.0 beta 2 and then the speed went in the dumper with the 5.0 release and is still that way.

 

Quote:

---

And if the Finder is able to workaround whatever stack problem there is, then should Dantz be able to work around it too?

 

---

That's the bottom line. We both know what our hardware is capable of doing with the Finder and the Retrospect client is almost two orders of magnitude slower, so the onus is on Dantz to investigate and come up with a solution. I simply don't believe that's going to happen because I reported this same problem over two years ago and still no fix.

[cclauset]

I think that I've spent enough time on this thread, but just to finish out...

 

I installed a 10BaseT hub between the iMac and the Netgear router and, low and behold, the copy performance jumped from 3.6 MB/min to 39 MB/min--a 10x performance increase with a 10x slower network connection--and there was negligible difference between the 10BaseT and 100BaseT for the compare (both averaged ~100 MB/min).

 

Comparing this to when I used the iMac as the Retrospect Server and the PowerBook G4 as the Retrospect Client (both connected via 100BaseT) the copy performance for the 10BaseT was 1/2 as fast, but compare was the same (~81 MB/min copy and ~100 MB/min compare).

 

So the 10BaseT hub stays until Dantz can fix the Retrospect Client, or maybe until I switch to something else...

[mmw]

 

to clarify, the terrible performance is occuring during every part of the back-up between the server and the Macs; scanning, copying & verifying. this sucks!! Hello, anyone at Dantz listening??

 

The connection between the server and the Windows machines running XP is usually around 160 MB/min versus 3 MB/min for the Macs. THIS IS AWFUL!!

[Sheppard]

I'm running my Lombard (PowerBook G3 400 Bronze) now on 10.3.4 with a FD 100BT switch and it maxes out at around 50 MB/min, but with stops and starts so you know it could do better. It's much better than the 4 I was getting. I'm keeping my fingers crossed with the latest performance.

 

I've tried so many things and I can't pin down what the real problem is (why sometimes it's OK and other times bad). I get multi-megabyte per second file share copy speeds. I know OS X is more of a pig than OS 9 so I would expect some slowdown, but my wife's OS 9.2.2 PowerBook G3 can be backed up at up to 160 MB/min on the same switch to the same backup server.

 

FWIW, I'm still using R 5.0 on a G4/450 with 10.3.3 after R 6.0 had an unsolvable conflict with my AIT, Adaptec SCSI card and DVD-RAM drive.

[jbgurman]

I have a very similar problem:

 

Configuration: Retrospect Workgroup 6.0.178, Mac OS 10.3.4 on a Mirrored Drive Doors dual 1.0 GHz G4

 

Issue: Since the upgrade to 10.3.4 and the 2004-06-07 security update, both scheduled and interactive Retrospect sessions backing up more than ~ 20 - 30 Mbyte over the LAN slow to a crawl. Other than the OS updates, nothing has changed since last week, when (as for the last several years), typical backup rates ranged from 15 Mbyte/minute for AirPort connected clients to 230 Mbyte/minute for local drives. All of these figures slow to << 1 Mbyte/minute now, and the Activity MOnitor frequently shows Retrospect to be "hung." Indeed, it appears difficult or impossible to "get Retrospect's attention" via Pause or Stop buttons, and most frequently, the application can only be stopped by Force Quitting RetroRun, RetroRunSL, and the Retrospect Application itself via the Activity Monitor.

 

Has anyone else seen behavior of this sort in Retrospect since the latest OS updates?