Linux CPU timer (was Re: question on top)

2008-12-10 Thread Rob van der Heij
Martin and myself took our argument off-list over a few virtual beers. I still owe you the outcome of that. * CPU time accounting in Linux is *different* with later kernels (from SLES10 / RHEL5 on) The older kernels used TOD clock (wall clock based) where the newer kernels use the CPU timer (virtu

Re: question on top

2008-12-08 Thread Barton Robinson
So, Martin, I learned a long time ago, that if the doc says 2+2 is 5, that don't make it right. Here is real data, we do understand it, and we do understand how to account for the "error", which is why we don't push for a "fix". So using native Linux tools, this data would be off by factor of

Re: question on top

2008-12-08 Thread Rob van der Heij
On Mon, Dec 8, 2008 at 5:49 PM, Martin Schwidefsky <[EMAIL PROTECTED]> wrote: > 2) The factor of 4-5 is based on what numbers exactly? I doubt that you > get that discrepancy if you are running a cpu bound linux process that > uses more than a few percent of cpu. As already pointer out the > situa

Re: question on top

2008-12-08 Thread Martin Schwidefsky
On Mon, 2008-12-08 at 17:41 +0100, Rob van der Heij wrote: > >> a production server). Not sure we've bothered to report the details since > >> this problem > >> would not impact our users. So the data still can not be used for serious > >> performance > > > > The last time we talked, your tool u

Re: question on top

2008-12-08 Thread Barton Robinson
Sorry Alan, if you are an open source company, or a monopoly, then you don't mind helping your competitors. With the growth in installations doing accounting for Linux applications, this stuff is actually important Alan Altmark wrote: On Monday, 12/08/2008 at 10:28 EST, Barton Robinson <

Re: question on top

2008-12-08 Thread Alan Altmark
On Monday, 12/08/2008 at 10:28 EST, Barton Robinson <[EMAIL PROTECTED]> wrote: > Not sure we've bothered to report the details since this problem > would not impact our users. It would nonetheless be a good service to the community to report the problem you found, whether it affects your customers

Re: question on top

2008-12-08 Thread Martin Schwidefsky
On Mon, 2008-12-08 at 07:25 -0800, Barton Robinson wrote: > Sorry Christian, but with the latest and greatest, there are many cases where > Linux and > TOP now seriously under report utilization (I think by factor of 5 in the > lab, and by 4 in > a production server). Not sure we've bothered to r

Re: question on top

2008-12-08 Thread Rob van der Heij
On Mon, Dec 8, 2008 at 4:54 PM, Christian Borntraeger <[EMAIL PROTECTED]> wrote: > Barton, > >> Sorry Christian, but with the latest and greatest, there are many cases >> where Linux and >> TOP now seriously under report utilization (I think by factor of 5 in the >> lab, and by 4 in > > Do you ha

Re: question on top

2008-12-08 Thread Christian Borntraeger
Barton, > Sorry Christian, but with the latest and greatest, there are many cases where > Linux and > TOP now seriously under report utilization (I think by factor of 5 in the > lab, and by 4 in Do you have a short description of one test case? If there is a real problem, we should fix it. > a

Re: question on top

2008-12-08 Thread Barton Robinson
Sorry Christian, but with the latest and greatest, there are many cases where Linux and TOP now seriously under report utilization (I think by factor of 5 in the lab, and by 4 in a production server). Not sure we've bothered to report the details since this problem would not impact our users.

Re: question on top

2008-12-08 Thread Christian Borntraeger
Am Montag, 8. Dezember 2008 schrieb Barton Robinson: > Yes, top lies. This is no longer true with SLES10+ and RHEL5+. They use the stpt instruction for accurate accounting. If you still see wrong numbers with a recent distro, this would be a bug and should be reported. > So are you really saying

Re: question on top

2008-12-08 Thread Mark Perry
Barton Robinson wrote: > Yes, top lies. So are you really saying a single threaded process is > using more than one > cpu? Don't need much more proof than that. > Barton I don't think TOP shows threads by default, so a multithreaded process would so up as a single line. In TOP type "H" to show t

Re: question on top

2008-12-08 Thread David Boyes
On 12/8/08 8:48 AM, "Ayer, Paul W" <[EMAIL PROTECTED]> wrote: > I have seen notes before that "top lies" but; Like a rug. > Looking at a top display sorted by %CPU I see some processes using over > 200 or 300 % CPU. > This LPAR has 4 IFL's installed and the Linux has access to all four. > Can we

Re: question on top

2008-12-08 Thread Barton Robinson
Yes, top lies. So are you really saying a single threaded process is using more than one cpu? Don't need much more proof than that. What does your performance monitor say (can you measure Linux in an LPAR with your performance monitor)??? Normally the processes would be somewhat balanced ove

Re: question on top

2008-12-08 Thread Harder, Pieter
: question on top Good Morning, I have seen notes before that "top lies" but; Looking at a top display sorted by %CPU I see some processes using over 200 or 300 % CPU. This LPAR has 4 IFL's installed and the Linux has access to all four. Can we use the %cpu below 400 % as an in

question on top

2008-12-08 Thread Ayer, Paul W
Good Morning, I have seen notes before that "top lies" but; Looking at a top display sorted by %CPU I see some processes using over 200 or 300 % CPU. This LPAR has 4 IFL's installed and the Linux has access to all four. Can we use the %cpu below 400 % as an indicator that we are not using all f