Feature request: option to set client runtime priority

Thank you for a great piece of software, it really fills the gap in my windows networks! Also it has matured considerably over a short periiod of time so it’s running very stable and reliably for me - a well deserved 1.0.

I do however have a feature request. On some windows client machines, especially older ones or ones running i/o heavy apps, but also recent, powerful machines with comparably slow storage (single spinning harddrives), it would be wonderful to have the ability to automatically lower the priority of the urbackup_backend process to something like low or idle.

Users sometimes complain to me about their machine slowing down during backups and sometimes they then pause the backup which results in no backup being competed because they forget to resume it. Restricting users from pausing backups doesn’t really remedy the base problem (besides it’s a nice to have feature when you actually need it), and running backups after hours instead is not desirable for energy saving reasons and because urbackup does not automatically shut down the client when finished. (Was that another feature request right there or am I blind? =) )

I already tried the new network bandwidth throttle mechanism introduced in urbackup 1.0 and it helps some. But during data gathering phases on the client when no or almost no data ist transmitted over the network, there is still heavy storage i/o activity on the client which impact I so far cannot influence by default. If the client ran at low priority, other processes (running in the foreground) could have their i/o needs satisfied first and urbackup would have to live with the gaps in i/o activity.

It would be nice to just be able to choose a desired priority for the service part of the urbackup client, ideally in a centralized way as part of the client settings on the server. Something like a dropdown with default windows priorities or a checkbox for low(er) default client runtime priority. The checkbox would probably be a more generic solution tailored to fit clients on more operating systems besides windows.

This is really just a minor issue, but one I think would greatly benefit your excellent software product. Please keep up the great work! (and put up a donations button on the page if you like!)

Cheers, Jannik

It is already using the lowest priority for all relevant threads (e.g. the indexing thread as well). THREAD_MODE_BACKGROUND_BEGIN here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686277(v=vs.85).aspx .

Windows prior to Windows Vista did not have IO-scheduling. Are you mainly having problems with Win XP PCs? I could set it to something like THREAD_PRIORITY_IDLE there, but it is IO bound and probably would not help. Another option would be to wait between indexing calls, but the question would be of course, how much to wait (which would depend on the speed of the disk and on how many other processes are accessing the disk which is information only the OS has).

Thanks for using it. There is a donation button on the SourceForge project page: https://sourceforge.net/projects/urbackup/

Thanks for your quick reply! Yeah, it’s XP clients that are the ones getting bogged down during backups.

I still think lowering the thread priority might help some on those clients, even if it technically doesn’t affect i/o scheduling. I’ve seen it used in a variety of products on XP and 2003 machines, mostly backup stuff for databases and the like. And since it is the only option that is easily available without implementing some logic of your own as you suggested, why not give it a try?

I’d be willing to test it on a couple of machines and collect user feedback. Windows XP is still going to be around for some time, especially in office networks with low-powered clients. Every little would help with those, I think.

Sure.
Here is a version were I set the relevant threads to THREAD_PRIORITY_LOWEST. I did not set it to IDLE because then they would starve in my test.
https://sourceforge.net/projects/urbackup/files/Client/1.0.1RC/

Uhm, sorry for not replying. Forum notifications got stuck in the spam filter. I just checked back manually because it was still on my todo list. Sorry again.
I really appreciate your efforts, I’m going to test the RC on two XP networks on a subset of clients and post my findings here. It might take a week or so, I’d like to see what user feedback is on this one.