Very slow backup of X client

[Sheppard]

Greetings,

 

 

 

Anybody else seeing very slow backups of an X client?

 

 

 

My first backup of an X client using the released version of 5.0 on a 9.2 server is crawling along at 4 MB/min. Not much else is running on the X client. CPU Monitor hardly gets above 25%. Retrospect is in the foreground on the 9.2 machine. Destination is DVD-RAM. Previous backups using beta 2 showed 50-90 MB/min.

 

 

 

The released version has already backed up a 9.2 client over AirPort at 30 MB/min or better and a LAN iMac running 9.2 at twice that speed. In fact, backups of VirtualPC running on the X client are done at 9.2 MB/min (and you know how slow VPC is in X), so why is the native client running on the same machine (without VPC running) half the speed of VPC and 1/10th as fast as beta 2?

 

 

 

Further investigation with IPNetMonitor shows that scanning the X client runs at 240 KB/s until about 50K files when it slows dramatically to 50 KB/s for the last 5K files. The server has 40 MB of RAM assigned. When the backup starts there is a burst of speed for each file followed by the rest of the file crawling along with the odd burst here and there.

 

 

 

I've reinstalled the client and restarted the server. No joy.

 

 

 

...Tom

[Sheppard]

The backup finally finished at 2 AM so this morning I tried a restore. I selected a 146 MB file and it restored at over 130 MB/min!

 

 

 

Then I created a file backup and selected just this file, turned off s/w compression and tried to back it up again. Same problem as before. I get an average of 4-5 MB/min but using IPNetMonitor I see an average of 50-70 KB/s with peaks up to 490 KB/s.

 

 

 

Something on the X client is causing this very bursty behaviour while reading files with Retrospect, but not writing them. I can mount the X client's volume on the Retrospect server and use the Finder to copy this file from the X client to the Retrospect server at 450 MB/min! That's over 100 times faster using the Finder than using Retrospect.

 

 

 

Server is G4/450 running 9.2.2, client is PB G3/400 running 10.1.3, 100BT Full Duplex switch

 

Retrospect is running in the foreground with 40 MB allocated.

 

 

 

Speed Summary:

 

9.2 client iMac on LAN: 50-60 MB/min

 

9.2 client iMac on AirPort: 20-30 MB/min

 

X client Finder copy: 450 MB/min

 

X client running beta 2: 50-90 MB/min

 

X client with release 5.0: 4 MB/min

 

 

 

That sure looks like a problem with the 5.0 X client to me.

[SteveW928]

I wonder if its something to do with the Powerbook?

 

 

 

We're running Retrospect v5 on a Beige G3 and backing up several different OSX clients. We're getting about 200 to 300 MB/min. Our main problem is that they randomly are not visible on the network to the backup system... and then we get no backup at all... but the performance for us seems on par with v4.3 so far.

 

 

 

-Steve

 

swilkinson@macys.com

 

 

[Sheppard]

The beta 2 version ran fine so unless there has been a change in the client that is PowerBook specific, I don't think this is the problem.

 

 

 

I did install some utilities that required restarts. Somewhere along the line, the problem was temporarily fixed as the next backup ran at 40 MB/min, about what I saw with the beta. However, the subsequent two backups were back down to 4 MB/min again.

[Sheppard]

Is any progress being made on this problem? I'm facing a 9.5 GB recycle backup within a week or two, depending upon when the last DVD-RAM disk gets full, and I estimate it will take about 40(!) hours non-stop at 4 MB/min to complete.

 

 

 

If you can't get a fix by then, please post a time extension to the public beta so that I can get my 40+ MB/min backup back until you can fix the release client.

 

 

 

Thanks.

[CallMeDave]

Somewhere along the line, the problem was temporarily fixed as the next backup ran at 40 MB/min, about what I saw with the beta. However, the subsequent two backups were back down to 4 MB/min again.

 

 

 

 

 

Is any progress being made on this problem?

 

:snip:

 

If you can't get a fix by then, please post a time extension to the public beta so that I can get my 40+ MB/min backup back until you can fix the release client.

 

 

 

 

 

What difference a switch makes!

 

 

 

We just installed real 100BaseT switches, with all new Cat5e cables to the desktop.

 

 

 

My OS 9.2 iMac running Retrospect 5.0.205 _screams_ through backups of my G4/733 running Mac OS X 10.1.4 with the Retropect Client 5.0.528.

 

 

 

It doesn't slow down at all. Not at all.

 

 

 

