.NET behaviour / performance

[watarat]

I am new to .NET totally, but it looks like Microsoft have created "Borland Builder/RAD studio for embedded", but hung it on C#.

I have the usual unanswerable questions about .NET performance for Real World apps. (Separate to processor speed issues)
I know that MS say it is not a Real Time operating system - but everything is realtime in some way - e.g. an MP3 player has to keep up or its a dud.
(Its just that the consequence of failing is relatively small - unlike a real data collection process)

So if I want to - say build a data logger - data coming in serial or parallel, and writing to USB drive.
Will that run "continuously & reliably" at some (hardware/CPU dependent) data rate - or will it experience periods of missing data due to .NET behavior when - maybe the garbage collector comes around or somesuch? (As distinct from a drive response induced issue which is nothing to do with .NET)

One would take all the usual precautions - seperate logging thread, 'erase sector size' writes, dual buffers etc etc - and practically no activity in the main thread...

I anticipate that the Runtime Loadable Procedure might be the key to improving performance, but assume that this would still be liable to be diverted by other CPU consuming tasks in the Framework?

The advantage I see of the .NET framework in this situation is in the ability to quickly code up HTTP/FTP download of data - graphical review etc etc when not in the process of doing the hard and fast work.

Does anyone have any experience to give ballpark figures on - say writing to USB/SD for any of the GHI family of cards?

What I am worried about is an app that will do something like
  Log at 100kBytes/second for a minute or so - but then fall over   
  Log at 65kBytes/second for an hour or so - yep - all good - ship it ...
  Still fall over at 20kBytes/sec if you try and run it for 48Hours.

Any vaguely relevant comments or experience appreciated. ...

R

[SupportAdmin]

I have the usual unanswerable questions about .NET performance for Real World apps. (Separate to processor speed issues)
I know that MS say it is not a Real Time operating system - but everything is realtime in some way - e.g. an MP3 player has to keep up or its a dud.
(Its just that the consequence of failing is relatively small - unlike a real data collection process)

Not real time doesn't mean the system is unstable. The only thing Micro Framework will not do is lets say you are controlling a machine and you *MUST* set a pin high in 10uS or less. Micro Framework will set the pin high but maybe in 500uS or 10mS....up to maybe 50mS.
Now, if you are making an automated home and the fan comes on 50mS late then no one will notice but in some cases, 10uS late is way too late!!
With that said, many things are done in interrupts internally in real time but your C# code is not real time

So if I want to - say build a data logger - data coming in serial or parallel, and writing to USB drive.
Will that run "continuously & reliably" at some (hardware/CPU dependent) data rate - or will it experience periods of missing data due to .NET behavior when - maybe the garbage collector comes around or somesuch? (As distinct from a drive response induced issue which is nothing to do with .NET)

It will work perfectly!! and we have already done a GPS data logger to a customer in ONE day that fit all customer needs. You will never be able to do the same in one day without micro framework.

One would take all the usual precautions - seperate logging thread, 'erase sector size' writes, dual buffers etc etc - and practically no activity in the main thread...

You do worry about any of this. We take care of it all. All you do is open files and write data...just like how you would do it in a PC

I anticipate that the Runtime Loadable Procedure might be the key to improving performance, but assume that this would still be liable to be diverted by other CPU consuming tasks in the Framework?

RLP is perfect if you are doing something like calculating CRC where ti will be about 10,000 faster to do it in C/Assembly vs C#. But this is for very specific and high compututional procedures. In usual cases, you do not need RLP. Have you seen the project website?
http://www.microframeworkprojects.com/

The advantage I see of the .NET framework in this situation is in the ability to quickly code up HTTP/FTP download of data - graphical review etc etc when not in the process of doing the hard and fast work.

Micro Framework is not for everything, same as Linux or windows! Depending on your project, Micro Framework maybe the best option around.

Does anyone have any experience to give ballpark figures on - say writing to USB/SD for any of the GHI family of cards?

What I am worried about is an app that will do something like
  Log at 100kBytes/second for a minute or so - but then fall over   
  Log at 65kBytes/second for an hour or so - yep - all good - ship it ...
  Still fall over at 20kBytes/sec if you try and run it for 48Hours.

