Heads up: display system drivers may affect peformance

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have observed some oddities and I wonder if anyone have similar experiences:

We had one machine here at Atmel which lost considerable amounts of data when programming on the STK500. When measuring the deferred procedure call (DPC) latency for this machine we saw AS5 affecting this to a large degree. Actually to the degree that the UART buffer got overwritten before it could get read. An identical machine also running XP within a virtual box had no issues with performance. Yet another running win7 was also running smoothly. After updating the display driver for the problem system we saw considerable (est. 10x less startup time) over all performance improvements to AS5 and a substantial improvement the DPC-latency of the entire system. Not to mention being able to program without loosing data most of the time.

The explanation(or.. working theory anyway) is simple , but the connection was not obvious to us at the time: AS5 uses WPF as a GUI framework, which is hardware accelerated, but may not be so in VM's. The Studio shell processes a lot in the GUI thread. potentially invoking the display driver. Now, if the display spends a lot of time finding out that there was nothing new to draw, this might disrupt the entire system, and AS5 in particular. Even making the UART buffer being overwritten before it could be read out by DPC.

Please tell us if you have similar experiences! We need to get to the bottom of the massive differences in performance seen by you guys

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not into WPF much, but have to ask the basic question: Is the UI and the port code running in the same thread?

(Please answer "no"..)
(or tell me why this sanity-check Q was really stupid..)

EDIT/ADENDUM: Specifically, is the serial I/O running in it's own dedicated "worker thread"?

In The Good Old Days [tm] it used to be the other way around. Extensive processing (or I/O or some such) in the UI thread made the UI sluggish or even un-responsive.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Not into WPF much, but have to ask the basic question: Is the UI and the port code running in the same thread?

(Please answer "no"..)
(or tell me why this sanity-check Q was really stupid..)

EDIT/ADENDUM: Specifically, is the serial I/O running in it's own dedicated "worker thread"?


You always think the best of our fellow Atmel Developers? :)

To be serious, DPC's are the worker threads of a Windows kernel. They are triggered from a hardware IRQ (e.g. a graphics card or serial device). DPC's run all with the same priority, lower than an CPU Interrupt, but higher than any user thread. Inside a DPC you can only access real memory (no virtual memory) and of course there is no scheduling of user threads.

When some of the graphic card DPC's block the CPU longer than it takes for a a serial FIFO to run empty, there could be serial data loss. This would also be devastating to the whole system, and would lead e.g. to missing ethernet frames and a huge slowdown to block devices like hard disks etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks PeteAVR, that was a very good explanation of the problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You always think the best of our fellow Atmel Developers?

Actually very mixed thoughts, but I have great respect for the people working on the compilers, runtime and AS5 in general and for OKB specifically. (Don't get me started on the FLIP dabblers, though..)

And if I didn't make it clear, my speculation was a shot in the dark, based very loosely on 15 y.o. knowledge and experiences.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]