And your's worked "somewhere along the line." What line is this? Did Dantz fix it for you, and then un-fix it? Or perhaps, there's something in your configuration that is slowing your backups down?

 

 

 

I did install some utilities that required restarts

 

 

 

Ah, you did? Perhaps you'd care to share what these might be?

[Sheppard]

"What difference a switch makes!"

 

I'm already running a 100BT full duplex switch and can copy the same test file at 450 MB/min using the Finder, so it's not a network problem.

 

 

 

"And your's worked "somewhere along the line." What line is this?"

 

It's only worked once in the daily backups I've done since R5 was released. Not a stellar record.

 

 

 

"Did Dantz fix it for you, and then un-fix it?"

 

Dantz has not fixed it. They requested some additional information and that's the last I've heard from them. The backup ran properly once shortly after a restart. I've done other restarts since then without any improvement.

 

 

 

"Or perhaps, there's something in your configuration that is slowing your backups down?"

 

It must be a combination of configuration, possibly h/w, and the release client. Remember, the beta2 client worked fine, I ran the uninstaller, then the R5 installer and immediately throughput is down the toilet. Dantz changed something between beta2 and release.

 

 

 

Tom: "I did install some utilities that required restarts"

 

 

 

Ah, you did? Perhaps you'd care to share what these might be?"

 

The problem existed before and after the installs so I think it had something to do with the reset, not the installs themselves, that momentarily corrected the problem. Anyway, I installed the latest Keyspan and Wacom tablet drivers.

 

 

 

I guess the point I'm trying to make is that the beta worked fine, the first backup after the R5 install is unusably slow, only 1 of 35 or so backups has been normal, Finder copies are lightning fast, R5 restores are fast and, this is the most perplexing, Virtual PC can be backed up faster than the native X client. All fingers seem to be pointing to the X client. Since there's only two people reporting this kind of performance hit, I suppose it must have something to do with our s/w or h/w. So Dantz has changed something between beta and release that now interacts with something. I'd appreciate a hint from Dantz as to where I should start looking.

 

 

 

Since I expect Dantz is tied up with the numerous other serious problems reported by many more people, I really don't expect much attention. I guess my last resort prior to the recycle backup is to do a clean install of X and R and try again. I've been trying to avoid that since you know what an enormous time consuming pain in the butt that is compared to OS 9 installs and restores.

 

 

 

If that fails, I'll have to get a refund since it is unreasonable to expect to take 40 hours to backup a single computer.

 

 

 

Once again Dantz, I join my voice with the others and ask that you update the beta's expiration date and give us a workaround until these problems are finally fixed. Is that really too much to ask?

[marsabo]

I wouldn't recommend that you go to all the trouble of re-installing OS X. I say this because I tried this already and it did not help - at all!

 

 

 

I'm having the same slow backup problem with one OS X client (mine). I have two other OS X clients and have no problems with them. As a matter of fact, they are only 10BaseT, I'm 100BaseT and I'm getting less than 1 MB/minute! Absolutely unacceptable. For now, I backup my important stuff to CD-RW. All three OS X clients are G4/867 but mine has the internal modem and the DVD burner, the other two have no modem and CDRW only. I can't see that this would make a difference. I'm running Retrospect 5 on a G3 B&W w/OS 9.2.2 (10.1.4 is installed and ready to go - just haven't had time). I also backup 5 OS 9 clients and 40+ Windows NT/2000 clients without any problems.

 

 

 

I still have a few things to test but I wanted to get my 2 cents in and maybe save you a lot of work. I will post once I have more info.

[CallMeDave]

In reply to:

---

Dantz has changed something between beta and release that now interacts with something.

---

 

 

 

Well, I would certainly _hope_ that they changed things between the pre-release beta and the release version(s)!

 

 

 

Have you tested client backups using a different type of Backup Set? Do File Backup Sets also exhibit the same behavior?

 

 

 

Especially since reads from the backup media are faster then writes...

 

 

 

Dave

[Sheppard]

Marsabo: "I wouldn't recommend that you go to all the trouble of re-installing OS X. I say this because I tried this already and it did not help - at all!"

 

 

 

Oops, too late, I did it this morning and you're right, it didn't help. I'll post another message with my results.

[Sheppard]

Well, I would certainly _hope_ that they changed things between the pre-release beta and the release version(s)!

 

 

 

Actually, I would hope not. In a good beta trial, the delta between the final beta, or Final Candidate Release, or whatever you want to call it, should be zero.

 

 

 

Have you tested client backups using a different type of Backup Set? Do File Backup Sets also exhibit the same behavior?

 

 

 

