Darren -

                There is extensive scientific data on this, no need to 
speculate. Software FDE does cause some extra battery usage due to extra CPU 
utilization (Bias stated, Mobile Armor makes BOTH software FDE and 
authentication and management modules for encrypting hardware drives like Opal 
SSC).

                I wouldn't categorize the data as 'significant', unless your 
use of mathematical exponentials differs from mine. Given that we make both 
drives with embedded authentication and software based FDE, we have seen 
battery time changes in minutes - not hours as your use of SIGNIFICANT would 
denote.

                Perhaps your calculus is different than mine?


Regards;

Bryan
------------------------------------
Mobile Armor
Bryan E. Glancey
Senior Vice President & Chief Technology Officer
br...@mobilearmor.com<mailto:br...@mobilearmor.com>
400 South Woods Mill Rd.
Suite 300
Chesterfield, MO 63017
http://www.mobilearmor.com/
------------------------------------


From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On 
Behalf Of Darren Lasko
Sent: Tuesday, April 28, 2009 5:45 PM
To: fde@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer


Hi Tim,

I'd also like to make a point regarding your statement that, "the marginal cost 
of additional CPU usage is zero unless your CPU meter is pegged."  This might 
be true if you are running software-based FDE on a desktop system or on a 
notebook PC that is using wall power.  However, for notebook PCs that are on 
BATTERY, additional CPU usage greatly impacts your on-battery time.

I've experimented with software-based FDE (granted, not BitArmor, but I can't 
imagine the results will be much different), and there is a SIGNIFICANT 
decrease in the amount of time you can stay on battery when using 
software-based FDE compared to using a self-encrypting drive.  The difference 
is significant even under light workloads where the drive I/O activity is low.

Best regards,
Darren Lasko
Principal Engineer
Advanced Development Group, Storage Products
Fujitsu Computer Products of America


Dmitry Obukhov <d.obuk...@samsung.com>
Sent by: fde-boun...@www.xml-dev.com

04/27/2009 02:40 PM
Please respond to
fde@www.xml-dev.com


To

fde@www.xml-dev.com

cc

Subject

Re: [FDE] how FDE is implemented at system layer







Hi Tim,

It is not about "archaic". It is about ratio between storage throughput and
CPU computational power. If you use very fast storage (SSD, as I did, or
RAID controller), it can make any CPU relatively "archaic".

"Up to" was received on Dell D630 with SSD (fresh Vista Ultimate) and
intensive read access. On the same machine you can get lower values of CPU
load with lower intensity of storage access. Obviously, CPU load will be 0
if you don't access the data at all. If your results are about 3%, it means
that your storage is "archaic" relatively to CPU or you do not exercise it
on its full speed.

WBR,

Dmitry






-----Original Message-----
From: fde-boun...@www.xml-dev.com [mailto:fde-boun...@www.xml-dev.com] On
Behalf Of Tim Hollebeek
Sent: Thursday, April 16, 2009 8:19 AM
To: fde@www.xml-dev.com
Subject: Re: [FDE] how FDE is implemented at system layer


> > It is very CPU-consuming
> > process. Up to 48% of the CPU power can be spent on encryption.
>
> Really?

Maybe on archaic hardware.  The numbers we've seen are closer to 3%.
And of course, the marginal cost of additional CPU usage is zero unless your
CPU meter is pegged.  "Up to" can be very misleading.  Up to 100% of the
information in this email might be wrong.  That doesn't mean it is.

Encryption is not a CPU intensive operation on modern machines.
I run our FDE product on my machines, and I often forget it's there.
The overhead is not noticeable.

-Tim



_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde

_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde




This message contains information which may be confidential and privileged. 
Unless you are the addressee (or authorized to receive for the addressee), you 
may not use, copy or disclose to anyone the message or any information 
contained in the message. If you have received the message in error, please 
advise the sender by reply [email], and delete the message.
_______________________________________________
FDE mailing list
FDE@www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde

Reply via email to