You should have no problem doing the project above. Our continuous data write rate is over 100KB/sec. There are many variables that affect this like the fragmentation and the quality on the media you are using. Keep in mind that you have *millions* of bytes that are free for you to buffer your data


I recommend you get a system and you get more familiar with Micro Framework. Then you can decide if Micro Framework is a good fit for your project or not.
Another option is ot tell us what you want to do and we can tell you if the project is a good fit for Micro Framework or not

[watarat]

Firstly thanks for prompt and comprehensive reply.

Let me try and talk my way through a project - and see if I got it right.

Say we start with a source of data - lets bring it in the serial port at 1Mb/s, and I'm writing in the order of 100kBytes/sec to a drive.
Logging that to a disk isnt much more than.

while(i'm not bored) {
   read(bigbuffer)
   write(bigbuffer)
}

And your low level routines will take care of that.

Suppose I wish to bring the data in a 16bit wide parallel port made from GPIO's
Then I probably arent going to be able to service the handshaking in C# much more reliably than in the ms area, as my task might not be scheduled to run for 20ms - and I would miss data - effectively a 20ms gap in my polling.

The solution would be to get 'somebody' to write a low level driver for my parallel bus (interrupt driven) and hook it into the framework.
Then I could go back to the original scheme?

Question - who is 'somebody' - can I write that and add it in to your existing framework, or would I need you to add it in to the whole package?

So - suppose I then want to "look at the data" - maybe I want to scan it for some event, or block it up into 1s chunks with a header on it.
If I try and look through the 100k buffer in C# - then I might be pushing it - this is where RLP would come in??

Suppose we add a GPS to timestamp the data (supported serial input at say 9600bit/s) - maybe my routine looks like

while(i'm not bored) {
   read(bigbuffer)
   read(gps)
   RLP_mungeWithData()
   write(mungedData)
}

RLP_mungeWithData() obviously has to be able to handle whatever it is passed and make sense of it, and will be the usual mess of C handling pointers buffer realignment etc.

Am I vaguely on the right track??

R

[SupportAdmin]

Yes you got it correct. With RLP you will probably never need us to add anything but if you needs us then we are available

[watarat]

OK - sounds like it may well solve some problems for me.

Just to be clear - so long as the data comes in via 'supported' hardware (a serial or USB port for example) things will be approx as fast as the port, and you can write some 'fast' RLP code to deal with it. (caveats on processor speed and peripheral behaviour of course)

RLP however wont help you where you might want to  - in conventional terms - write an interrupt driven port handler.
That would need to be implemented as part of the Framework - and I am not clear on this - that would need to be done as part of the whole package by - e.g. yourselves? OR Is it possible to link in such a module separately?

Thanks for info.

R

[SupportAdmin]

Good question. You actually can install RLP interrupt handler! We are inverstigating this and once we have it tested well, we will post some examples online.

You would need us only to change features right into the port. For example, some customer requested that we do not control the watchdog our selves so he can control it anyway he likes and so we made the change free of charge. Another customer requested that we return the port number of the USB device connected to our USB host controller, we did so with no charge. Another customer just requested support for 640x480 displays and we are doing so now and there will be no charge!

[gentledepp]

Hi!
I am sorry for writing to this post. I surely could have opened another thread, but I've just a simple question:

@SupportAdmin: You wrote

Not real time doesn't mean the system is unstable. The only thing Micro Framework will not do is lets say you are controlling a machine and you *MUST* set a pin high in 10uS or less. Micro Framework will set the pin high but maybe in 500uS or 10mS....up to maybe 50mS.
Now, if you are making an automated home and the fan comes on 50mS late then no one will notice but in some cases, 10uS late is way too late!!
With that said, many things are done in interrupts internally in real time but your C# code is not real time

I would highly appreciate if you could tell me where I can find some documentation about the fact, that the C# code is not real-time as I need a source for the technical report I am writing.
Thanks in advance!

Alex

[support]

.NET Micro Framework is not real-time. and this is not related to the C#. Microsoft C# is used in many other environments.
you can easily get all the information you want from Microsoft's website.

but any way check this page for .NET Micro Framework FAQ: the second question is yours

http://msdn.microsoft.com/en-us/netframework/bb267264.aspx