Yes, the second message in this thread mentioned that. I tried reinstalling X from scratch followed only by Retrospect and I'll post the results in the next message.

[Sheppard]

I read the reply about not bothering to reinstall OS X only after I'd done it. Sigh. Well, I did learn something in the course of this reinstall anyway.

 

 

 

I formatted the drive and installed X all the way to 10.1.4, then the R. client and ... it backed up at a whopping 6 MB/min. So it's not related to any of the other junk I've installed in my regular system. I used netstat to see that there were about 5% retransmissions. That'll kill throughput. Tried another cable from the client to the switch. Same problem.

 

 

 

Then I decided to use an ancient version of EtherPeek running on another computer to see what was going on with the network. Unfortunately, I have 100BT switches so I had to move the X client to a 10BT hub so that the computer running EtherPeek could see the packets. Well, whadda ya know, it now backs up at 40 MB/min, 10 times faster than when connected on 100BT switch. And netstat shows only a few retransmissions, about 0.006%.

 

 

 

OK, lets get the switch out of the picture. I connected the G4/450 9.2.2 server to the PB G3 Bronze X client with a crossover cable. Backups down at 6 MB/min again. Hmm.

 

 

 

Next I put the X client back on the 100BT switch and moved the server to the 10BT hub. Well, well, backs up at 40 MB/min again. So it seems that if either the server or the X client is on 10BT, then it backs up at 40. But if both are on 100BT, then the rate is 1/10th as fast.

 

 

 

But Finder copies are 450 MB/min so why is Retrospect sensitive to the network connection type when the Finder is not? Packet size? TCP options? The Finder always uses 1518 bytes of data and Retro uses 1518 interleaved with 642(?). My understanding of TCP/IP is that it hides the lower level details from the application. So I don't understand why Retrospect is sensitive when the Finder is not. Virtual PC is not sensitive either and it's faster than the X client. I'm baffled.

 

 

 

I suspect that from the beta that worked to the release version, something was changed in how the client uses TCP/IP. Perhaps some option was changed by the client. Only Dantz knows. I could probably dig up a 100BT hub so that I could use EtherPeek, but that will take a bit of doing.

 

 

 

The saga continues...

[dkatz42]

Wild-ass guess--you've got a link speed or duplex problem. Some interfaces and switches seem to have a lot of problems negotiating properly. Under OS X you can see what's going on:

 

 

 

localhost(107): ifconfig en0

 

en0: flags=8863 mtu 1500

 

inet 172.16.12.139 netmask 0xffffffc0 broadcast 172.16.12.191

 

ether 00:03:93:1d:03:ae

 

media: autoselect (100baseTX ) status: active

 

supported media: none autoselect 10baseT/UTP 10baseT/UTP 100baseTX 100baseTX 1000baseTX

 

 

 

localhost(108): netstat -in

 

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

 

lo0 16384 171027 0 171027 0 0

 

lo0 16384 127 127.0.0.1 171027 0 171027 0 0

 

en0 1500 00.03.93.1d.03.ae 1269491 2 3699248 0 0

 

en0 1500 172.16.12.128 172.16.12.139 1269491 2 3699248 0 0

 

en0 1500 1269491 2 3699248 0 0

 

en1 1500 00.30.65.01.ee.5e 0 0 1 0 0

 

 

 

The interesting bits are the speed and duplex (100/SIMPLEX) and the collision count (0). If you have a half-duplex device on a full-duplex link, you 'll see zillions of collisions.

 

 

 

Not sure if this information is even available under OS 9.

 

 

 

Most decent switches will have LEDs indicating speed and duplex (and switches are usually FDX) so you should verify that your OS X machine agrees with the LEDs on the port to which it is connected.

 

 

 

If you have any way of forcing your switch to HDX mode, you might give that a shot on both ports as well.

 

 

 

10Mb/HDX is the least common denominator, so the 10Mb hub probably forced both machines to HDX mode and life got better.

 

 

 

 

[dkatz42]

Woops, looks like the forum software thought that the ifconfig flags were markup tags and stripped them from the post. The flags were UP,BROADCAST,b6,RUNNING,SIMPLEX,MULTICAST...

[Sheppard]

Being a glutton for punishment, I installed R on the 9.2.1 iMac client and used it as a server while backing up the X client. It crawled at 6 MB/min. Then I installed 10.1.4 on the iMac and tried to back it up from the 9.2.2 G4/450 server. A whopping 169 MB/min!! Smokin'! Then I used the iMac under X to back up the original PB X client and it was around 46 MB/min. Much slower than the iMac, although the two machines should be comparable, but 10 times faster than the 9.2.2 server trying to backup the X client.

 

 

 

