EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Performance and other issues

Posted: 05/12/2014 03:31:28
by Ivan Russell (Basic support level)
Joined: 05/11/2014
Posts: 3

I was playing around with the CBFS sample applications on Windows 7 x64, and found a few minor issues, and one which gives me greater cause for concern.

Minor issues:

(1) VDisk_VS2008 x64 Release build doesn't link (wrong library path). This is easily fixed so it's hardly worth mentioning.

(2) Run VDisk, mount drive, copy executable file "hello.exe" to the drive, open a Windows command prompt, cd to the drive, type "hello": 'hello' is not recognized as an internal or external command, operable program or batch file. Hmm.

(3) Copy EldoS installation folder to the new drive, try to build sample projects: not possible. Lots of 'No such file or directory' or 'Could not delete temporary file' messages from visual studio. I suspect this is somehow related to issue (2).

Major issues:

(4) Copy 8GB of miscellaneous files and folders to the drive: throughput is 3MB/s - normally I get 500MB/s from SSD. This seems like a potentially more serious problem, and before I dive deeper, I wonder if you can provide some hints: e.g. if the problem is due to inefficient implementation of vdisk sample (which is fine for sample code), or fundamental issue of CBFS layer.

(5) Switch to Mapper sample, try the same tests again: Issues (2) and (3) are resolved, and now I get 125MB/s. This is definitely an improvement, but I would still rather see closer to 500MB/s. Again, any hints? I am happy to put in the time if the sample code can be improved.

Thanks and best regards,
Posted: 05/12/2014 06:01:41
by Eugene Mayevski (Team)

Thank you for contacting us.

First of all, we recommend testing everything with Mapper sample. VDisk shows how to implement a disk in memory and it has lots of extra code. Mapper passes all filesystem requests to the host filesystem, so it has less overhead and less glitches that need investigation and/or explaining.

(2) it's possible that the combination of filesystem name and flags/attributes prevents the executables from being run by the OS (the OS has some restrictions on running EXEs from unknown sources and disks). Try Mapper sample.

(4) Please try measuring speed with Mapper and also check this article: https://www.eldos.com/cbfs/articles/7979.php

Sincerely yours
Eugene Mayevski
Posted: 05/12/2014 09:09:23
by Ivan Russell (Basic support level)
Joined: 05/11/2014
Posts: 3

Thanks for your quick response.

Regarding the performance issue, I'm not entirely convinced by the 'context switching overhead' argument. Reason as follows:

I can write an app in user space, which reads in blocks of 64KB from one SSD, processes the data (lightly!), and writes out to another SSD, achieving 500MB/s or an average rate of 125ns/block. I believe this rate to be largely limited by the speed of the SSD.

I'm not an expert on kernel drivers, which is why I'm here in the first place, but the number of context switches required in this example does seem at first glance to be the same as required by Mapper sample, which also passes the data through user-space.

To go from 500MB/s to 125MB/s, something in the kernel/CBFS layer must be consuming an additional 375ns per 64KB block. Is it possible to explain what that is, without divulging too much about your proprietary IP? Or even better, reduce it somehow? Please excuse my persistence, but for my application, data throughput does matter.

Thanks and best regards,
Posted: 05/12/2014 09:45:34
by Eugene Mayevski (Team)

I am sorry but you will need to review your requirements or give up with the idea.

Sincerely yours
Eugene Mayevski
Posted: 05/13/2014 02:23:55
by Eugene Mayevski (Team)

To elaborate a bit:

first of all, your calculation is not correct. Mapper does 6 context switches *just to read or write the data*, and if you do copying, this reading or writing is just one part of the operation, so you need to add several more switches. When you copy the data from one actual disk to another, you have 4 context switches in *total*.

Next, there are some extra data copy operations involved in your case and they also cost resources (CPU time).

Finally, when working with virtual disk CBFS needs to acquire certain global locks which are not necessary for the regular filesystem driver. This surely slows down operations, but acquiring those locks is mandatory, because Windows was not designed for things like CBFS and hat we do are all hacks.

So as I said, there's not much room for speed improvement so you need to either reconsider your speed requirements or find ome other approach which doesn't involve a virtual disk.

Sincerely yours
Eugene Mayevski
Posted: 05/16/2014 19:49:05
by Ivan Russell (Basic support level)
Joined: 05/11/2014
Posts: 3

Thank you for elaborating, much appreciated.



Topic viewed 2379 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!