c# .NET Serial Driver performance

My application needs to communicate with a embedded device which is about 1MHz clock speed, through serial communication. In the mid of that process, we found that we were missing some data from the device.

So, I began testing the performance of the serial driver that I used. The device keeps on sending raw data with counter increased for each packet at a Baud Rate of 115200 bits/sec. When connected to hyper terminal and ran whole night we found that it is not missing any data.

But when I used the c# serial driver with DataReceived handler and a parser written to find whether packets missed or not, we encountered situations like

1) Missing of packet 2) Buffer over run error.

I am not able to come to a conclusion. I want all of your views on the data available.

Is it a test which stretches the boundaries of any Serial Device drivers ? Or the way .NET serial driver written is not up to the mark?

The way I have implemented is very simple. I have just used a DataReceived handler and updating the data to a List, which inturn is used by a parser running in a different thread with highest priority. The functio开发者_如何转开发nality done with in DataReceived hanlder is nothing but adding the received data to the list.

Thanks in Advance

---

The way I have implemented is very simple. I have just used a DataReceived handler and updating the data to a List, which inturn is used by a parser running in a different thread with highest priority.

This is probably your problem. The parser is likely CPU-bound, which means sticking it on Highest priority means that it will consume the vast majority of CPU cycles until it runs out of stuff to parse, and so your DataReceived thread is starved of execution and ends up missing stuff.

In short, don't fiddle around with priority unless you know what you're doing. Set the priority back to normal and you'll get better results.

---

Using a List to communicate between two threads is a bad idea since it's not thread safe (unless you have locks around it - do you??). Use a ConcurrentQueue<T> if you are using .NET4.

Also, as Anon points out, high priority threads are rarely the right answer. In this case, your parser should, if anything be running at below normal priority since it's job is just to consume the Queue without affecting any other thread that might be doing I/O. You can keep an eye on the Queue length in the parser thread and issue warnings if it's getting left too far behind.