Let's try and summarize this:

 

 

 

G4/450 running 9.2.2, iMac running 9.2.1 and 10.1.4 both as client and server, PB G3 400 Bronze client running 10.1.4 as both client and server, 100BT switched. All values in MB/min. :

 

 

 

Server <-> Client

 

 

 

G4 <- PB = 4

 

G4 -> PB = 130

 

G4 <- 9.2.2 iMac = 70

 

G4 <- 10.1.4 iMac = 169

 

9.2.2 iMac <- PB = 4

 

10.1.4 iMac <- PB = 46

 

PB <- 10.1.4 iMac = 196

 

PB -> 10.1.4 iMac = 3

 

PB <- 9.2.1 iMac = 180

 

PB -> 9.2.1 iMac = 5

 

 

 

Finder copies:

 

G4 <- PB = 385

 

PB -> G4 = 60

 

PB -> 9.2.1 iMac = 60

 

PB -> 10.1.4 iMac = 180+ (Seems to suffer from pauses)

 

9.2.1 iMac <- PB = 322

 

10.1.4 iMac <- PB = 278

 

 

 

The PB just doesn't want to send data using Retrospect, either when being backed up as a client or doing a restore as a server. It is much better when being backup up by an X server than a 9 server but still crawls trying to restore to an X client.

 

 

 

Well, that should be enough stats for awhile. :-}

[Sheppard]

Wild-ass guess--you've got a link speed or duplex problem.

 

 

 

I agree there has to be some problem, but I'd like to understand why the Finder is fast but Retrospect is slow.

 

 

 

The interface is running at 100BT FD.

 

 

 

Not sure if this information is even available under OS 9.

 

 

 

You can get that from the Apple System Profiler.

 

 

 

Most decent switches will have LEDs indicating speed and duplex (and switches are usually FDX) so you should verify that your OS X machine agrees with the LEDs on the port to which it is connected.

 

 

 

Yes, it does. Both server and client are reading 100BT FD.

 

 

 

If you have any way of forcing your switch to HDX mode, you might give that a shot on both ports as well.

 

 

 

Unfortunately, no.

 

 

 

10Mb/HDX is the least common denominator, so the 10Mb hub probably forced both machines to HDX mode and life got better.

 

 

 

Yes, but there's that pesky Finder copying data at 100 times the Retrospect rate while running 100BT. That leads me to believe the network is not totally bust, but perhaps there's something different the way the Finder and R. open TCP connections with the options that are set, or something.

[dkatz42]

Should have read your post more closely, sorry...

 

 

 

I'm having a little trouble parsing your chart--do OS X <-> OS X operations work reasonably well? I would expect some degradation of speed over OS9 <-> OS9 due to additional overhead introduced by all of the good software and hardware stuff that makes the system more stable.

 

 

 

The OS X TCP is very clean and straightforward (and *extremely* well tested, unless Apple did something really stupid like touch the code.) Judging from "netstat" output, Retrospect is using the standard kernel services and not doing something bizarre like opening a raw IP socket and implementing TCP in the application.

 

 

 

I've run into serious problems running an OS X server against an OS 9 client (see the thread on remote backups hanging) and after running tcpdump and pawing through the results have discovered that there is something really horrible going on in the client/TCP stack under OS 9, which may or may not be triggered by something that the OS X server is doing. In that case, if a packet from the client is lost, the client fails to send anything further after the retransmission of the lost packet (while ignoring the offered TCP window.)

 

 

 

I don't know anything about the OS 9 TCP/IP stack, nor the level of the interface that the applications see, but there is clearly something rotten there. Perhaps you're seeing a different version of similar symptoms.

 

 

 

The TCP stream can be enlightening if you're a masochist. The number of retransmissions, the offered windows on each side, and the delay between packet receipt and acknowledgement transmission can give some hints on the dynamics.

 

 

 

Assuming that the link is clean and the Ethernet parameters all match, a healthy TCP should never run more slowly at 100Mbps than at 10. In this case it sounds like a timing-related bug in either the OS 9 TCP or the applications.

[Sheppard]

I'm having a little trouble parsing your chart--do OS X <-> OS X operations work reasonably well?

 

 

 

The relevant bits for X to/from X from my previous posting are (PowerBook (PB) is always running X) with Server on the left:

 

Retrospect:

 

