I'm working on a quite big application that is in charge of doing real-time motion tracking and camera movement controlling. Its tasks are:
Motion tracking (done by a native module, which decodes a video stream from a network camera and supplies both image buffers as big as 1280x720 pixels and the tracking results to the managed application via callbacks)
Receiving positioning feedback data from and sending movement data to a pan/tilt hardware about 20 times a second as well as zoom commands from/to the camera
Displaying the image data including live visualizations
Encoding and writing of the image and session data
Automatic postprocessing of the video is done by another process
The application uses .NET 4.0 and has a WPF user interface.
Managed threads freezing
From the beginning we had to face managed threads that freeze for between 500 to 1500ms, which is really much for a real-time application like this.
To find out when these hangs occur I created a thread whose only task is to do a sleep for 100ms all the time. I then calculated how long the sleep really took and got exactly the times when the camera movement stopped. It works very reliably, the threads all hang at the same time!
Unmanaged threads don't freeze
While all the managed threads freeze the unmanaged threads work without any problem. We check that by logs that are written independent from the managed part of the application.
Analysis
I tried to figure out with phenomenons could maybe cause this behaviour:
The whole machine slows down when we encounter these problems: Windows is responding very slowly (e.g. directory listings hang for half a minute in both Windows Explorer and my application, or launching applications takes incredibly long)
We read and write thousands of files at the same time (the tracking and postprocessing application), maybe this overcharges windows
The response of the GUI becomes very slow
The app uses about 1.3GB of virtual memory (according to Process.VirtualMemory64) / 500MB of working set memory (Process.WorkingSet64) - could it be that some of that is swapped onto the harddisk? (How can that be checked or solved?)
Of course if we kill the process Windows is responding fast again, but it takes Windows a while to be responding normally again
Hints on how to investigate into this would be highly appreciated. Thank you very much!
Maybe GC is working?
See the great article: http://samsaffron.com/archive/2011/10/28/in-managed-code-we-trust-our-recent-battles-with-the-net-garbage-collector
I would suggest taking a process dump as you are encountering the performance problem. You can do this several ways (taskmgr.exe or procdump.exe from SysInternals). Take a full memory dump.
Once you have the .dmp file, you can analyze it with windbg (or Visual Studio 2010). For managed processes you need to load the sos.dll extensions.
There are a lot of good windbg resources out there, but here are a few that have helped me:
1) Tess Fernandez video (ASP.NET process, but the techniques are the same)
2) WinDbg cheatsheet
The memory analysis will be able to give you the stack (!clrstack) while you are encountering the problem and tell you the exact culprit.
Related
I have a lot of console applications that run in a scheduler every 10 mins, I see the console applications are completing successfully, all the objects in the code are closed and disposed as needed. I ran processexplorer, perfview, process monitor and was not able to identify any applications hanging around.
But I see all my applications (1000's of them) are showing up in RAMMAP process section all of them with 4K Private bytes, please see screen shot attached.
Please advise is this normal or do i have a potential leak in all my applications? any tool that can be recommended to identify/resolve this issue?
Thanks
Good worktime!
I'm writing C# warp around Sony Remote API, using Android test app as an example.
There became a problem with Liveview.
I start liveview streaming by the API method "startLiveview". Liveview data consumer works in a separate thread and it simply passes through frames if there's no time to draw them all (just like in the test app, as far as i understand).
However, after the startLiveview method is processed and fetching stream is started, the camera experience some difficulties with all other API commands processing in time.
E.g., after my warp discovers the camera and connects to it, performs startRecMode and so on, it can take pictures very fast. However, since liveview is started, the camera can't process all actTakePicture calls in time. There can be seconds or even dozens of seconds i have to wait before the shutter clicks.
I've tried to stop liveview before starting picture taking. It doesn't matter - stopLiveview command experiences the same problem, it takes even minutes to process it (there are minutes to return from System.Net.WebClient.UploadString).
I've tried to use startLiveviewWithSize instead of startLiveview and to pass the smallest size available (there is "M" with Sony A7R i'm using). No result.
What can i do to successfully stop the liveview or, as a max wish, to get rid of performance penalties when the liveview is on?
Thank you in advance!
p.S. Using MS VS 2010, .NET Framework 3.5, Sony ILCE Alpha 7R camera, all preprocessing settings found are switched off.
I'm having a problem with timing in XNA 4.0, writing in C# and using Visual Studio 2010 express.
I'm not writing a game exactly, but I'm trying to use XNA for it's simplified content pipeline, drawing, and timing. What I'm trying to do is write a program that can time a user's response to onscreen stimuli at very fine resolutions - less than 5 ms, ideally.
To do this, I need to call the update routine (so I can poll the keyboard) no less than once every 5 ms. Even in variable step timing, I can't get the timing below about 16 ms per call. This doesn't appear to have anything to do with the amount of processing that I do in my update and draw routines. I can comment out everything in both routines and the program still spends roughly 16.66 ms on each iteration.
In fixed step timing, I can set the target to about 60 iterations per second (16.66 ms between updates), but if I try to go any faster than that, the IsRunningSlowly flag is tripped, and the game seems to try to compensate - several iterations will run faster than 60 iterations per second, and then 1 iteration will run slower.
So I guess my question is this: is the 60 iterations per second the upper limit for XNA? Is it possible to circumvent it? Should I just ditch XNA altogether?
I really appreciate your time and knowledge. Thanks in advance.
The problem you are having is due to VSync. Disable it in XNA by adding this line to your game's constructor (assuming you have the default GraphicsDeviceManager graphics):
graphics.SynchronizeWithVerticalRetrace = false;
This will allow your game to run "fast as possible". This should be "good enough" for your purposes.
See this blog post for a description of timing in XNA.
If you wanted to get more fancy: For XNA on Windows I would consider using the Windows event loop and a high resolution timer directly. Note that Game in XNA (on Windows and Xbox 360) is entirely optional.
You'd want to move as many slow operations (eg: update and draw) and blocking operations (eg: vsync) off the main thread. Note that input in XNA can only be handled on the main thread. I think you can create the graphics device on a separate thread - although I have never tried it.
You should note that, if you are measuring reaction times, there is lag in between sending a "present" command to the GPU, and that content actually appearing on screen.
I'm not expert to XNA development, but, I know I have already similar "problem" in windows phone. (slowly problem).
When you have a lot of treatment, use multithreading programming,,
msdn : "Applications that use multithreading are more responsive to user input because the user interface stays active as processor-intensive tasks execute on separate threads. Multithreading is also useful when you create scalable applications, because you can add threads as the workload increases. "
Hope I help you...
What options are available in C#/.NET to get the status of an installed printer? The only information we need is if the printer is on or off (we have a little indicator on the screen that says 'Printer ready' or 'Printer offline').
Our application is a small client running on an embedded PC. We've found that the WMI Windows process is running out of memory. Watching it on my development PC there appears to be a memory leak as the amount of memory it uses slowly creeps up. On an embedded device with limited memory this is unacceptable and we're finding after a couple of hours the application crashes.
I would try to resolve the memory leak, but if you cant find it, you could always use PInvoke calls (specifically GetPrinterData). See an example here (Note: There are also WMI posts that could help you compare what you have and see if you can find the memory leak)
It's hard to put this into the title, so let me explain.
I have an application that uses Direct3D to display some mesh and directshow(vmr9 + allocator) to play some video, and then send the video frame as texture to the Direct3D portion to be applied onto the mesh. The application needs to run 24/7. At least it's allowed to be restarted every 24hours but not more frequent than that.
Now the problem is that directshow seems to be giving problem after a few hours of playback, either due to the codec, video driver or video file itself. At which point the application simply refuse playing anymore video. But the Direct3D portion is still running fine, mesh still displayed. Once the application is restarted, everything back to normal.
So, I'm thinking of splitting the 2 parts into 2 different process. So that when ever the video process failed to play video, at least I could restart it immediately, without loosing the Direct3D portion.
So here comes the actual question, whether it's possible to pass the texture from the video player to the direct3d process by passing the pointer, aka retrieve the texture of another process from pointer? My initial guess is not possible due to protected memory addressing.
I have TCP communication setup on both process, and let's not worry about communicating the pointer at this point.
This might be a crazy idea, but it will work wonder of it's ever possible
Yes you can do this with Direct3D 9Ex. This only works with Vista and you must use a Direct3DDevice9Ex. You can read about sharing resources here.
Now the problem is that directshow seems to be giving problem after a few hours of playback, either due to the codec, video driver or video file itself. At which point the application simply refuse playing anymore video.
Why not just fix this bug instead?
If you separate it out as a separate process then I suspect this would not be possible, but if it were a child thread then they would have shared memory addressing I believe.
Passing textures doesn't work.
I'd do it using the following methods:
Replace the VMR with a custom renderer+allocator that places the picture into memory
You allocate memory for pictures from a shared memory pool
Once you receive another picture you signal an event
The Direct3D process waits for this event and updates the mesh with the new texture
Note you'll need to transfer the picture data to the graphics card. The big difference is that this transfer now happens in the Direct3D app and not in the DirectShow app.
You could also try to use the VMR for this. I'm not sure if the custom allocator/renderer parts will allow you to render into shared memory.
Maybe you could use the Sample Grabber in your DirectShow host process to get the image as a system memory buffer. Then you could use WriteProcessMemory to write the data into a pre-agreed address (which you setup over TCP or something) in your Direct3D app.