Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Released: R3D Data Manager for Mac v6.1

Dear Conrad,

>> Checksums are a (computer) industry standard method for comparing data. They are used from the most basic CRC check reading data from platters to ECC in RAM to the TCP stack. They are used in high level associations like checking downloads werent tampered with or code signing. Those are all different implementations of the basic checksum methodology. None of those use a diff methodology. Diffs area good way to make two files on two different systems exactly the same - like a local and remote file. Otherwise, they are not the greatest for what you are trying to do.

Well, what can I say.. Ok most people use your method. Sure they do. So ?
I like software for it's perfection. The 100% solution suits me fine. On the other hand, hardware, as you say, is not perfect.
A bit by bit comparison is 100% perfect. A check sum is not. Simply as that.

I am truly sorry you have taken exception to this.

I wish you well in your product sales. I am sorry if you feel I am saying bad things about your product; I am not. I hope you sell heaps.


all the best
james
 
Well, what can I say.. Ok most people use your method. Sure they do. So ?
I like software for it's perfection. The 100% solution suits me fine. On the other hand, hardware, as you say, is not perfect.
A bit by bit comparison is 100% perfect. A check sum is not. Simply as that.

I am truly sorry you have taken exception to this.

I take exception to this, because its not true. There IS NO software that is 100% accurate 100% of the time. The bit-by-bit method doesnt work often enough that people have reported serious problems.

Im fine if you dont use my software, and Id rather that you use something beyond finder to secure your media. But please dont tell me that bit-by-bit is any better than checksums, because it is not.

And I like your quote: "I like software for it's perfection.". Im going to print it out and frame that next to my copy of Windows 3.1
 
Hello Conrad,

You are correct, there is much so called software around that is awful.

What I was referring to is the abstract, the logic, the pureness of ideas in the Plato sense. Modus tollens and all that. One plus one is two. Does one equal one ? It is always exact ! Hardware in comparison can never be, of course, but software being logical and abstract, can be perfect. It is this ideal world software programmers like to live in.

It is into this world that the red is moving .. which makes it so exacting in my opinion. Perfection in our time.

cheers
james
 
Interesting update!

I copied 48GB from a Reddrive, FW800 port is faulty so used FW400 with a FW800 to FW400 cable, via R3D Data Manager to an esata to express card slot connected Raid.

The speed was impressive the computer reached 52-64 MBps read and 54-66 MBps write and finished the copy in 25:35, including checksums. This was on a new gen MBP late 2008 release the few that were released with an express card slot.
As a benchmark I also copied the same data via Finder to the same raid and got 66-74MBps read/write and a copy time of 11:28. Of course this was without the checksums though.

I then copied the same data on an older MBP. I connected the Reddrive with a FW800 to FW400 cable to the FW800 port on the computer. Then made a copy to the same raid connected the same way. The drives reached 44-54 MBps read and 48-56 MBps write the copy time was 27:55.

In previous versions of R3D Data Manager the read/write speeds would be around the 26-33MBps this increase in copy speed is significant.

On V5.4 the read MBps and write MBps were almost identical in similar copy configurations to what I described above. The only difference between the 2 machines that would affect the write speeds that I could think of is the RAM running at 667MHZ on the older and 1067MHZ on the newer computer.

More so I then tried copying to 2 simultaneous destinations via R3D DMNG the read speed was 19-23MBps and write was 40-48MBps and the copy time was 42:18. For this I connected the Reddrive to the FW400 port and the additional HDD (a Maxtor) to the FW800 port.
When I tried copying in the same configuration to the same simultaneous destination via Finder the read/write speeds equalled each other at 23-25MBps and the copy took 63min, no checksums included.

Considering that the write bandwidth is split between both destinations and my findings in differences between the machines above.
Logically I am deducting that V6.1 some how takes much better advantage of the RAM for copying.

Bottom line is that there is a significant improvement in the copy times due to the new way in which R3D Data Manager handles writing data. This is a great step forward way to go Conrad and team.
Who knows in the next version we may be able to saturate all the buses in a computer and over ride system usage...
 
I have the latest build of Redline installed (194), but I still don't see the options for REDcolor and REDgamma or any b30 options. Is there a later build of Redline somewhere?
 
