[hlds_linux] Renice process bug
Hi, How hard is it to FIX the bug which causes CPU going to 100% usage after renicing the process? It was added in the last optional update, just like this last one. -ICS ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
After renicing to what? On Fri, 2006-04-21 at 09:20 +0300, ics wrote: Hi, How hard is it to FIX the bug which causes CPU going to 100% usage after renicing the process? It was added in the last optional update, just like this last one. -ICS ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
To anything from default? -1, 1, -20. Always the same CPU 100% if process is being reniced. John Sheu wrote: After renicing to what? On Fri, 2006-04-21 at 09:20 +0300, ics wrote: Hi, How hard is it to FIX the bug which causes CPU going to 100% usage after renicing the process? It was added in the last optional update, just like this last one. -ICS ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
You sure it's not just a matter of just being reniced? i.e. nice -10 gives 100% utilization, but nice 10 does not. On Fri, 2006-04-21 at 10:11 +0300, ics wrote: To anything from default? -1, 1, -20. Always the same CPU 100% if process is being reniced. John Sheu wrote: After renicing to what? On Fri, 2006-04-21 at 09:20 +0300, ics wrote: Hi, How hard is it to FIX the bug which causes CPU going to 100% usage after renicing the process? It was added in the last optional update, just like this last one. -ICS ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
Why would anyone want to renice it below 0 to 1-19 which would make it run slower than the default process priority 0? The fact that it puts cpu on 100% stress while its being reniced to -1 - -20 is a problem. Since someone would ask why i would want it to be for example -20 is that not all users run only gameserver on their box. -ICS John Sheu wrote: You sure it's not just a matter of just being reniced? i.e. nice -10 gives 100% utilization, but nice 10 does not. On Fri, 2006-04-21 at 10:11 +0300, ics wrote: To anything from default? -1, 1, -20. Always the same CPU 100% if process is being reniced. John Sheu wrote: After renicing to what? On Fri, 2006-04-21 at 09:20 +0300, ics wrote: Hi, How hard is it to FIX the bug which causes CPU going to 100% usage after renicing the process? It was added in the last optional update, just like this last one. -ICS ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
As I understand the process scheduler, it there's no real difference between, say, nice -10 and nice -20 in most cases. On my system, the highest-priority threads are some kernel threads, and they're running at -5 right now; thus it would make no difference if I reniced a process -10 or -20, as they would pre-empt even those kernel threads either way. Thus the trying of different levels. Try, say, -20, -5, 0, and 5 multiple times, and wait a minute or between switches. See if it's actually the process of renicing that spikes it, or just the fact that you're prioritizing that process. On Fri, 2006-04-21 at 10:37 +0300, ics wrote: Why would anyone want to renice it below 0 to 1-19 which would make it run slower than the default process priority 0? The fact that it puts cpu on 100% stress while its being reniced to -1 - -20 is a problem. Since someone would ask why i would want it to be for example -20 is that not all users run only gameserver on their box. -ICS John Sheu wrote: You sure it's not just a matter of just being reniced? i.e. nice -10 gives 100% utilization, but nice 10 does not. On Fri, 2006-04-21 at 10:11 +0300, ics wrote: To anything from default? -1, 1, -20. Always the same CPU 100% if process is being reniced. John Sheu wrote: After renicing to what? On Fri, 2006-04-21 at 09:20 +0300, ics wrote: Hi, How hard is it to FIX the bug which causes CPU going to 100% usage after renicing the process? It was added in the last optional update, just like this last one. -ICS ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
ics wrote: Why would anyone want to renice it below 0 to 1-19 which would make it run slower than the default process priority 0? FFS. When will people actually learn about the commands they are using? (re)nice does not make something run slower or faster. (re)nice changes the priority of the process giving it a higher or lower priority than other processes waiting to be run at the same time, whilst increasing or decreasing the time slice it is allowed to run in. So, if you are using other services on your games machine you should increase the priority (-1 or less)of the game process so that if MySQL and the Half-Life Daemon want to use the CPU at the same time, the Half-Life Daemon will run first because it has the higher priority. (re)nice'ing a program therefore makes a program run smoother, not faster. Matt. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
On Fri, 2006-04-21 at 09:04 +0100, Matt Judge wrote: (re)nice'ing a program therefore makes a program run smoother, not faster. Sort of misleading. For a highly CPU-bound process, renicing a program will make it run faster, as it gets a better share of the CPU's valuable time. And in some cases (i.e. game framerate, if a game was for some reason CPU-bound), faster in fact equals smoother. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
My point exactly - BUT you CANT increase the priority to -1 BECAUSE srcds will jump the CPU usage to 100% BECAUSE there is a BUG that does it. Dont get away from the original subject. -ICS Matt Judge wrote: ics wrote: Why would anyone want to renice it below 0 to 1-19 which would make it run slower than the default process priority 0? FFS. When will people actually learn about the commands they are using? (re)nice does not make something run slower or faster. (re)nice changes the priority of the process giving it a higher or lower priority than other processes waiting to be run at the same time, whilst increasing or decreasing the time slice it is allowed to run in. So, if you are using other services on your games machine you should increase the priority (-1 or less)of the game process so that if MySQL and the Half-Life Daemon want to use the CPU at the same time, the Half-Life Daemon will run first because it has the higher priority. (re)nice'ing a program therefore makes a program run smoother, not faster. Matt. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
John Sheu wrote: Sort of misleading. For a highly CPU-bound process, renicing a program will make it run faster, as it gets a better share of the CPU's valuable time. And in some cases (i.e. game framerate, if a game was for some reason CPU-bound), faster in fact equals smoother. Faster than what? It certainly can't run any faster than it was originally intended to do. The only thing it can do, is run faster than it would do if it wasn't (re)niced. The only time that it would run faster by (re)nicing would be if the server was under heavy load. If a process consumes 10% of CPU time per second, (re)nicing it will not make it consume more or less time, thereby making it work faster or slower. (re)nicing the process will only allocate larger or smaller time slices (and more of them) to that process. The process will still only run as fast as it would if were not (re)niced at all. Imagine a scenario of an ideal system, with nothing else running and, no overheads for swapping processes. You have 1 high CPU-bound process(a) utilising 70% of the CPU time slices/s. It is happy using the CPU without any interruptions from any other processes. (re)nicing it will not make it run any faster or slower as there is no other processes to share the CPU time slices. In this scenario, there is no point to renicing the process as there is nothing else to share the CPU time with. Lets add to this ideal system another process(b). Lets assume that if this process were on its own, it would utilise 20% of the CPU time slices/s. Now we have 2 processes which are highly likely to be wanting to use the CPU at the same time. (re)nicing process(a) ensures the our main process always has priority to use the CPU and get to use more of it before the CPU passes control to the other process. This ensures that process(a) runs smoother - but not faster. If we were to add yet another process to this system which would, by itself, utilise 30% of the CPU time slices/s, then this is the only case where (re)nicing would make a process run faster than it would otherwise. We would now have a 3 processes trying to grab more time slices/s than the CPU can provide and all the processes would lag regardless of how you reniced them. Matt. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
-- [ Picked text/plain from multipart/alternative ] Ff there's something you don't want to affect/compete with the game server (like mysql, httpd or something, anything none essential time wise, which aren't good things to run on a gaming server anyway, but some have no choice I guess), maybe positively nice -n 20 those processes instead. You can even nice them as default when they start. There's a number of preferred reasons for doing that imo, but I'll leave others to argue the toss over it :). On 4/21/06, ics [EMAIL PROTECTED] wrote: My point exactly - BUT you CANT increase the priority to -1 BECAUSE srcds will jump the CPU usage to 100% BECAUSE there is a BUG that does it. Dont get away from the original subject. -ICS Matt Judge wrote: ics wrote: Why would anyone want to renice it below 0 to 1-19 which would make it run slower than the default process priority 0? FFS. When will people actually learn about the commands they are using? (re)nice does not make something run slower or faster. (re)nice changes the priority of the process giving it a higher or lower priority than other processes waiting to be run at the same time, whilst increasing or decreasing the time slice it is allowed to run in. So, if you are using other services on your games machine you should increase the priority (-1 or less)of the game process so that if MySQL and the Half-Life Daemon want to use the CPU at the same time, the Half-Life Daemon will run first because it has the higher priority. (re)nice'ing a program therefore makes a program run smoother, not faster. Matt. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
-- On Fri, 21 Apr 2006 09:20:18 +0300 ics [EMAIL PROTECTED] bubbled: Hi, How hard is it to FIX the bug which causes CPU going to 100% usage after renicing the process? It was added in the last optional update, just like this last one. No problem here with reniced srcds or hlds (latest versions): PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 11087 ngcuser0 -19 99.7m 83m 8568 S 0.0 16.8 15:31.53 hlds_i686 6125 ngcuser0 -19 147m 70m 12m S 0.0 14.2 1:43.73 srcds_i686 -- MyExcuse: We didn't pay the Internet bill and it's been cut off. Martin Zwickel [EMAIL PROTECTED] Research Development TechnoTrend AG http://www.technotrend.de -- [ signature.asc of type application/pgp-signature deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Ticket errors since update
-- [ Picked text/plain from multipart/alternative ] I would like to give u this information, but what is colo plant and where do i see what colo plant my server is located in ?. On 4/21/06, Stuart Stegall [EMAIL PROTECTED] wrote: Every who's having this problem. What colo plant is the server located in? It can be a peering issue at the local peering center or something local to a colo plant. In 7 colo plants I have 0 servers with this anywhere in the log (I have a little ruby system that grabs logs from all the servers) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Ticket errors since update
This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] Colo Plant = the building where the server is colocated (assuming you do not have a dedicated ds3/ds5 to your server. If it is hosted by a GSP, then you'll have to check with them. Xeen wrote: -- [ Picked text/plain from multipart/alternative ] I would like to give u this information, but what is colo plant and where do i see what colo plant my server is located in ?. On 4/21/06, Stuart Stegall [EMAIL PROTECTED] wrote: Every who's having this problem. What colo plant is the server located in? It can be a peering issue at the local peering center or something local to a colo plant. In 7 colo plants I have 0 servers with this anywhere in the log (I have a little ruby system that grabs logs from all the servers) -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
If a process consumes 10% of CPU time per second, (re)nicing it will not make it consume more or less time, thereby making it work faster or slower. That much is true. However: Imagine a scenario of an ideal system, with nothing else running and, no overheads for swapping processes. You have 1 high CPU-bound process(a) utilising 70% of the CPU time slices/s. It is happy using the CPU without any interruptions from any other processes. (re)nicing it will not make it run any faster or slower as there is no other processes to share the CPU time slices. In this scenario, there is no point to renicing the process as there is nothing else to share the CPU time with. Under this ideal system, with one CPU-bound process, it would monopolize the processor, i.e. 100% utilization. The only reason why such a single process would _not_ use 100% CPU is if the thread were blocking on something else, e.g. I/O requests or sleeping. Lets add to this ideal system another process(b). Lets assume that if this process were on its own, it would utilise 20% of the CPU time slices/s. See above. Now we have 2 processes which are highly likely to be wanting to use the CPU at the same time. (re)nicing process(a) ensures the our main process always has priority to use the CPU and get to use more of it before the CPU passes control to the other process. This ensures that process(a) runs smoother - but not faster. Suppose that they were set to equal priority. Then the ideal scheduler _should_ allocate 50% CPU time to each thread. Note right away that this already reduces the speed of each process by 50%; as they only get the CPU for half the time, they need twice the realtime to process their tasks. Now, suppose one is prioritized over the other and the split is 75%-25%: the higher-priority thread, having more CPU time, would now indeed run faster than the case in which it had only 50% rights. If we were to add yet another process to this system which would, by itself, utilise 30% of the CPU time slices/s, then this is the only case where (re)nicing would make a process run faster than it would otherwise. We would now have a 3 processes trying to grab more time slices/s than the CPU can provide and all the processes would lag regardless of how you reniced them. So the overall answer is, I suppose, it depends. As I said, a highly CPU-bound process will indeed benefit from renicing to a lower priority; however, if the process is speed-limited in some way (in our specific case: srcsds will not exceed a particular framerate), the answer may vary. The point of renicing is to prioritize a process in the case that it does try to grab 100% CPU. Translated to the case of running a game server: if there's not much happening on a particular frame, and the server can process that frame with time to spare (and sleep away), then nicelevels will have a negligible impact on the process. However, in a frame with some heavy action (i.e. a firefight), where the server is strapped for time, a lower nicelevel (and a higher priority) means that the thread can effectively monopolize the CPU. In this case, it does run faster. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
John Sheu wrote: Imagine a scenario of an ideal system, with nothing else running and, no overheads for swapping processes. You have 1 high CPU-bound process(a) utilising 70% of the CPU time slices/s. It is happy using the CPU without any interruptions from any other processes. (re)nicing it will not make it run any faster or slower as there is no other processes to share the CPU time slices. In this scenario, there is no point to renicing the process as there is nothing else to share the CPU time with. Under this ideal system, with one CPU-bound process, it would monopolize the processor, i.e. 100% utilization. The only reason why such a single process would _not_ use 100% CPU is if the thread were blocking on something else, e.g. I/O requests or sleeping. I guess you are trying to be a pedant here. Or I over simplified my explanation. Expanding on your view point, my CPU utilisation would be 100% all the time, distributed between all the processes currently running. Guess what? it isn't. Go and learn about kernel scheduling. I did try replying to the rest of your email, but it was patently clear that trying to explain how Unix type operating systems work would be clearly beyond you, so I gave up. All the answers are in my previous post, please read it and be enlightened. Matt. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
-- [ Picked text/plain from multipart/alternative ] I think you're both coming at it from opposite angles and depends what you are looking at. For example because of the way srcds has changed (until its fixed), it _may_ take 100%, however thats a specific case. If you take a game without that issue and a fixed tic it would use less than that. So a fair amount depends on the game/app as well, there isn't really any rule that covers all. I still go with my earlier comments though its better to reduce the nice priority (positively) of those apps u don't consider important rather than to negatively nice the processes you prefer. 2 ways to skin a cat or something. Ultimately at this moment in time, you _won't_ get the nice issue if you use increase the value of those processes you deem less valuable, rather than reducing the nice value of those you do. On 4/21/06, Matt Judge [EMAIL PROTECTED] wrote: John Sheu wrote: Imagine a scenario of an ideal system, with nothing else running and, no overheads for swapping processes. You have 1 high CPU-bound process(a) utilising 70% of the CPU time slices/s. It is happy using the CPU without any interruptions from any other processes. (re)nicing it will not make it run any faster or slower as there is no other processes to share the CPU time slices. In this scenario, there is no point to renicing the process as there is nothing else to share the CPU time with. Under this ideal system, with one CPU-bound process, it would monopolize the processor, i.e. 100% utilization. The only reason why such a single process would _not_ use 100% CPU is if the thread were blocking on something else, e.g. I/O requests or sleeping. I guess you are trying to be a pedant here. Or I over simplified my explanation. Expanding on your view point, my CPU utilisation would be 100% all the time, distributed between all the processes currently running. Guess what? it isn't. Go and learn about kernel scheduling. I did try replying to the rest of your email, but it was patently clear that trying to explain how Unix type operating systems work would be clearly beyond you, so I gave up. All the answers are in my previous post, please read it and be enlightened. Matt. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
/me sighs. Here it goes again: On Fri, 2006-04-21 at 16:56 +0100, Matt Judge wrote: I guess you are trying to be a pedant here. Or I over simplified my explanation. Expanding on your view point, my CPU utilisation would be 100% all the time, distributed between all the processes currently running. Guess what? it isn't. Go and learn about kernel scheduling. The reason why CPU utilization isn't at 100% all all times is because all those threads are blocking on something else and/or sleeping. I did try replying to the rest of your email, but it was patently clear that trying to explain how Unix type operating systems work would be clearly beyond you, so I gave up. All the answers are in my previous post, please read it and be enlightened. Empirical evidence time. Here comes the clue train... ** Case 01: 1 CPU-bound thread, nice 0: ** ( nice -n 0 yes /dev/null ) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 8323 root 25 0 1460 372 312 R 98.3 0.0 0:09.25 yes 8133 root 15 0 152m 20m 6636 S 1.3 2.0 0:15.75 X As you can see, the CPU-bound process immediately chews up all your CPU time (98.3%). ** Case 02: 1 CPU-bound thread, nice -10: ** ( nice -n -10 yes /dev/null ) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 8329 root 15 -10 1456 368 312 R 99.4 0.0 0:09.02 yes 8133 root 15 0 152m 20m 6744 S 0.7 2.0 0:17.35 X Chews up your CPU time again, this time on nice -10. System is rather unresponsive, owing to the CPU prioritizing this useless process above all else. ** Case 03: 1 CPU-bound thread, nice 10: ** ( nice -n 10 yes /dev/null ) PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 8333 root 35 10 1456 368 312 R 98.7 0.0 0:05.32 yes 8133 root 15 0 152m 20m 6744 S 1.0 2.0 0:19.44 X Same results, but system more responsive. ** Conclusions ** As you can see, a CPU-bound process immediately tries to eat up as much CPU time as it can get. Niceness just regulates how important we rate this process. And please, stop pulling phrases like kernel scheduling out without fulling understanding the context. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
On Apr 21, 2006, at 9:32 AM, John Sheu wrote: As you can see, a CPU-bound process immediately tries to eat up as much CPU time as it can get. Niceness just regulates how important we rate this process. And please, stop pulling phrases like kernel scheduling out without fulling understanding the context. Correct. Also, interactive processes and pre-emption go quite a ways into screwing up 'nice'. Niceness is a suggestion, not a rule. The scheduler always wins the argument. If you want to tweak the scheduler, you can do that by recompiling your kernel, but only in a few ways that will really matter (such as changing the HZ value or turning preemption on/off.) -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Renice process bug
On Fri, 2006-04-21 at 11:32 -0500, John Sheu wrote: As you can see, a CPU-bound process immediately tries to eat up as much CPU time as it can get. Niceness just regulates how important we rate this process. And please, stop pulling phrases like kernel scheduling out without fulling understanding the context. To pre-empt any comments: fully understanding the context. Thank you, I'll be here all week. John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
