Jump to content

jedtech

Members
  • Content count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jedtech

  • Rank
    Occasional Forum Poster
  1. Suggestion: It would make Instant Scan more palatable on a laptop if there was an option to pause it when running on battery.
  2. I did the test on a 1-CPU 4-Core Hyperthreading Xeon Mac Pro (8 threads). When I said 100% of 1 CPU I should have said 100% of one thread so on this machine it was only using about 12-15% of the processing power available.
  3. I was trying to maximize the performance wherever possible. There is a significant delay for a large backup set at the end of a script when it does the catalog compression. Timing that aspect of it in my test wouldn't have been meaningful because the catalog was so small. Some of the backups that I manage have several million files.
  4. I agree that it should be an optional feature. I too have some older singe-core Pentium machines at clients and pretty much everything brings them to their knees.
  5. One of my customers asked for an assessment of how to get the best performance out of their backups and still have some security on the backup set and make the best use of storage. They are similar to many of my other customers in that they have a modern multi-core Mac Intel CPU server with 1000T network and eSATA or Fibre Channel attached storage devices. One difference with this customer is that they back up mostly JPG files. I set out to test a variety of scenarios to see how they would perform and where the bottlenecks were. I thought it was worth sharing and may also give the Retrospect developers some information about how Retrospect 9 performs in the real world backing up JPG images. Here are the results and my recommendations to them: -------------- I set up a series of backups of 19,613 files totaling 13.75GB of primarily JPG files which should give similar results on a smaller scale to what the customer has. There were no TIFF files in my batch so compression of those files would result in slightly higher overall compression. I used a 2010 Mac Pro 2.93 GHz quad-core eSATA connected to a Western Digital My Book Studio Pro II 4TB backup drive. The client machine is a MacBook Pro connected via 1000T ethernet with a 7200 RPM 500GB disk drive. For the first test I ran the following settings: Password protection, no compression, no verification, no catalog compression and got the following results: Elapsed time: 6 min 31 secs, Data Rate: 2.1 GB/min, Backup Set size: 13.73 GB Retrospect CPU Usage ~ 100% of 1 CPU almost entire time Workstation CPU ~ 15% of 1 CPU average I then turned on Media Verification and ran it again which produced: Elapsed time: 9 min 20 secs, data rate: 1.5 GB/min, backup set size: 13.73 GB Retrospect CPU Usage ~ 100% of 1 CPU almost entire time I did not test turning on "Thorough Verification". I turned verification back off and turned on compression which produced: Elapsed time: 12 min 42 secs, data rate: 1.5 GB/min, backup set size: 14.62 GB - NOTE LARGER SIZE WITH COMPRESSION Retrospect CPU Usage ~ 100% of 1 CPU almost entire time I believe that the larger size above was the result of Retrospect trying to compress JPG documents which are already highly compressed which results in the compressed file actually being larger than the original. Turning verification back on and keeping compression yielded: Elapsed time: 14 min 18 secs, data rate: 0.894 GB/min, backup set size: 14.62 GB Retrospect CPU Usage ~ 100% of 1 CPU during both backup and verification phases To see how much disk drive bandwidth affects the remote backups I switched from using the eSATA 3Gbps port to FireWire 800 on the same drive and re-ran the uncompressed fastest backup: Elapsed time: 6 min 42 secs, data rate: 2.0 GB/min, backup set size: 13.73 GB This surprised me, I was expecting the eSATA to perform at a much higher rate but the current version of Retrospect is unable to deliver the data fast enough to make use of it. At this point I switched to using AES-128 Encryption and re-ran the relevant tests (using the eSATA interface again) Testing with encryption but no compression yielded: Elapsed time: 11 min 45 secs, data rate: 1.1 GB/min, backup set size: 13.73 GB Retrospect CPU Usage ~ 115% of 1 CPU almost entire time Testing with both encryption and compression yielded Elapsed time: 17 min 40 secs, data rate: 0.76 GB/min, backup set size: 14.62 GB Retrospect CPU Usage ~ 110% of 1 CPU almost entire time Conclusions: 1. Retrospect Server is single-CPU-limited even with uncompressed remote backups. Use the fastest CPU available. 2. Even with a fast 2.93 GHz Xeon CPU Retrospect was barely able to fully saturate FireWire 800 so there is not a lot of benefit to using the faster eSATA interface on a machine below 3GHz. The faster interface yielded only about a 3% speed benefit. 3. Media Verification slows backup of a remote device by about 50% 4. Compression slows backup by about 100% and may result in larger backup files if highly compressed original files are being backed up. 5. Data Encryption appears to be able to make use of at least part of an additional CPU reducing its impact on the backup time. 6. Data Encryption did NOT increase the size of the backup but did incur almost a 50% performance penalty over password protected 7. The combination of Encryption and Compression reduces the speed to only about 1/3 the speed of Password without compression 8. Slowest backup is Encryption, Compression, Verification Recommendation for my customer: 1. Leave compression off, the decreased speed and increased size of already-compressed files makes it not worthwhile for JPG backups 2. Leave catalog compression off 3. Use either "No Verification" or "Media Verification" (but keep "Generate MD5 Digest" option turned on for manual verification) Recommendation to Retrospect team 1. Figure out how to take advantage of multiple CPUs on the server machine 2. Consider distributing the compression and/or encryption workload to the client
  6. jedtech

    100Mbps limit?

    The same client software performs great with Retrospect 6 but about 10x slower with 8. I posted a packet trace a while back but no one ever responded. I believe that Retrospect Server is losing packets and the subsequent retransmissions slow everything down to a crawl. I was hoping that someone more conversant than I with packet traces could confirm my theory. John Duncan
  7. jedtech

    Sources not found

    On the 10.6.2 server after killing the Retrospect process I rebooted the server. After rebooting the Retrospect server process came back up but I was still unable to see any sources. I used the Retrospect system preference to stop the server and restart it and after that the sources showed up. This is clearly a Retrospect Server problem.
  8. jedtech

    Sources not found

    The firewall was not and still is not turned on. Killing the Retrospect Server process fixed the problem on the 10.5.8 machine. Rebooting will probably fix the 10.6.2 machine but haven't been able to test it yet. I'll post here when I do
  9. jedtech

    Sources not found

    Thanks for the tip on killing the Retrospect process. This worked on the 10.5.8 Server and clients immediately showed up after the process respawned. Jury is still out on the 10.6.2 Server however. After the kill -9 the process did not respawn. Using the System Preference to restart it was unsuccessful. I'll have to try rebooting the machine after-hours and hopefully all will be well.
  10. jedtech

    Sources not found

    Agreed but what changed in 626 to cause it? Both these installations were successfully finding their clients with 622 and stopped on the day I installed 626 with no other network, software or hardware changes.
  11. jedtech

    Sources not found

    I am having same problem with sources not showing up at two different installations with 626. All proactive backups are failing. One site is MacOS-X Server 10.5.8, other is 10.6.2. All client machines are Windows XP or Vista. I was able to get the 10.6.2 site working again by manually adding the IP addresses but they still don't show up in the sources. I will probably try downgrading the other site to 622. All sources will answer if you put in the specific IP address. Tested with all firewalls off and same results.
  12. jedtech

    Performance Drops

    I'm running Retrospect 8.1.622 on an OS-X 10.5.8 Server with Intel Quad-Core Nehalem 2.93GHz and also getting very slow backups of the remote workstations (both Mac and Windows). It appears to deteriorate as the backup progresses. The network is all 1000T and during the slowdown the CPU and disk activity of both the Server and Client machines are very low. I ran a TCPDUMP from the server which appears to indicate network problems. Here's a partial dump, perhaps someone who is more conversant with this can shed some light but to me the incorrect checksums raise a red flag. In this dump, IP 192.168.56.10 is the client and 192.168.56.11 is the server and the one that is running the TCPDUMP. ----------------- 09:58:37.637331 IP (tos 0x0, ttl 64, id 45432, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xc751), ack 721161 win 30964 09:58:37.637954 IP (tos 0x0, ttl 128, id 38367, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 721161:722609(1448) ack 0 win 65535 09:58:37.637956 IP (tos 0x0, ttl 128, id 38368, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 722609:724057(1448) ack 0 win 65535 09:58:37.637956 IP (tos 0x0, ttl 128, id 38369, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: P 724057:725505(1448) ack 0 win 65535 09:58:37.637957 IP (tos 0x0, ttl 128, id 38370, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 725505:726953(1448) ack 0 win 65535 09:58:37.637958 IP (tos 0x0, ttl 128, id 38371, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 726953:728401(1448) ack 0 win 65535 09:58:37.637959 IP (tos 0x0, ttl 128, id 38372, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: P 728401:729849(1448) ack 0 win 65535 09:58:37.637960 IP (tos 0x0, ttl 128, id 38373, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 729849:731297(1448) ack 0 win 65535 09:58:37.637961 IP (tos 0x0, ttl 128, id 38374, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 731297:732745(1448) ack 0 win 65535 09:58:37.637962 IP (tos 0x0, ttl 128, id 38375, offset 0, flags [DF], proto TCP (6), length 756) 192.168.56.10.dantz > 192.168.56.11.64043: P 732745:733449(704) ack 0 win 65535 09:58:37.637985 IP (tos 0x0, ttl 64, id 10345, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xb87a), ack 724057 win 31856 09:58:37.637990 IP (tos 0x0, ttl 64, id 31600, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xb5a6), ack 725505 win 31132 09:58:37.637994 IP (tos 0x0, ttl 64, id 53013, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xaffe), ack 728401 win 29684 09:58:37.637998 IP (tos 0x0, ttl 64, id 4178, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xad2a), ack 729849 win 28960 09:58:37.638001 IP (tos 0x0, ttl 64, id 45415, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xa782), ack 732745 win 27512 09:58:37.638004 IP (tos 0x0, ttl 64, id 30833, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xa622), ack 733449 win 27160 09:58:37.638472 IP (tos 0x0, ttl 128, id 38376, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 733449:734897(1448) ack 0 win 65535 09:58:37.638473 IP (tos 0x0, ttl 128, id 38377, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 734897:736345(1448) ack 0 win 65535 09:58:37.638473 IP (tos 0x0, ttl 128, id 38378, offset 0, flags [DF], proto TCP (6), length 1252) 192.168.56.10.dantz > 192.168.56.11.64043: P 736345:737545(1200) ack 0 win 65535 09:58:37.638482 IP (tos 0x0, ttl 64, id 15641, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0xa07a), ack 736345 win 25712 09:58:37.638485 IP (tos 0x0, ttl 64, id 36172, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0x9e22), ack 737545 win 25112 09:58:37.638722 IP (tos 0x0, ttl 128, id 38379, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 737545:738993(1448) ack 0 win 65535 09:58:37.638723 IP (tos 0x0, ttl 128, id 38380, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 738993:740441(1448) ack 0 win 65535 09:58:37.638724 IP (tos 0x0, ttl 128, id 38381, offset 0, flags [DF], proto TCP (6), length 1252) 192.168.56.10.dantz > 192.168.56.11.64043: P 740441:741641(1200) ack 0 win 65535 09:58:37.638724 IP (tos 0x0, ttl 128, id 38382, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 741641:743089(1448) ack 0 win 65535 09:58:37.638725 IP (tos 0x0, ttl 128, id 38383, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.56.10.dantz > 192.168.56.11.64043: . 743089:744537(1448) ack 0 win 65535 09:58:37.638726 IP (tos 0x0, ttl 128, id 38384, offset 0, flags [DF], proto TCP (6), length 1252) 192.168.56.10.dantz > 192.168.56.11.64043: P 744537:745737(1200) ack 0 win 65535 09:58:37.638734 IP (tos 0x0, ttl 64, id 5401, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0x987a), ack 740441 win 23664 09:58:37.638738 IP (tos 0x0, ttl 64, id 21821, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0x9622), ack 741641 win 23064 09:58:37.638742 IP (tos 0x0, ttl 64, id 36415, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0x907a), ack 744537 win 21616 09:58:37.638744 IP (tos 0x0, ttl 64, id 43277, offset 0, flags [none], proto TCP (6), length 52) 192.168.56.11.64043 > 192.168.56.10.dantz: ., cksum 0xf18c (incorrect (-> 0x8e22), ack 745737 win 21016
  13. I tried completely rebuilding the catalog, no joy (took 5 days). I then erased the catalog and started over. It gets a few tapes in and then fails with the same elem16.c-687 error. I tried reverting back to 6.1.126 and starting over, same problem. The primary change here is that both the Retrospect Server and clients are now on 10.4.11 and also one of the clients is upgraded to iLife '08. I am stuck at this point.
  14. I encountered the same problem after upgrading from Tiger OS-X Server 10.4.9 to 10.4.11. This was without installing 6.1.138. I installed that hoping it would fix the problem but no luck. Sometimes it fails when backing up the local server volumes, sometimes when backing up remote machines. No solution so far. New media would be a last resort since I am into 14 AIT-3 tapes at about $50 each.
  15. Tape drive works fine with built-in 400 or 800 ports. I just bought a LaCie d2 DVD-RW and tried connecting it to the DuoConnect and it has a similar problem (it too works fine with the built-in ports). I tried using Disk Copy to create an image of a DVD with the drive connected to the DuoConnect. It struggled for about 6 hours to read the DVD. Most of the time the activity light was off. It seemed to make it through the entire DVD, but it took probably 30 times longer than if I had read it via the built-in DVD drive which is actually a slower drive. It looks like there is something wrong with OS-X 10.3.9's drivers with respect to this card. I'm going to try upgrading to OS-X Server 10.4 and see if things improve.
×