Yeah, I've got it in the usr/sbin folder. And I see the option for the RedRocket, but it's grayed out (I assume it's because I don't have one.)

Thanks for the quick response by the way. Just copied a 16.5 GB drive to two destinations in 13:30. :thumbsup:
 
The corrupt transfers wrought by SPP almost sank a high-profile show I did a few years ago. Finder transfers have always been plagued by errors in mission-critical situations across a great enough sample size. R3DDM is the only app I've used with 100% success.

Statistically speaking, checksums don't work 100% of the time. True. The trick is finding the right balance of speed, risk, consistency and accountability. So far, R3DDM strikes that balance for me.

This is a pretty awesome upgrade that is worth being excited about.
 
The corrupt transfers wrought by SPP almost sank a high-profile show I did a few years ago. Finder transfers have always been plagued by errors in mission-critical situations across a great enough sample size. R3DDM is the only app I've used with 100% success.

Statistically speaking, checksums don't work 100% of the time. True. The trick is finding the right balance of speed, risk, consistency and accountability. So far, R3DDM strikes that balance for me.

I just feel like standing up for SPP because I'm seeing it unfairly maligned in my opinion. I've been DMT'ing Red for a couple years now, as well as asst editing a lot of the stuff I DMT'ed, and nothing was ever lost or corrupted by file transfers. To my mind the issue isn't which software/checksum method is used, but how diligently the DMT is QC'ing the transfers, and the faster the download, the more time available to do that.
 
Hey Conrad.
I tried connecting a HDD I previously copied to as destination and setting it as the source. On <V5.4 I would then click check checksums but that button is not there in V6.1 and the verify all checksums button is greyed out.
Wondering how can I check checksums after copying?
Thanks,
Nir.
 
Yeah, I've got it in the usr/sbin folder. And I see the option for the RedRocket, but it's grayed out (I assume it's because I don't have one.)

Thanks for the quick response by the way. Just copied a 16.5 GB drive to two destinations in 13:30. :thumbsup:

Can you open up the terminal application and type in the following:

Code:
ls -al /usr/sbin/REDline

It should have this in its output:

Code:
/usr/sbin/REDline -> REDline.app/Contents/MacOS/REDline
 
Can you open up the terminal application and type in the following:

Code:
ls -al /usr/sbin/REDline
It should have this in its output:

Code:
/usr/sbin/REDline -> REDline.app/Contents/MacOS/REDline


I get this when I type that command in:

-rwxr-xr-x 1 root wheel 1540992 Sep 11 2009 /usr/sbin/REDline


And not to add to the problems, but I seem to have run into another issue. When copying to two external sources at the same time, sometimes the Data Manager will write checksums to one destination but not both. Copies made after have checksums in both destinations. I am using a 4TB G-Raid through eSATA and an internal 1.5TB WD Caviar in a Manhattan dock through eSATA. Both are going into an eSATA reader in the express slot. Any ideas?
 
I get this when I type that command in:

-rwxr-xr-x 1 root wheel 1540992 Sep 11 2009 /usr/sbin/REDline

Then the beta REDline is not installed on your system. You need to more both to /usr/sbin

And not to add to the problems, but I seem to have run into another issue. When copying to two external sources at the same time, sometimes the Data Manager will write checksums to one destination but not both. Copies made after have checksums in both destinations. I am using a 4TB G-Raid through eSATA and an internal 1.5TB WD Caviar in a Manhattan dock through eSATA. Both are going into an eSATA reader in the express slot. Any ideas?

I cannot duplicate your issue. All destinations always have checksums on our systems. The checksums are written last, so this may be an issue with finder not updating the list of files in the folder.
 
Then the beta REDline is not installed on your system. You need to more both to /usr/sbin

I deleted the ones in the sbin folder and unpacked the zip file again and dropped the new ones in the folder. It works now!


I cannot duplicate your issue. All destinations always have checksums on our systems. The checksums are written last, so this may be an issue with finder not updating the list of files in the folder.


I have no idea either. I can't think of anything different that happened at the time of the copy, although it was a pretty hectic time on set. I still made sure I got that big green check mark i love so much and saved the results log like I always do. But I didn't notice the missing checksums until a couple of hours later. I certainly wouldn't have deleted them. I will keep an eye out for further instances though.
 
Back
Top