Slashdot Mirror
Optimizing Linux Use On a USB Flash Drive?
Buckbeak writes "I like to carry my Linux systems around with me, on USB flash drives. Typically, SanDisk Cruzers or Kingston HyperX. I encrypt the root partition and boot off the USB stick. Sometimes, the performance leaves something to be desired. I want to be able to do an 'apt-get upgrade' or 'yum update' while surfing but the experience is sometimes painful. What can I do to maximize the performance of Linux while running off of a slow medium? I've turned on 'noatime' in the mount options and I don't use a swap partition. Is there any way to minimize drive I/O or batch it up more? Is there any easy way to run in memory and write everything out when I shut down? I've tried both EXT2 and EXT3 and it doesn't seem to make much difference. Any other suggestions?"
Get a swap partition so that you can free up some memory for disk cache, for one. Enable laptop mode too.
Support my political activism on Patreon.
USB has high cpu use and encrypted does not help a firewire based flash drive will be a lot faster. USB 3.0 may help but it too may still the limit of usb 2.0 high cpu use as well.
Well, the sucky thing about USB is it requires an inordinate amount of CPU. Normally this isnt a worry, but if you're using a encrypted loopback.. well ouch.
One thing you could instead use is the SD card slot and a USB loader. If you choose a 8GB class 6 SD card, you could have plenty of room for whatever, and 6MB/s minimum speed. You're still going to take the CPU hit for encryption, but that is your choice. The big thing is to stay off the USB.
You'll get a huge performance increase and maintain a similar level of portability.
Are you using squashfs?
Having everything compressed seriously reliefs the drive I/O. Another nenfit is that more stuff fits on your stick :D
One thing I've found really, really helps is to use smaller programs et al. While the difference in how long it takes to start up gnome-terminal vs rxvt or nautilus vs pcmanfm is minimal on a normal/modern desktop or laptop, the difference is substantial on a cheap USB flash drive. There's plenty of lists for lightweight applications, window managers etc for linux around online. In fact, I'll often just stick with terminal applications (moc, for instance).
Another option, if you're booting on a box which has a good internet connection, is to ssh -X things over a network. Not only does this save a large amount of space, but I've found it's often faster to have a program like Firefox start on my snazzy box at home and ssh -X over than waiting for it to load off of my crappy usb drive.
"A witty saying proves nothing." - Voltaire
It might be that the poor performance occurs when you're on a computer that only has USB1 support. On Dells this was added later than you might expect.
You might find you got better performance if you were to use a CD to hold most of the static software and the USB for just your home directory.
switch to slax. it's faster.
I know a little bit about this because I am one of the developers for TurnKey Linux, a new opensource project which builds small installable live CDs (we're up to 9) optimized for various mostly server-related tasks. I've been investigating supporting live USB mode.
Your generic run-of-the-mill USB drive has about fourth-half the read/write performance of your hard drive nowadays (10-15MB/s). Since there are no moving parts (spinning platters), usually the seek times are very good.
There are several things you can do to optimize the performance of an operating system running live from a USB drive:
1) buy a faster USB drive: a good USB drive (e.g., Lexar JumpDrive) can have 2-3 times the performance of a generic.
2) Use a Linux distribution with a smaller footprint such as DSL (50MB) or Puppy Linux (standard edition is 68MB): the smaller the footprint, the less your drive has to read, the faster your system will load.
3) Try loading the operating system system into a ramdisk: many live USB distributions have the ability to load themselves into RAM. With some you have to add a cheatcode in the bootloader. Others do it by default if there is enough memory (usually not a problem with small distributions and modern computers).
4) Try turning on readahead: many distributions which are designed to run from a live CD or live USB have a feature that reads ahead various files important to the boot sequence sequentially. Whether or not this helps depends on the characteristics of the storage medium you are using, but you should investigate it.
TurnKey Linux: if it can be easy, it should be easy
make sure you are on USB 2.0- interface can kill you.
Also did you check the faq-
No seriously:
http://www.linux-usb.org/FAQ.html#i5
especially the section on:
Q: What is max_sectors and how should I use it?
A:For USB Mass Storage devices (that is, devices which use the usb-storage driver) max_sectors controls the maximum amount of data that will be transferred to or from the device in a single command. As the name implies this transfer length is measured in sectors, where a sector is 512 bytes (that's a logical sector size, not necessarily the same as the size of a physical sector on the device). Thus for example, max_sectors = 240 means that a single command will not transfer more than 120 KB of data.
Most USB flash drives are very slow, and rely on heavy cacheing to make them usable. That doesn't help when you need to write large amounts of data (ie. in an apt-get update/install).
Some flash drives that advertise themselves as 10-15MiB/sec write capable peak out at only 1 or 2, and even less with small-block random I/O (since the erase-write cycle operates on relatively large blocks).
Several vendors make specialized flash drives that are somewhat more expensive (ie. 20-50% over average), but perform much better.
One is here: OCZ Turbo USB 2.0
A government is a body of people notably ungoverned - AC
Puppy Linux is tiny and is set up to boot off of USB. After it's booted, if the system has enough RAM, the entire system is loaded into RAM. Makes for a damn snappy system.
http://www.puppylinux.org/
I/O to RAM is really fast compared to I/O to any block device (most USB keys appear to the host PC as block devices, because they have a little ARM7 or other low-power 16-bit MCU on them that emulates the IDE interface). So, maybe you could get a speedup by mounting any I/O intensive parts of your filesystem on a ramdisk. It might also save wear and tear on the flash (though MLC NAND is never going to be all that reliable). Here's an fstab excerpt showing one technique:
/dev/ram0 /tmp tmpfs defaults,nodev,nosuid 0 3
/dev/ram1 /var/run tmpfs defaults,nodev,nosuid 0 3
/dev/ram2 /var/log tmpfs defaults,nodev,nosuid 0 3 /tmp, /var/run, and /var/log on them. The next step would be to write something to serialize and unserialize the ramdisks at startup and shutdown, and optionally snapshot them from time to time to safeguard against power failure. This example uses the parts of a filesystem that'd be I/O intensive on a server, but I don't see why you couldn't do the same thing with your home directory or whatever else. You could profile your USB distro by instrumenting your kernel, or just list your recently touched files from time to time to get a sense of where the I/O is happening.
This makes three ramdisks with dynamic capacity, and mounts
Distros like Damn Small Linux know a mode where all frequent writes go to a RAM disk. Current flash hardware (especially disks - lesser cheap usb sticks) is already a lot smarter at "wear levelling", but a standard distro genereates a whole lot of small writing activity. It would be nice if there was a out-of-the-box way to make a server distro like Ubuntu Server USB ready. My file server could shut down its 5 disks completly until I access the files over the network. This could save quite some energy (and disk lifetime).
I don't know if Linux requires anything less than MS Vista in terms of system resource requirements (memory, etc) these days, but with OpenBSD I also run it off of USB - optionally loads to various MFS filesystems, (/, /var, /tmp, /usr, /home, etc...) syncs the MFS to Flash on shutdown and a bunch of other goodies, hopefully to be ported to Linux as well. But I'm sure it's possible, with Linux, somehow, just might be a hell of a lot of work to try and lean it out.
What about making sure all log and tmp files are redirected to a ram disk?
Try out different filesystems, NILFS seems to be optimized for FLASH usage.
Brtfs could also be worth a try.
use the "noop" IO/Scheduler with nilfs: /sys/block/sdX/queue/scheduler
echo noop >
Postmark benchs on an usb-stick (shameless copied from here:
ext3 (mount -o noatime,noadirtime, normale Partition, scheduler cfq): 49 Transactions/s
nilfs2 (Partition aligned 128k, scheduler noop, protection_period 10s): 588 Transactions/s
you need to work on your grammar.
I have an old 10GB laptop drive inside of a very low profile USB enclosure and it runs like 35x faster than my USB drive or something absurd like that. It's a little more sensitive to bumps but it's not exactly expensive for 10GB drives. You can get a 6 pack of used one on ebay for about $3-7 each. Best of all, in a good enclosure, it still fits in your pocket.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
You might want to try replacing many programs as you can with busybox. It's versions of utilities are less complete than the standard gnu utilities, but they are all rolled into one binary, so most likely most of that binary will get cached in ram pretty early and stay there.
Also, for any packages you build you should try to use the -Os option for gcc, and perhaps even strip the binaries to remove unused symbols and debug info.
Building the system as though this was an embedded system with a small disk should be a win in most cases since fewer things have to go over the wire to load a file and more of the binaries can fit into cache.
PCLinuxOS, DSL, Knoppix (and probably many others) can run entirely from RAM and only use the USB drive to save the user's settings.
For my company I have made two streamer server products based on 1U HP Proliant servers using the internal USB connector running Debian GNU/Linux. First I used the cheapest 1 GB stick from Kingston but then found out that read and write speeds was not specified and very low. I then settled for a 2GB a-data PD7 drive. Believe me it's fast! They were spec'ed to 20MB/s write and 25MB/s read speed. Using cpipe I measured sustained write speed of 21MB/s and read speed of 26MB/s. They are just so good to the price.
Read a review of the 8GB PD7 drive here:
http://www.overclockersclub.com/reviews/adata_pd7_8gb_flash_drive/6.htm
Delete it on unmount (as part of your shutdown process) -- if you're truly paranoid you can even take the time to scrub the sectors your swap was using.
He's running his flash drive using full-disk encryption. So he's concerned about leaving his data lying around. If that's the case he should not be swapping in the clear, then hoping it gets properly scrubbed later. The swapping should also be encrypted.
It should be possible to do the same loopback-though-encryption hack to the swap file on the Windows disk as you use to encrypt the whole disk. (Make the swap file, mount an encrypted loop on it, declare that to be swap for Linux.)
I haven't done this myself yet so I won't try to give a detailed how-to. But it shouldn't be too hard to figure it out from how the encrypted-disk is done, and set up a script to do all the mounts and file creations in one shot to add the swap file.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
The best thing to do is make a ram disk and use that as swap space.
So the OS can use part of the memory as swap, rather than memory, and when the part it is using as memory is full it can copy it to the part it is using as disk? (Except it won't, because if I recall correctly the RAM disk, along with disk buffers, are all dynamically assigned in memory, so when you need to swap there's nowhere to swap to.)
Were you trying to be funny? Or just unintentionally managed it?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I'm surprised no one mentioned this (or maybe someone has and it's just under my threshold), but not using a journalling filesystem can help tremendously. Having a whole system on a flash-based USB mass storage media formatted and mounted as ext3 is a great way to make sure the only bottleneck you'll ever have is disk I/O.
"Beware of he who would deny you access to information, for in his heart he dreams himself your master."
Create an initrd image with your entire filesystem (use BusyBox etc) and never do the pivot root back to disk.
I run exclusively off a flash drive. I'm nomadic and it's easier to haul around than a laptop.
Many apps like to call fsync() needlessly, causing many writes to occur to the flash drive. Buffering all these writes in RAM until you halt the system works around this.
One of the largest performance gains I've gotten is by using tmpfs to store all of firefox's data.
Strategy is as follows:
On boot, mount ~/.firefox as tmpfs. Extract backup tarball into this dir.
On halt, generate tarball of ~/.firefox
Some scripts are at http://coder.home.cosmic-cow.net/src/usbstick/
I use this strategy with firefox, pidgin, and a few other apps. The performance gain is amazing.
If it's web browsing performance you're worried about, turn of the browser disk cache, it's probably competing with your apt-get for disk IO bandwidth, and a fair bit of it will be writes too..
To turn off file system journaling (whatever file sys you use) Other comments were good. I didn't see my favorite, though.
TEXT MODE only! Runlevel 3 is awesome! runlevel 5 is for wusses.
Dave Jones recently posted elsewhere his notes for improving things on the eee900. Several of the steps focus on getting proper performance out of the flash, and so would also apply to booting from a USB thumb drive or other flash media. Here's what he had to say:
Program Intellivision!
"Those chips are about as intelligent as a rubber band. There's currently just no way to implement sane wear filesystem-independent wear levelling in a tiny chip like that."
Which is why HDDs do all their "wear leveling" in software.
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
"What can I do to maximize the performance of Linux while running off of a slow medium?"
Stop trying to fight physics and use a different technology
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
>A read only filesystem for general use. That sounds like fun.
My travel notebook has a CF card for storage, and normally runs with aufs overlaying a tmpfs (RAM) filesystem in front of the flashcard.
So reads come from the 40MByte/sec CF card, and writes just go to RAM. Nothing is saved permanently unless I want it to be saved.
This makes for safer browsing, and gives the ability to try out new s/w packages in a throw-away environment.
In grub I have the choice at boot of running entirely from CF, which is slower but makes all changes permanent.
But even with the tmpfs overly, I can still access the real underlying CF media for permanent writes when needed.
And a simple bash script can be run to "commit" all of the tmpfs/aufs changes back to the real CF.
I wouldn't want it any other way for my travel machine!
Cheers
I would suggest using a distro that supports a "live filesystem" that normally runs off of the CD Drive, these copy a lot of stuff into RAM and the ones I have played with are actually quite responsive (once booted). You can leave your home directory mounted on the USB drive so any data files you create/modify will be with you after you shut the system down.
Since the system is running in RAM it leaves NO garbage on the host computer.
RSD
w/ a smaller distro couldn't you just some way load it ALL into memory?
that would seem like the most potential.
other then that I suppose -f or prelinking...
"Given the journal is in a fixed location on disk, scribbling to it every time a file gets written is a great way to wear out the flash."
Unless the flash drives they are using are extremely lame (and I mean extremely), they use technology called wear leveling. This means that even if the journal is in a fixed location according to Linux, it's not in a fixed location according to the hard drive. Writes are spread to different bits of hardware for the same "physical" sector. As I understand it, every flash drive except for cheap, crappy USB drives use wear leveling (and even they might)
"After installing, change the fstab so that everything gets mounted with noatime."
This is not really that necessary anymore. Fedora 8 and on have relatime set by default which is only negligibly slower than noatime and there is no possibility of having any problems. You still can do it I suppose, but it's no where near the difference between atime and noatime
Apparently, the wear leveling isn't that great on some. Dave said he's seen an eee with dead flash precisely where the swap used to be. Apparently some of the lower-end flash devices wear-level in zones, meaning that if you have a particularly hot "zone", you could still burn that zone out. I imagine $10 USB sticks from Office Despot are going to have those lower-tech algorithms, or algorithms tweaked specifically for FAT filesystems.
According to Val Henson (who invented relatime, apparently):
So there you have it.
Program Intellivision!
There's quite a discrepancy over the speeds on flash drives. Cheap flash drives run USB 1.1 and the transfer rates are around 1 MB/sec. USB 2.0 drives range from slow 10 MB/sec to close to 40 MB/sec. The fastest drives will cost easily over $100. The size of the drive will slow the transfer rate also. 4 GB drives are faster than 8 GB and so on. Corsair GT drives have close to 35 MB/sec read speeds, write speeds are always dramatically slower. I've installed a bootable PBX in a Flash on a 4 GB Corsair USB flash drive with very acceptable performance for teaching purposes. I can see other LAMP bootable installations popping up. Each student can have their own server to configure and boot-up then take shut it down and take it home.
puppy linux can load to ram and then no longer needs the loading medium
Cant he keep /bin & /usr/bin on the HDD and just have the kernel load into ram anyway?
IranAir Flight 655 never forget!
Do you really need to encrypt everything? Why don't you create a separate partition for your /home (and /var /etc and /tmp if you really want to); encrypt that/those but not the rest. I can't see why there'd be anything confidential about what's in all other directories, especially since almost all the rest is probably open source anyway.
If the ordinary experience is acceptable, try running background jobs or I/O intensive non-interactive jobs using the ionice command, such as
ionice -c 3 apt-get update
(Make it suid or run as root.)
2) Use a Linux distribution with a smaller footprint such as DSL (50MB) or Puppy Linux (standard edition is 68MB): the smaller the footprint, the less your drive has to read, the faster your system will load.
Puppy does exactly what the Original Poster asks for. It loads everything into RAM and when you shut down/reboot it asks if you want to save the changes to disk - this includes newly installed packages, updates, your documents, settings etc. You have the option for this "save file" to be encrypted (and password protected) or not.
Puppy has also done a lot of optimizing for running on a USB stick, and it can handle encrypted partitions. Check it out: puppylinux.org
Do not swap onto your USB drive, that is a very bad idea and will lead to horrific performance, and a failed USB key. Second, setup a ram disk on boot and put /var there so that all logging goes to ram disk. Most USB keys will fail otherwise because they are not designed for repetitive write cycles.
Salut,
Jacques
how about disabling or decreasing syslogd log priority to log only critical or emergency messages /tmp /var/tmp /var/log bind mounted on a dynamic tmpfs or static ramfs
and/or to have
so you don't have logs and variable files hitting the flash ever
A sentence is supposed to begin with a capital letter.
(1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
I'm not sure much gets logged on a properly functioning system with few services enabled. I just looked at my /var/log/messages on my Ubuntu system. It's pretty mind-numbingly boring:
Nov 30 07:53:25 metal syslogd 1.5.0#1ubuntu1: restart.
... several more pages of the same ...
Nov 30 08:08:06 metal -- MARK --
Nov 30 08:28:06 metal -- MARK --
Nov 30 08:48:06 metal -- MARK --
Nov 30 09:08:06 metal -- MARK --
Dec 4 07:08:06 metal -- MARK --
Dec 4 07:28:06 metal -- MARK --
Dec 4 07:48:06 metal -- MARK --
Dec 4 08:04:36 metal syslogd 1.5.0#1ubuntu1: restart.
Dec 4 08:28:07 metal -- MARK --
Dec 4 08:48:07 metal -- MARK --
That's one new write appending to the log every 20 minutes. I think by that point it's officially in the noise, even if it ends up being two writes (the second for updating the size and mtime in the inode).
As for /tmp, where does Fedora mount /tmp by default? I thought all the cool kids were using tmpfs these days. Of course, Ubuntu doesn't seem to for /tmp itself, but it does for some other transient filesystems:
$ mount | grep tmp /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) /dev type tmpfs (rw,mode=0755) /dev/shm type tmpfs (rw)
varrun on
varlock on
udev on
devshm on
Program Intellivision!
forgot the best one: squashfs and unionfs. new computers are faster at using compressed filesystems than reading/writing to flash/usb.
Ever looked at squashfs?
As your Basesystem is compressed, it seriously reliefs the I/O load.
I am using an selfbuilt gentoo system on an 4GB USB stick. The stick itself is somewhat slow but squashfs really helps to have a nice running system. Changes to my System are written into an ext3 system. If that systems becomes to big i just again compress it with squashfs and put it as a layer onto my original squashfs with the help of aufs (which also serves to put the rw layer upon all the squashfs)
This procedure has also the nice point of being snapshotlike ... destroyed your system? just delete der rw overlay and everything is fine again :D
What you need to do is set up a ramdisk, copy over your files to it, mark it read-only and do a union of the ramdisk with the usb, so writes get recorded to flash but everything is read out of ram (unless it changed)
If you want a thin, snappy solution, try Puppy Linux. It loads itself into memory and runs from there.
However I have been using a full Ubuntu install on a 4GB USB drive with some modifications to optimize writes. I used unionfs to transparently overlay a ramdisk on top of some directories that are likely to be written to (/var, /etc, /home, /usr, etc). Unionfs provides a merged view of the overlaid directory and the ramdisk, while disallowing writes to the overlaid directory. What this means is that when I read a file it comes from the flash, but when I write to the file it goes to the ramdisk and not to the flash. Future reads of that file will come from the ramdisk version. So "apt-get install" writes everything to ramdisk and is super fast. If I decide later that I want to keep the updates, I can run a script that syncs the changes from the ramdisk to the flash. Of course this also means that if I don't like the updates I can just reboot and everything will be as it was before the install.
I did this based on a few web links that talked about similar things, but I haven't documented it publicly. If anyone is interested in knowing more, contact me at cc02568c at y-a-h-o-o dot com.
http://hardware.slashdot.org/comments.pl?sid=1049611&cid=25978057
See "Tubal-Cain"'s posting there. You decide.
APK
What's so important on your USB drive that you can't just shell into a server? Do you really need more than PuTTY? or maybe Xming? It seems to me like using someone elses PC to boot into your personal USB drive is against etiquette, or am I wrong by saying that?
So in other words, this guy is concerned that somebody steals his USB drive, decrypts the passwords in /etc/passwd and /etc/shadow and then does what? Find the key for his encrypted files? Which he conveniently stored on the USB drive and used a weak password so somebody COULD crack it?
Is this guy a member of Al Qaeda or being otherwise actively hunted by the CIA, FBI, DIA, MI6, Interpol, and the Mossad? Or is he a child molester with kiddie porn on his USB drive? The Treasurer of AIG?
What level of paranoia are we talking about here?
Here's the bottom line - if you have that kind of critical sensitive data on a USB drive, you're an idiot, not just a paranoid.
How many cases in this year alone have we seen of people losing critical sensitive data on USB drives?
If you can't afford to lose it or have somebody see it, don't put it there. It's that simple.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
He has some good points, but one of them doesn't really apply to USB flash drives.
(I don't know much about the SSD's, so this may or may not be relevant to them as well)
Next, the default filesystem will be ext3. You really don't want this. [...] Given the journal is in a fixed location on disk, scribbling to it every time a file gets written is a great way to wear out the flash.
This is not really correct. On a USB stick, whatever file system you use is still running on top of the USB sticks internal storage mechanism. This (should) have a built-in wear leveling mechanism, which should prevent the burn out.
HOWEVER he continues to say: "Additionally, not having to write to the journal means that you're doing less IO, which is obviously a win when it's on such slow media."
Which is a VERY valid point, not only are you doing less I/O, but you're not having to wait for the usb stick to wear-level the entire journal every time you update it.
My advice- Use the USB drive to boot and store data between sessions. Use a ramdisk for all the actual OS stuff, i.e. don't do anything that needs to do any kind of random I/O from the flash itself (swap, cache, etc).
If you're short on memory, I'd advise using 2 sticks, a secondary one for all your data so if you do burn out the stick your data is still safe on the other one.
Basically, the only time you want to write to the USB stick is when you're getting ready to shut down, and are just doing a straight write-only dump to the stick.
Once you try to search, you find Slax - the distro that answers all your questions.
As of swap file - you need 2GB of RAM to run up to 10 apps at once including office, browser and mail without even turning on your swap.
1) Fastest USB thumb drive which is rugged and has 4 GiB or more of storage?
2) Fastest SDHC card with 4 GiB or more of storage?
Thanks!
Use a compressed read-only filesystem like Squashfs. For genuinely read-only directories (like /usr) these can be used directly, for directories that need to be writable, the read-only Squashfs can be used with aufs/unionfs to make it writeable. A number of people have mentioned systems like Puppy, and that is exactly what these systems do.
Using a compressed read-only filesystem not only solves the wear-levelling problem, but it makes accesses faster because less data has to be read. It also means more data can be fitted into the flash.
Search for Squashfs, aufs/unions and flash, you'll find lots of pages explaining what to do.
In general, i don't think it is a good idea for distros to mount /tmp to tmpfs for the reason that some programs might want to write large amounts of data to /tmp, e.g. you have 512MB RAM, that makes the default tmpfs size 256MB, then you want to edit a 30 minute MP3 with Audacity, Audacity will decompress the MP3 to /tmp so it can work on it but it needs ~280MB space to do this, it will fill up /tmp then throw an error leaving the user with a problem. This is a real example because it happened to me, it's not a big deal for a user that understands the problem, but it is for a user that doesn't, and is a good argument for not making it default since the more knowledgeable users can enable it themselves anyway.
usb 3.0 is more or less out now, so wait for 3.0 flash drives to come out-- they're over 10 times faster than 2.0 (5.0 Gb/s, or 625 MB/s) ; that'll speed things up quite a bit.
also, I'd recommend jfs filesystem for the actual OS, as jfs is the best easily available (and stable) fs for small files, and linux (especially the core system) is mostly small files.
35 MB/s is 280 Mb/s, which is relatively close to the 480 Mb/s USB 2.0 limit. the advertised 480 is "theoretical"-- the average speed of usb hard drives is 20-25 MB/s. the main reason why theoretical and reality don't match up is that "overhead" is included in the speed rating- which IMO is deceptive advertising, since that kind of information is useless to consumers.
Similarly, Base-100 ethernet usually doesn't get better than 50/mbps- half the line is overhead.
here's my source: http://www.lyberty.com/tech/terms/usb.html