10.1.4 iMac <- PB = 46 (server backing up PB)

 

PB <- 10.1.4 iMac = 196 (PB backing up iMac)

 

PB -> 10.1.4 iMac = 3 (PB restoring to iMac)

 

 

 

Finder:

 

PB -> 10.1.4 iMac = 180+ (Seems to suffer from pauses)

 

10.1.4 iMac <- PB = 278

 

 

 

From this the Finder looks OK, but the pauses were related to retransmitted packets. Retrospect seems to have a lot of trouble sending data from the PB, even X to X. But when it's talking to OS 9, it's down in the dumps.

 

 

 

... if a packet from the client is lost, the client fails to send anything further after the retransmission of the lost packet (while ignoring the offered TCP window.)

 

 

 

The TCP stream can be enlightening if you're a masochist. The number of retransmissions, the offered windows on each side, and the delay between packet receipt and acknowledgement transmission can give some hints on the dynamics.

 

 

 

There's definitely something to do with lost packets. I can't get hold of a 100BT hub so I'm going to have to pack up two or three computers and head off to where I can steal a few ports on one for awhile. I'll run EtherPeek and see what it shows regarding retransmission timeouts. I've had a lot of experience with TCP, but that was 7 years ago. I'll have to see how much I can remember. But then, I have no idea how the OS 9 protocol stack is implemented and why 9 and X don't get along -- but only with Retrospect.

 

 

 

I'm also curious why many other people aren't reporting this so I suspect the PB G3 Bronze (Lombard) may also be a key factor with its Ethernet chip. I say this because the 9.2.2 server can back up the 10.1.4 iMac at 169 MB/min! The iMac and PB should be in the same class.

 

 

 

I'm really tempted to just junk the Lombard and get a new Titanium, but that would be playing right into Steve's hands. When you make your money on the hardware, there's little incentive to support the old stuff. I've already discovered one hidden warranty with this turkey laptop so I think I'll snoop around Apple's discussion forums and see if I can find anything about Lombard and Ethernet.

 

 

 

Thanks for your thoughts.

[Sheppard]

I packed up the PB running X and took it to a place where I could get a 100BT hub so that I could plug in another PB running EtherPeek. Unfortunately, the hub was only simplex, not full duplex like the switch I have. But the results were interesting.

 

 

 

Doing a Finder copy from a G4 w/ 9.2.2 from the PB with 10.1.4 I averaged about 170 MB/min. However, there were noticeable pauses of around 1.3 seconds every so often. The pauses seemed to originate with the PB waiting to send data. Both end's TCP windows at that time were still around 30-60 KB.

 

 

 

Having Retrospect on the G4 backing up the PB, I had throughput of about 40-50 MB/min. Pretty much what I saw with the beta client or running through a 10BT hub. Again, I saw the 1.3 second pauses except this time they were very frequent and caused the average throughput to be about a quarter the speed of a Finder copy.

 

 

 

I haven't been able to hook up a protocol analyzer with 100BT FD, so I can't see what's happening in my usual setup.

 

 

 

There's definitely an interaction with OS 9 and X, 10 or 100BT and simplex or duplex. I just don't know why the Finder is so much better than Retrospect under the same network conditions. And an iMac 400 X client is way faster than my PB 400. The beta client was OK, so something is different with the release version and the way it uses TCP.

 

 

 

If anybody is interested, I have the traces in either EtherPeek format or a text file. I've been away from reading this kind of stuff for 7 years now, so I can't make much sense of it, although I intend to try some more. I'm also not sure of the validity of the packet arrival timing as the two computers seemed to take turns with bursts of packets and I've always seen a more seamless interleaving.

 

 

 

On the positive side, I have a workaround to the 4 MB/min I'm getting now because I can always connect to a 10BT hub to do a full backup, but that's a pain in the butt and speeds are limited to 45 MB/min when they should be 160 MB/min.

[Hugo]

Yep.. Same here.

 

 

 

I tried to backup a 165 Gigabyte RAID volume served by Mac OS X Server 10.1.4 with Workgroup. It screamed at 499Mbyte per minute. I am running both the Backup mac and the server over Gigabit.

 

 

 

Retrospect won't back up all the files though, and I was told I needed to upgrade to Retrospect Workgroup, which I did.

 

 

 

What now?

 

 

 

90Mbyte per minute.....

 

 

 

What a waste of technology.

 

 

 

I have been on hold with Dantz for 12 minutes now... I guess they want my money again for premium support eh...

 

 

 

 

 

hugo

 

 

[bwhbrady]

Very disappointing. Very disappointing.

 

 

 

I have Retrospect Server 5 on OS9. I have a mixture of OS9, Windows, and OSX clients. My OSX clients backup at 22MB/min. My OS9 ASIP server connects at a rate of over 220MB/min. The other clients vary in rate from 40 to 180 MB/min. But both OSX clients are stuck at 22. Unfortunately, one of the OSX clients is our new OSX Server with 50GBs of graphic files and other mission critical data. 22MB/min is unacceptable and an unworkable speed for our backup requirements.

 

 

 

I called Tech Support. The word is: "OSX is slower." But 90% slower?! According to Tech support my setup is correct. I passed their diagnostic quiz with flying colors. Great. Nothing more can be done. So for the upgrade price to Retrospect Server 5 I'm no better off than I was with Retrospect 4. What a waste.

 

 

 

Can anybody recommend another backup product/system/technique for OSX?

[Hugo]

Dantz told me that because the OS X client runs together with all the other applications in OS X, it has to share processing speed with all the other applications.

 

 

 

There is a slider control in the OS 9 client to control the processing speed alotted to the client, but not in OS X.

 

 

 

I have been doing some tests though, and have noticed that the OS X client has problems with large files (100 Meg or plus) it simply slows down to 2.5 Mb per minute!!! Then when the large files are backed up and it comes across smaller files, it speeds up again.

 

 

 

I have about 108000 files on my server, but the 8000 large ones I have slow everything down...

 

 

 

Hmmmmm.. We'll have to see what thet reply to that... Maybe it's time for Retrospect 5.1.......

 

 

[CallMeDave]

In reply to:

---

So for the upgrade price to Retrospect Server 5 I'm no better off than I was with Retrospect 4

---

 

Well, except for the fact that Retrospect 4 doesn't handle the unique file structure of Mac OS X clients (and yes, I know that there was a plug-in; it's obviously a marketing decision to charge for OS X support, which seems fair. Better then not having any OS X client support at all...)

 

 

 

My 600 Mhz iMac CDR/Mac OS 9.2 gets about 180 MB/Min backing up a G4/733/OS X 10.1.4 on a switched 100 BaseT network (to a File Backup Set) (which included some 600Mb .dmg files).

 

 

 

Perhaps if you describe you hardware setup in detail, some problem might be discovered by members of the Forum?

 

 

 

Dave

[bwhbrady]

Good. I'm getting some action now...

 

 

 

10/100BaseT Switched network with 10/100 Hubs and 10baseT unmangaged hubs. All Retrospect client machines are on 10/100 Switch ports. Cisco 1600 Router using NAT. All machines are on same private IP subnet 192.168.1.1 - 192.168.1.255. OSX Server provides DHCP to all machines except the two servers (ASIP and OSX Server) are fixed private IP in that subnet range.

 

 

 

Hardware configurations of OSX client machines:

 

OSX Server 10.1 768 MB RAM, G4/400Mhz, built-in 100BaseT ethernet: Multicast, Simplex [22MB/min backup rate]

 

OSX 10.1.3, 384 MB RAM, B&W G3/400Mhz, built-in 100BaseT ethernet: Multicast, Simplex [22MB/min backup rate]

 

 

 

OS9 clients (sampling):

 

ASIP 6.3.3 Server, OS 9.2.1, 256MB RAM, Beige G3/366Mhz, FastWide SCSI, PCI 100bT card [220MB/min backup rate]

 

OS9.0.4, 256MB RAM, B&W G3/400Mhz, built-in 100bT [180MB/min backup rate]

 

OS9.2.1, 512MB RAM, G4/400, built-in 100bt Full Duplex [45MB/min backup]

 

OS9.1, 1GB RAM, G3/400, built-in 100bt Full Deuplex [120MB/min backup]

 

 

 

Retrospect Server

 

R5.0.2.05, OS9.0 with carbon lib 1.5 extension, 176MB RAM, Fast & Wide SCSI Hard Drives and SONY AIT drives, PowerMac 8500 with 300Mhz G3 XLR8 Card, PCI 100bT ethernet.

 

 

 

This should be enough specs to get started...

 

 

[CallMeDave]

In reply to:

---

 

 

Multicast, Simplex

 

---

 

What's this?

 

 

 

Are there multiple active ethernet ports in your Network preference pane? As has been noted here before, Retrospect seems to have problems with multicasting under OS X (most notibly when attempting to execute Internet Backup Sets).

 

 

 

 

 

Dave

 

(obviously reaching...)