| 1 |
Alan McKinnon wrote: |
| 2 |
> On Tuesday 19 August 2008 15:30:07 Dale wrote: |
| 3 |
> |
| 4 |
>> Håkon Alstadheim wrote: |
| 5 |
>> |
| 6 |
>>> << SNIP >> |
| 7 |
>>> |
| 8 |
>>> I'm running the machine for multi-media-use, and I would like to make |
| 9 |
>>> sure that I tune the media-programs to leave sufficcient cpu to handle |
| 10 |
>>> the odd house-keeping task, while at the same time doing as much |
| 11 |
>>> post-processing for image and sound quality as possible. Is there a |
| 12 |
>>> way to get top to make sense, or are there other tools you good people |
| 13 |
>>> would recommend ? |
| 14 |
>>> |
| 15 |
>> The only thing I can think of that may help is to use the nice command |
| 16 |
>> to give some processes more or less priority. That may or may not help |
| 17 |
>> you any but it is a thought. |
| 18 |
>> |
| 19 |
>> Otherwise, I tend to agree with Alan. Leave it to the kernel. |
| 20 |
>> |
| 21 |
> |
| 22 |
> I thought of one thing that might help - perhaps the media apps in question |
| 23 |
> are single threaded and might benefit from a different preemption model |
| 24 |
> algorithm. Give the old-fashioned server model a try instead of desktop or |
| 25 |
> low-latency desktop. It's worth a try, YMMV |
| 26 |
> |
| 27 |
|
| 28 |
When I say "tune" I mean things like picking a resolution and a |
| 29 |
deinterlace method for video that is as good as possible, while still |
| 30 |
leaving enough headroom to avoid uneven playback. Given that a schedule |
| 31 |
update or a backup run might kick in at a bad time despite all efforts |
| 32 |
to write a good crontab, knowing when to stop is not always easy. I run |
| 33 |
all system tasks under "nice ionice -c3", and they will still cause |
| 34 |
hiccups if the system is maxed out. Looks like the good old trial and |
| 35 |
error is the only method that will work. Being on the bleeding edge, |
| 36 |
that means erring on the side of caution, or else you never know whether |
| 37 |
you have hit a system bottleneck or a bug in the software .... :-) . |
| 38 |
|
| 39 |
mplayer kept saying my system was too slow, while the cpu was idling at |
| 40 |
20%. Turns out top was correct in that instance, mplayer was |
| 41 |
misinterpreting input data, trying to play back at half the intended |
| 42 |
frame-rate. Now I'm past that hurdle and adding deinterlacing and other |
| 43 |
filters. I'll just have to hold back on the temptation to go all out on |
| 44 |
the filter options :-) |
| 45 |
|
| 46 |
Thanks for keeping me from wasting any more time with top though. |
Archives