Please let me know if you are able to measure :
Also look at the following thread where Geir did make some measurements with the same code:
I made the measurement today with the while loop in the C code, and the line commented, and I reached 321 kHz, even though the board is stucked in the program again and I have to reset the firmware to get it functionnal again.
That’s far better than before 
Is there any way to avoid to have to flash the firmware every time ?
Glad that you are able to see higher speeds. I just wanted to drive home the point that the chip is running as fast as it can, however on a NETMF system it is not about running just one tight loop. There are processes like GC, debugger communication that work in the background. When you code executes a RLP method it blocks everything else till completion and return.
Using a delay will prevent this by relinquishing control and providing a chance for the other threads to run. You need to experiment and choose a delay value that is a tradeoff.
Alternatively you can check for a trigger (e.g. a button press) to exit the loop or call the delay).
Okay, thx for the help.
We tested it furthermore today, so it seems that the processor is currently running at 72 MHz, but as you said the access to the pin is very slow, we assume that the RLP process goes back to the CLR when trying to access a pin. That’s why we can’t go faster than 320 kHz for toggling a led 
We tested some more “computational” operations like big loops in RLP and it’s getting far faster that toggling a pin.
Basically what we need to do to write an image in the ram is toggling our pins very fast to control it, considering that we unfortunaly have to give up with the panda board, we will do it with an AVR board which can be programmed with native C.
We even thought about flashing the .net framework but we assume that it would not be possible to program the board though USB afterward 