decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Encryption causes computer slowness | 360 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Encryption causes computer slowness
Authored by: Anonymous on Sunday, November 11 2012 @ 05:23 AM EST
True but for the seriously paranoid it is the only way to be sure something
won't be visible in a cache, or in a log or temp file. There are services
logging all sorts of stuff these days. Yes there are ways to tell them to ignore
certain files or not log certain things. But there are so many places things get
logged or backed up it is easy to slip up and forget something. If you have
confidential stuff the only way to be really sure of no leaks is to encrypt the
lot.

For example zeitgeist seems implacably determined to index every file you touch
and everything you do; the location service seems implacably determined to log
your physical location every couple of seconds. Your browser is implacably
determined to cache everything; as is your media player. Etc. So many logging
caching things.

[ Reply to This | Parent | # ]

Encryption causes computer slowness
Authored by: yacc on Monday, November 12 2012 @ 06:15 AM EST
Well, if it's so, you've got something wrong with the
encryption.

For practically any modern PC encryption is a trivial load,
especially if you compare it to hdd access times. Basically,
even my old (and it was not a high end one when I bought it
either) AMD box manages to decrypt 100MB/s.

For filesystem browsing the most relevant issues involve
seeking time (because the directories are most probably not
stored sequentially at one place), and filesystem code, e.g.
some filesystems are better at handling huge directories
than others. Additionally depending upon your OS/tools
involved, the file browser might want to probe the files as
such to determinate their contents, even more seeking.

As to the reason why a backup, and restore to a new system
without encryption produced a speed up => if you did the
backup on file level (e.g. tar on Unix), the restoring
operation produced a nearly perfectly defragmented,
sequentially layed out filesystem content.

To put it to numbers, using an average seek time of 10ms, my
box can easily decrypt around 1MB during this time, using
only one of it's 4 cores. Reads of 1MB are seldom, e.g. on
my hdd it defaults to 128KB read ahead.

So what do you need for speedy file browsing no matter what?
Basically a good (good nowadays implies avoid the buggy
ones) SSD.

For example, my PC is currently backing up my SSD via a lvm
snapshot, the SSD is doing 1000-2000 io transactions per
second, and I don't really notice that, because my normal
operating needs are a tiny compared to it's capacity for
random access. Try the same with a normal hdd, and the PC
will slow down to a crawl, as normal hdd (again based on the
10ms average) can handle roughly 100 transactions per
second, even with considering the scheduling optimizations
that Linux applies, they seldom manage more than 200
transactions per second (how? simple by sorting the access
locations, the seek time on average is lower than the quoted
"average seek time" which is derived on seeking from a
random location to another random location.)



[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )