Pocket PC Forum / Developers / WinCE Programming / February 2010
RAM or ROM directories
|
|
Thread rating:  |
Tommaso - 30 Jan 2010 15:22 GMT Hi, In my OS Design I've compression enabled and RAM and ROM file system. I'm new to CE and it's not clear to me which dirs are placed in RAM and which in ROM. If I copy files to \Windows or \Temp dirs: it takes quite long and after power off on they're lost. As it takes long I could say "these dirs are in flash mem" but as they're lost I should say the opposite. Unless it's due to compression and the dir I see are a mix of ram and flash?
If I copy files to \NandFlash dir: it takes about the same but after power off on files remain.
Regards Tommaso
Paul G. Tobey [eMVP] - 30 Jan 2010 16:05 GMT When you use RAM&ROM, \windows is a combination of the files buillt into the OS image (files listed in your BIB files for the build), and whatever you copy to the overlayed RAM filesystem. It's all either permanently present (ROM), or non-persistent (RAM). There is no persistent filesystem there.
It seems like, if you designed this OS, you should understand what parts of the filesystem are persistent and which are not. After all, you're the one who set that all up.
Paul T.
> Hi, > In my OS Design I've compression enabled and RAM and ROM file system. [quoted text clipped - 11 lines] > Regards > Tommaso Tommaso - 30 Jan 2010 19:21 GMT Hi, I've got an evaluation board with a BSP already present and a list of steps to make the OS Design, so I didn't design that by my own. What about the time taken to make a copy (about 2 secs for 1MB on an ARM 600mhz)?
> When you use RAM&ROM, \windows is a combination of the files buillt into the > OS image (files listed in your BIB files for the build), and whatever you [quoted text clipped - 24 lines] > > . Paul G. Tobey [eMVP] - 31 Jan 2010 21:35 GMT That will depend on the type of RAM/flash, how the RAM/flash is interfaced, the code in the driver and potentially the code in the BSP itself. Flash writing is an I/O-bound process, so the speed of the processor probably has little to do with it. RAM writing is, I think, largely processor bound. It doesn't seem wildly outrageous to me, depending on the source of the copy which you didn't tell us, that you'd get that sort of speed. You could give us some more information and maybe someone has a parallel experience to compare. 600MHz would be faster than any production processor I've used in the ARM line.
Paul T.
> Hi, > I've got an evaluation board with a BSP already present and a list of [quoted text clipped - 40 lines] >> >> . Tommaso - 01 Feb 2010 08:46 GMT Hi, I simply copied by Copy & Paste, for example from \Temp\myfile to \Windows\myfile. If I try with a simple C appl via fopen,fread and fwrite, I see it be slow until memory pages are only reserved but not used, and very fast then. I mean, If I read twice a 10MB files (very larger than any cache) to the same buffer, the first time it'0s slow and the 2nd very fast. I don't know how WinCE implements Copy & Paste
> That will depend on the type of RAM/flash, how the RAM/flash is interfaced, > the code in the driver and potentially the code in the BSP itself. Flash [quoted text clipped - 54 lines] > > . Paul G. Tobey [eMVP] - 01 Feb 2010 14:56 GMT There is no copy and paste at the filesystem level. If you copy a file and paste the file in the filesystem somewhere, a CopyFile() call is almost certainly what happens behind the scenes. Explorer is doing that. Windows CE isn't going to do something fancy for that kind of an operation. What are the numbers? Fast and slow don't mean anything. How much RAM do you have devoted to the RAM filesystem? If Windows CE is having to move the program RAM/filesystem RAM boundary around while you're doing this, I have no doubt that will slow it down...
Paul T.
> Hi, > I simply copied by Copy & Paste, for example from \Temp\myfile to [quoted text clipped - 63 lines] > > > > . Tommaso - 02 Feb 2010 07:42 GMT Hi, I've 30Mbytes free in the RAM file system, ARM 600Mhz DDR 166Mhz: it takes around 1sec for copying 1MByte. Tommaso
> There is no copy and paste at the filesystem level. If you copy a file and > paste the file in the filesystem somewhere, a CopyFile() call is almost [quoted text clipped - 74 lines] > > > > > > . Paul G. Tobey [eMVP] - 02 Feb 2010 23:59 GMT OK, so I think to get real information, you'll have to verify the exact time to complete the copy. I have whipped up a program to create a file, copy it, and calculate how long it took. On my development machine with a very fast hard disk, it was about 10-12ms. Don't have a Windows CE device with RAM filesystem enabled to try, but give it a try yourself and let us know what results you get (note that I didn't create a method to get the data, other than the debugger, so you'll have to enhance it for CE a bit).
While you're at it, tell us some more information about this build:
Windows CE version? DEBUG or RETAIL build? if RETAIL build, is the BSP outputting RETAIL messages? if DEBUG build, are you connected to Platform Builder for kernel debug, RELFSD directory access?
Paul T.
-----
// copyspeed.cpp : Defines the entry point for the console application. //
#include "stdafx.h"
#include "windows.h"
#define SOURCE_FILE _T( "\\testfile.txt" ) #define DESTINATION_FILE _T( "\\testdestination.txt" )
char _16bytes[] = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F' };
int _tmain(int argc, _TCHAR* argv[]) { // Create a 1MB file. HANDLE hf = CreateFile( SOURCE_FILE, GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL );
// Write the data. for ( long i = 0; i < 1024*16*4; i++ ) { DWORD count; WriteFile( hf, &_16bytes[0], 16, &count, NULL ); }
// Close the file. CloseHandle( hf );
// Delete the target file. DeleteFile( DESTINATION_FILE );
// Copy the file, after counting the ticks. DWORD startTick = GetTickCount();
CopyFile( SOURCE_FILE, DESTINATION_FILE, FALSE );
DWORD endTick = GetTickCount();
DWORD ticks = endTick - startTick;
return 0; }
Tommaso - 03 Feb 2010 09:24 GMT Hi, I tried, it takes several secs to create the file, then it takes a variable time from 300 to 800 ticks. I have WinCE 6.0, RETAIL build, I can see RETAIL msg. I dont' know what RELFSD directory access exactly is, sorry. Thanks
> OK, so I think to get real information, you'll have to verify the exact time > to complete the copy. I have whipped up a program to create a file, copy it, [quoted text clipped - 59 lines] > return 0; > } Paul G. Tobey [eMVP] - 03 Feb 2010 15:39 GMT That's longer than I would expect, but not outrageously long, I think. 10x what the desktop can do seems pretty reasonable. This is 30x to 80x. You were NOT running the code in the debugger, right? That might really slow things down.
RelFSD is a driver that you can put in your OS, typically just a DEBUG build, that makes the flat release folder on the Platform Builder computer appear as a folder on the device. This allows you to modify, for example, a driver, compile it on the PB computer, then get the device to load it, all without regenerating nk.bin and reflashing the device. Because it appears in the filesystem, I wanted to be sure you weren't using it.
If it were me, at this point I'd evaluate how important this is. How often does this happen on the device when it's running in the field? Can I change how other code works to minimize the effect of this or reduce its frequency. If RAM filesystem is slow and flash is actually faster (which seems impossible), can't I change what I'm doing to use the faster media? If none of that is possible, I guess that a support incident with MS is the next step. I don't see anything else that you could be doing "wrong" (minor improvements might be possible depending on how your processor talks to the RAM and what settings are configured for that).
Paul T.
> Hi, > I tried, it takes several secs to create the file, then it takes a variable [quoted text clipped - 66 lines] > > return 0; > > } Tommaso - 08 Feb 2010 15:23 GMT Hi, I'm not running the code on the debug. I'm not using RelFSD. I was testing the copy of file just to have an idea of what I could expect in terms of performance by my DDR, supposing that the WinCE CopyFile was very optimized. But I was wrong. It's not a big problem for my appl itself, as I will do differently. At the end I became just curious to understand why CopyFile is slow. Thanks Tommaso
> That's longer than I would expect, but not outrageously long, I think. 10x > what the desktop can do seems pretty reasonable. This is 30x to 80x. You [quoted text clipped - 90 lines] > > > return 0; > > > } Paul G. Tobey [eMVP] - 08 Feb 2010 16:09 GMT I don't think it makes sense to say "I want CopyFile to be optimized". How? All it can do is read the input file and write the output file. I guess that you could build your own version that might be fractionally faster than the default, but this has to work with all filesystems on any Windows CE device that can run the standard shell, so the amount of fooling around to get that extra 5-10% performance is pretty limited.
Paul T.
> Hi, > I'm not running the code on the debug. I'm not using RelFSD. [quoted text clipped - 100 lines] > > > > return 0; > > > > }
|
|
|