RE: Increasing HZ (patch for HZ > 1000)

RE: Increasing HZ (patch for HZ > 1000)

[Grover, Andrew]

> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
> Jean-Marc Valin
> > Why would you want to *increase* HZ? I'd say 1000 is 
> already too high
> > personally, but I'm curious what you'd want to do with it? Embedded
> > real-time stuff?
> 
> Actually, my reasons may sound a little strange, but basically I'd be
> fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound when the
> CPU is idle (probably bad capacitors). By increasing HZ to 10 kHz, the
> sound is at a frequency where the ear is much less sensitive. 
> Anyway, I
> thought some people might be interested in high HZ for other (more
> fundamental) reasons, so I posted the patch.

I'd advocate lower HZ. Say, oh I dunno...100? This is better for power
management and also should make the sound go away.

Hmm, I wonder if HZ=10 would break anything :)

Regards -- Andy

Re: Increasing HZ (patch for HZ > 1000)

[Jamie Lokier]

Grover, Andrew wrote:
> I'd advocate lower HZ. Say, oh I dunno...100? This is better for power
> management and also should make the sound go away.

Alas, the sound my Toshiba laptop makes when the CPU is busy is the
same frequency whatever kernel, and by extension whatever the timer
frequency.  I guess it must have another cause :/

-- Jamie

Re: Increasing HZ (patch for HZ > 1000)

[Vojtech Pavlik]

On Fri, Dec 12, 2003 at 10:31:28PM +0000, Jamie Lokier wrote:
> Grover, Andrew wrote:
> > I'd advocate lower HZ. Say, oh I dunno...100? This is better for power
> > management and also should make the sound go away.
> 
> Alas, the sound my Toshiba laptop makes when the CPU is busy is the
> same frequency whatever kernel, and by extension whatever the timer
> frequency.  I guess it must have another cause :/
> 
> -- Jamie

If it's when the CPU is busy, then it's the CPU's DC/DC converter. There
is no way to get rid of the noise without mnodifying the notebook.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Increasing HZ (patch for HZ > 1000)

[Jamie Lokier]

Vojtech Pavlik wrote:
> > > I'd advocate lower HZ. Say, oh I dunno...100? This is better for power
> > > management and also should make the sound go away.
> > 
> > Alas, the sound my Toshiba laptop makes when the CPU is busy is the
> > same frequency whatever kernel, and by extension whatever the timer
> > frequency.  I guess it must have another cause :/
>
> If it's when the CPU is busy, then it's the CPU's DC/DC converter. There
> is no way to get rid of the noise without mnodifying the notebook.

It only does it when the CPU is busy in any low power mode.  In
maximum power mode it never makes the noise.  It sounds like it's
coming from the speakers (independent of volume control though), but
it might not be.

Would the DC/DC converter noise be explained by a low quality
capacitor used by the converter?

-- Jamie

Re: Increasing HZ (patch for HZ > 1000)

[Vojtech Pavlik]

On Fri, Dec 12, 2003 at 11:45:23PM +0000, Jamie Lokier wrote:
> Vojtech Pavlik wrote:
> > > > I'd advocate lower HZ. Say, oh I dunno...100? This is better for power
> > > > management and also should make the sound go away.
> > > 
> > > Alas, the sound my Toshiba laptop makes when the CPU is busy is the
> > > same frequency whatever kernel, and by extension whatever the timer
> > > frequency.  I guess it must have another cause :/
> >
> > If it's when the CPU is busy, then it's the CPU's DC/DC converter. There
> > is no way to get rid of the noise without mnodifying the notebook.
> 
> It only does it when the CPU is busy in any low power mode.  In
> maximum power mode it never makes the noise.  It sounds like it's
> coming from the speakers (independent of volume control though), but
> it might not be.
> 
> Would the DC/DC converter noise be explained by a low quality
> capacitor used by the converter?

Yes.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Increasing HZ (patch for HZ > 1000)

[Pavel Machek]

Hi!

> >Actually, the way I rewrote it in the patch is immune to that kind of
> >problem:
> >
> >seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
> >           HZ*(c->loops_per_jiffy>>3)/62500,
> >           (HZ*(c->loops_per_jiffy>>3)/625)%100);
> >
> >It will work correctly for any HZ up to ~34000 bogomips (using 32-bit
> >arithmetic).
> 
> I think it's likely any CPU with 34000 bogomips will have more than 
> 32 bit ;-)

Hmmm, but it will perhaps be running in compatibility mode.

;-),
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Increasing HZ (patch for HZ > 1000)

[Bill Davidsen]

Jean-Marc Valin wrote:

> Actually, the way I rewrote it in the patch is immune to that kind of
> problem:
> 
> seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
>            HZ*(c->loops_per_jiffy>>3)/62500,
>            (HZ*(c->loops_per_jiffy>>3)/625)%100);
> 
> It will work correctly for any HZ up to ~34000 bogomips (using 32-bit
> arithmetic).

I think it's likely any CPU with 34000 bogomips will have more than 32 
bit ;-)

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: Increasing HZ (patch for HZ > 1000)

[Mitchell Blank Jr]

john stultz wrote:
> Indeed, with all the trouble HZ==1000 has caused, I'm thinking that
> playing w/ HZ at 10k and 10 would be good stress tests for the time
> subsystem.

I think setting HZ much lower than 100 might break some drivers that
do things like:
		timeout = jiffies + (HZ / 50);

Not sure if any of the common drivers have this problem but be on the
lookout for it if you want to try running w/ really low HZ.

I suppose there should really be a "FRACTION_OF_SECOND()" macro or something
that always returns >0 for specifying these really short delays.

-Mitch

Re: Increasing HZ (patch for HZ > 1000)

[john stultz]

On Fri, 2003-12-12 at 15:40, Pavel Machek wrote:
> > For now, my patch only allows up to around 10 kHz. At that frequency, I
> > don't hear anything because the noise is not loud enough (ear is much
> > more sensitive at 1 kHz). Also, I have around 10% overhead on my
> > Pentium-M 1.6 GHz, so I guess it's not for everyone. Extrapolating from
> > there, I'd also say that at 100 kHz, it wouldn't do anything but handle
> > the interrupts, which is slightly annoying when you want to actually get
> > some work done :)
> 
> I wonder what happens at 200kHz then; system might detect some lost
> ticks and keep running at very slow speed...

Indeed, with all the trouble HZ==1000 has caused, I'm thinking that
playing w/ HZ at 10k and 10 would be good stress tests for the time
subsystem.

I'd be interested in hearing how much drift people see when running w/
this patch. 

thanks
-john

Re: Increasing HZ (patch for HZ > 1000)

[Pat Erley]

sometime before now (bill davidsen) wrote this blurb:

> Stop! This is Linux we're talking about, if we can have Morse code panic
> messages, we can certainly have the idle loop change frequency to play a
> tune on the output capacitors (or whatever else make noise). How about
> the Penguin army marching music from the Saturday morning cartoon, and
> maybe hack LinuxBIOS to check for Windows running and have the idle loop
> play Twilight of the Gods.
> 
> I better stop before someone actually does it.

what about the xfree hack that would let you use a monitor as an AM broadcasting station by tweaking on something?

http://slashdot.org/articles/01/11/26/2353252.shtml

Pat Erley

-- 

Re: Increasing HZ (patch for HZ > 1000)

[bill davidsen]

In article <1071269849.4182.14.camel@idefix.homelinux.org>,
Jean-Marc Valin  <Jean-Marc.Valin@USherbrooke.ca> wrote:
| 
| > Every notebook from thinkpad 560X up has produced some kind of
| > cpu-load-related-noise. You'd have to throw out quite a lot of
| > notebooks...
| 
| You're right, I'm probably not the only one. It may be worth at least
| having an option to change HZ to less annoying values. Otherwise there
| are going to be lots of complaints when people try out 2.6 on their
| laptops and hear that noise. On mine, I seriously could not stand the
| noise more than 5 minutes. Not because it was that loud but 1 kHz is
| really annoying.
| 
| > PS: Jean, can you try how high you can get it? You might want to go to
| > 24kHz so that no human can hear it, or to 100kHz to be kind to
| > cats. At ~1MHz you'd be even kind to bats :-), but it is probably
| > impossible to get over 200kHz or so. Still it might be funny
| > experiment.
| 
| For now, my patch only allows up to around 10 kHz. At that frequency, I
| don't hear anything because the noise is not loud enough (ear is much
| more sensitive at 1 kHz). Also, I have around 10% overhead on my
| Pentium-M 1.6 GHz, so I guess it's not for everyone. Extrapolating from
| there, I'd also say that at 100 kHz, it wouldn't do anything but handle
| the interrupts, which is slightly annoying when you want to actually get
| some work done :)
| 
| 	Jean-Marc

Stop! This is Linux we're talking about, if we can have Morse code panic
messages, we can certainly have the idle loop change frequency to play a
tune on the output capacitors (or whatever else make noise). How about
the Penguin army marching music from the Saturday morning cartoon, and
maybe hack LinuxBIOS to check for Windows running and have the idle loop
play Twilight of the Gods.

I better stop before someone actually does it.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Increasing HZ (patch for HZ > 1000)

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

>> > Every notebook from thinkpad 560X up has produced some kind of
>> > cpu-load-related-noise. You'd have to throw out quite a lot of
>> > notebooks...
>> 
>> You're right, I'm probably not the only one. It may be worth at least
>> having an option to change HZ to less annoying values. Otherwise there
>> are going to be lots of complaints when people try out 2.6 on their
>> laptops and hear that noise. On mine, I seriously could not stand the
>> noise more than 5 minutes. Not because it was that loud but 1 kHz is
>> really annoying.
>
> Okay, we are probably taking other sounds. I can hear cpu-load-related
> noise on every notebook from thinkpad 560X -- in a quiet room, and on
> some machines its rather hard to notice. You probably have way more
> annoying problem.

My laptop makes a slight noise in the speakers when there are
interrupts.  It's only noticeable with an external amplifier
connected.  There's also some ~1 kHz sound coming from the vicinity of
the CPU, particularly when there is network activity.

-- 
Måns Rullgård
mru@kth.se

Re: Increasing HZ (patch for HZ > 1000)

[Pavel Machek]

Hi!

> > Every notebook from thinkpad 560X up has produced some kind of
> > cpu-load-related-noise. You'd have to throw out quite a lot of
> > notebooks...
> 
> You're right, I'm probably not the only one. It may be worth at least
> having an option to change HZ to less annoying values. Otherwise there
> are going to be lots of complaints when people try out 2.6 on their
> laptops and hear that noise. On mine, I seriously could not stand the
> noise more than 5 minutes. Not because it was that loud but 1 kHz is
> really annoying.

Okay, we are probably taking other sounds. I can hear cpu-load-related
noise on every notebook from thinkpad 560X -- in a quiet room, and on
some machines its rather hard to notice. You probably have way more
annoying problem.

> > PS: Jean, can you try how high you can get it? You might want to go to
> > 24kHz so that no human can hear it, or to 100kHz to be kind to
> > cats. At ~1MHz you'd be even kind to bats :-), but it is probably
> > impossible to get over 200kHz or so. Still it might be funny
> > experiment.
> 
> For now, my patch only allows up to around 10 kHz. At that frequency, I
> don't hear anything because the noise is not loud enough (ear is much
> more sensitive at 1 kHz). Also, I have around 10% overhead on my
> Pentium-M 1.6 GHz, so I guess it's not for everyone. Extrapolating from
> there, I'd also say that at 100 kHz, it wouldn't do anything but handle
> the interrupts, which is slightly annoying when you want to actually get
> some work done :)

I wonder what happens at 200kHz then; system might detect some lost
ticks and keep running at very slow speed...
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Increasing HZ (patch for HZ > 1000)

[Måns Rullgård]

Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> writes:

> more sensitive at 1 kHz). Also, I have around 10% overhead on my
> Pentium-M 1.6 GHz, so I guess it's not for everyone. Extrapolating from
> there, I'd also say that at 100 kHz, it wouldn't do anything but handle
> the interrupts, which is slightly annoying when you want to actually get
> some work done :)

I once forgot to acknowledge an interrupt in the handler for a PCI
board.  It ended up being called ~300k times per second.  The system
load was noticeable.

-- 
Måns Rullgård
mru@kth.se

Re: Increasing HZ (patch for HZ > 1000)

[Jean-Marc Valin]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

> Every notebook from thinkpad 560X up has produced some kind of
> cpu-load-related-noise. You'd have to throw out quite a lot of
> notebooks...

You're right, I'm probably not the only one. It may be worth at least
having an option to change HZ to less annoying values. Otherwise there
are going to be lots of complaints when people try out 2.6 on their
laptops and hear that noise. On mine, I seriously could not stand the
noise more than 5 minutes. Not because it was that loud but 1 kHz is
really annoying.

> PS: Jean, can you try how high you can get it? You might want to go to
> 24kHz so that no human can hear it, or to 100kHz to be kind to
> cats. At ~1MHz you'd be even kind to bats :-), but it is probably
> impossible to get over 200kHz or so. Still it might be funny
> experiment.

For now, my patch only allows up to around 10 kHz. At that frequency, I
don't hear anything because the noise is not loud enough (ear is much
more sensitive at 1 kHz). Also, I have around 10% overhead on my
Pentium-M 1.6 GHz, so I guess it's not for everyone. Extrapolating from
there, I'd also say that at 100 kHz, it wouldn't do anything but handle
the interrupts, which is slightly annoying when you want to actually get
some work done :)

	Jean-Marc

-- 
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Increasing HZ (patch for HZ > 1000)

[Jean-Marc Valin]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

> Well, on i386 we only run with HZ=100 and HZ=1000, so bug is latent,
> but if you can find nice way to rewrite it without the bug, it would
> probably be worth fixing.

Actually, the way I rewrote it in the patch is immune to that kind of
problem:

seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
           HZ*(c->loops_per_jiffy>>3)/62500,
           (HZ*(c->loops_per_jiffy>>3)/625)%100);

It will work correctly for any HZ up to ~34000 bogomips (using 32-bit
arithmetic).

	Jean-Marc

-- 
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Increasing HZ (patch for HZ > 1000)

[Pavel Machek]

Hi!

> Just one more thing about the patch I sent. I think it addresses
> something unclean in the bogomips computation. For example, in
> arch/i386/kernel/cpu/proc.c, you have:
> 
> seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
>            c->loops_per_jiffy/(500000/HZ),
>            (c->loops_per_jiffy/(5000/HZ)) % 100);
> 
> It's clear that for any case where 5000/HZ is not an integer, the
> bogomips decimals will be wrong and if 500000/HZ isn't an integer, the
> bogomips integer part will be wrong.
> 
> For example on a 2 GHz processor with a 4000 bogomips value and HZ=1200,
> the code above will produce 3996.66 instead of 4000. Of course, as soon
> as HZ goes above 5000, you have a divide by zero right at compile time.

Well, on i386 we only run with HZ=100 and HZ=1000, so bug is latent,
but if you can find nice way to rewrite it without the bug, it would
probably be worth fixing.
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Increasing HZ (patch for HZ > 1000)

[Pavel Machek]

Hi!

> >> Why would you want to *increase* HZ? I'd say 1000 is already too high
> >> personally, but I'm curious what you'd want to do with it? Embedded
> >> real-time stuff?
> > 
> > Actually, my reasons may sound a little strange, but basically I'd be
> > fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound when the
> > CPU is idle (probably bad capacitors). By increasing HZ to 10 kHz, the
> > sound is at a frequency where the ear is much less sensitive. Anyway, I
> > thought some people might be interested in high HZ for other (more
> > fundamental) reasons, so I posted the patch.
> 
> Ha! ;-) 
> A hardware fix might be in order ;-)

Every notebook from thinkpad 560X up has produced some kind of
cpu-load-related-noise. You'd have to throw out quite a lot of
notebooks...
								Pavel
PS: Jean, can you try how high you can get it? You might want to go to
24kHz so that no human can hear it, or to 100kHz to be kind to
cats. At ~1MHz you'd be even kind to bats :-), but it is probably
impossible to get over 200kHz or so. Still it might be funny
experiment.

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

RE: Increasing HZ (patch for HZ > 1000)

[Vincent Legoll]

> I'd advocate lower HZ. Say, oh I dunno...100?
> This is better for power management and also
> should make the sound go away.
> Hmm, I wonder if HZ=10 would break anything :)

I wonder if someone tried HZ=40, if so, is she
still alive ? As 40 Hz is the brain wave frequency,
inteferences should have interesting side effects.
I won't try that myself unless wearing an AFDB, do
you ?
http://zapatopi.net/afdb.html - ROTFL
:-)

-- 
Vince - libATA is cool

Re: Increasing HZ (patch for HZ > 1000)

[Jean-Marc Valin]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

Just one more thing about the patch I sent. I think it addresses
something unclean in the bogomips computation. For example, in
arch/i386/kernel/cpu/proc.c, you have:

seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
           c->loops_per_jiffy/(500000/HZ),
           (c->loops_per_jiffy/(5000/HZ)) % 100);

It's clear that for any case where 5000/HZ is not an integer, the
bogomips decimals will be wrong and if 500000/HZ isn't an integer, the
bogomips integer part will be wrong.

For example on a 2 GHz processor with a 4000 bogomips value and HZ=1200,
the code above will produce 3996.66 instead of 4000. Of course, as soon
as HZ goes above 5000, you have a divide by zero right at compile time.

	Jean-Marc

-- 
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Increasing HZ (patch for HZ > 1000)

[Gene Heskett]

On Thursday 11 December 2003 13:10, Richard B. Johnson wrote:
>On Thu, 11 Dec 2003, Martin J. Bligh wrote:

No, Gene Heskett wrote this:

>> > Hardware indeed.  I'm a Certified Electronics Technician.  Have
>> > someone check all those electrolyric caps in the on-board psu in
>> > particular, using a device similar to a "Capacitor Wizard" which
>> > measures not the capacity of the cap, but the caps Equivalent
>> > Series Resistance (ESR) at 100 kilohertz or more.  Anything over
>> > half an ohm should be replaced forthwith.  This assumes of
>> > course that your tech in charge of hot solder has the tools to
>> > do it correctly.  If not, find one who does have the tools.
>> >
>> > Many mobos in a period ranging from about 2.5 to 1.5 years ago
>> > were built with caps that go defective prematurely due to a bad
>> > batch of them from several far eastern cap makers who were fed a
>> > bad recipe for the electrolyte in the caps, eg the Ethylene
>> > Glycol wasn't near pure enough.
>>
>> When you say "fed a bad recipe", didn't they actually steal it? Or
>> is that just an urban legend?
>>
>> M.
>
>"Appropriated". Also, it isn't ethylene glycol (that's antifreeze),
>It's potassium hydroxide with an inhibitor. The inhibitor was
> cleverly removed from the recipe and left out to be stolen. As
> expected, it was. Unfortunately, the bad caps didn't damage the
> competing company bad enough to put them out-of-business so the
> whole ploy was a waste of effort. ;^)

I believe that potassium hydroxide, an extremely alkaline chemical, is 
involved with tantalum capacitors only.  For electrolytics, its 
always been, and probably always will be, Ethylene Glycol to replace 
the air in the kraft paper foil seperator, and furnish a high 
dielectric constant, several times that of air.  "Antifreeze", yes 
but without any inhibiters, none, technical pure grade only.  
Resistance in CM3 measured in siemans if you have a meter that goes 
that high.  Most don't.

It doesn't take much on a per cap basis though.  I almost 
single-handedly caused a nationwide shortage of capacitors one winter 
back in the 70's when I needed some pure stuff for the tv transmitter 
I was in charge of at the time.  Seems that during the OPEC oil 
embargo, the only 55 gallon barrel of any kind of ethylene glycol in 
the whole country was a barrel of technical grade, sitting on the 
dock of the Mobil distributor 100 miles down the road in Omaha NE.  I 
probably ran up a 500 dollar phone bill just finding it because I 
started at the refineries on the coasts.

It was either pay the about 10 bucks a gallon for it or go off the 
air.  I paid, or rather the Nebraska ETV commission paid and bought 
that last barrel and KXNE-TV stayed on the air that winter.

It wasn't till late the next summer when the replacement capacitor 
shelf at your local electronics supplier finally started to get some 
dust cover again.  It got pretty bare there for a few months.

Another of your trivia factoids for the day :-)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: Increasing HZ (patch for HZ > 1000)

[Gene Heskett]

On Thursday 11 December 2003 12:33, Martin J. Bligh wrote:
>> Hardware indeed.  I'm a Certified Electronics Technician.  Have
>> someone check all those electrolyric caps in the on-board psu in
>> particular, using a device similar to a "Capacitor Wizard" which
>> measures not the capacity of the cap, but the caps Equivalent
>> Series Resistance (ESR) at 100 kilohertz or more.  Anything over
>> half an ohm should be replaced forthwith.  This assumes of course
>> that your tech in charge of hot solder has the tools to do it
>> correctly.  If not, find one who does have the tools.
>>
>> Many mobos in a period ranging from about 2.5 to 1.5 years ago
>> were built with caps that go defective prematurely due to a bad
>> batch of them from several far eastern cap makers who were fed a
>> bad recipe for the electrolyte in the caps, eg the Ethylene Glycol
>> wasn't near pure enough.
>
>When you say "fed a bad recipe", didn't they actually steal it? Or
>is that just an urban legend?
>
>M.

Well, I *was* trying to be nice<vsg>.  I'd made the assumption that 
the supplier was the one doing the stealing, and that they (the cap 
makers as buyers of this cheaper than usual product) were not 100% 
aware of the problems at the time.  Yes, I've read the story, and the 
history of capacitor failures over the last 2 years does seem to lend 
considerable credance to the story.  When you are a CET, doing 
component level repairs for a living for the last 50 some years, some 
things do get your attention, and poor life of capacitors has long 
since become the single leading failure of things electronic, 
recently by a factor measured in magnitudes over anything else, like 
bad semiconductors.  Thats been the tend for the last 10 years in 
fact.  Poor lubrication of things basicly mechanical like electrical 
switches is now second on the list, with a lot of white space between 
them.

The windshield wiper speed switch in your car being a prime example of 
that 2nd type of failure.  If it hasn't miss-behaved, it will.  Pull 
the knob off the end of the stalk and remove the super sticky syrupy 
grease there and replace it with lubriplate, end of problem, probably 
forever.  Certainly for as long as you'll own it.  Your trivia fact 
for the day :-)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: Increasing HZ (patch for HZ > 1000)

[Richard B. Johnson]

On Thu, 11 Dec 2003, Martin J. Bligh wrote:

> > Hardware indeed.  I'm a Certified Electronics Technician.  Have
> > someone check all those electrolyric caps in the on-board psu in
> > particular, using a device similar to a "Capacitor Wizard" which
> > measures not the capacity of the cap, but the caps Equivalent Series
> > Resistance (ESR) at 100 kilohertz or more.  Anything over half an ohm
> > should be replaced forthwith.  This assumes of course that your tech
> > in charge of hot solder has the tools to do it correctly.  If not,
> > find one who does have the tools.
> >
> > Many mobos in a period ranging from about 2.5 to 1.5 years ago were
> > built with caps that go defective prematurely due to a bad batch of
> > them from several far eastern cap makers who were fed a bad recipe
> > for the electrolyte in the caps, eg the Ethylene Glycol wasn't near
> > pure enough.
>
> When you say "fed a bad recipe", didn't they actually steal it? Or
> is that just an urban legend?
>
> M.

"Appropriated". Also, it isn't ethylene glycol (that's antifreeze),
It's potassium hydroxide with an inhibitor. The inhibitor was cleverly
removed from the recipe and left out to be stolen. As expected, it
was. Unfortunately, the bad caps didn't damage the competing company
bad enough to put them out-of-business so the whole ploy was a waste
of effort. ;^)


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: Increasing HZ (patch for HZ > 1000)

[Martin J. Bligh]

> Hardware indeed.  I'm a Certified Electronics Technician.  Have 
> someone check all those electrolyric caps in the on-board psu in 
> particular, using a device similar to a "Capacitor Wizard" which 
> measures not the capacity of the cap, but the caps Equivalent Series 
> Resistance (ESR) at 100 kilohertz or more.  Anything over half an ohm 
> should be replaced forthwith.  This assumes of course that your tech 
> in charge of hot solder has the tools to do it correctly.  If not, 
> find one who does have the tools.
> 
> Many mobos in a period ranging from about 2.5 to 1.5 years ago were 
> built with caps that go defective prematurely due to a bad batch of 
> them from several far eastern cap makers who were fed a bad recipe 
> for the electrolyte in the caps, eg the Ethylene Glycol wasn't near 
> pure enough.

When you say "fed a bad recipe", didn't they actually steal it? Or
is that just an urban legend?

M.

Re: Increasing HZ (patch for HZ > 1000)

[Gene Heskett]

On Thursday 11 December 2003 02:18, Martin J. Bligh wrote:
>>> Why would you want to *increase* HZ? I'd say 1000 is already too
>>> high personally, but I'm curious what you'd want to do with it?
>>> Embedded real-time stuff?
>>
>> Actually, my reasons may sound a little strange, but basically I'd
>> be fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound
>> when the CPU is idle (probably bad capacitors). By increasing HZ
>> to 10 kHz, the sound is at a frequency where the ear is much less
>> sensitive. Anyway, I thought some people might be interested in
>> high HZ for other (more fundamental) reasons, so I posted the
>> patch.
>
>Ha! ;-)
>A hardware fix might be in order ;-)

Indeed...  I may have the only un-repaired Biostar M7VIB in the area 
out of several dozen.  All the rest have had those 4 caps right above 
the AGP slot replaced already.  And this one may also be the only one 
that doesn't get shut off at night.  However it is also very unstable 
when starting from cold, needing 3-5 resets to even get through post 
without trashing the video after I had it apart to clean the cpu 
fan/sink and psu the other night.  Its stable once thats been done, 
so I'm as usual, procrastinating.  Been doing it for 69 years now. :)

Hardware indeed.  I'm a Certified Electronics Technician.  Have 
someone check all those electrolyric caps in the on-board psu in 
particular, using a device similar to a "Capacitor Wizard" which 
measures not the capacity of the cap, but the caps Equivalent Series 
Resistance (ESR) at 100 kilohertz or more.  Anything over half an ohm 
should be replaced forthwith.  This assumes of course that your tech 
in charge of hot solder has the tools to do it correctly.  If not, 
find one who does have the tools.

Many mobos in a period ranging from about 2.5 to 1.5 years ago were 
built with caps that go defective prematurely due to a bad batch of 
them from several far eastern cap makers who were fed a bad recipe 
for the electrolyte in the caps, eg the Ethylene Glycol wasn't near 
pure enough.

>M.
>
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: Increasing HZ (patch for HZ > 1000)

[Tim Schmielau]

> Actually, my reasons may sound a little strange, but basically I'd be
> fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound when the
> CPU is idle (probably bad capacitors). By increasing HZ to 10 kHz, the
> sound is at a frequency where the ear is much less sensitive. Anyway, I
> thought some people might be interested in high HZ for other (more
> fundamental) reasons, so I posted the patch.

=8-)
I'd guess a tickless kernel might be what you actually want. See e.g.

  http://sourceforge.net/projects/high-res-timers/

Tim

Re: Increasing HZ (patch for HZ > 1000)

[Nick Piggin]

Jean-Marc Valin wrote:

>>Why would you want to *increase* HZ? I'd say 1000 is already too high
>>personally, but I'm curious what you'd want to do with it? Embedded
>>real-time stuff?
>>
>
>Actually, my reasons may sound a little strange, but basically I'd be
>fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound when the
>CPU is idle (probably bad capacitors). By increasing HZ to 10 kHz, the
>sound is at a frequency where the ear is much less sensitive. Anyway, I
>thought some people might be interested in high HZ for other (more
>fundamental) reasons, so I posted the patch.
>

Heh! Does it scare your dog away? ;)

Re: Increasing HZ (patch for HZ > 1000)

[Martin J. Bligh]

>> Why would you want to *increase* HZ? I'd say 1000 is already too high
>> personally, but I'm curious what you'd want to do with it? Embedded
>> real-time stuff?
> 
> Actually, my reasons may sound a little strange, but basically I'd be
> fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound when the
> CPU is idle (probably bad capacitors). By increasing HZ to 10 kHz, the
> sound is at a frequency where the ear is much less sensitive. Anyway, I
> thought some people might be interested in high HZ for other (more
> fundamental) reasons, so I posted the patch.

Ha! ;-) 
A hardware fix might be in order ;-)

M.

Re: Increasing HZ (patch for HZ > 1000)

[Jean-Marc Valin]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

> Why would you want to *increase* HZ? I'd say 1000 is already too high
> personally, but I'm curious what you'd want to do with it? Embedded
> real-time stuff?

Actually, my reasons may sound a little strange, but basically I'd be
fine with HZ=1000 if it wasn't for that annoying ~1 kHz sound when the
CPU is idle (probably bad capacitors). By increasing HZ to 10 kHz, the
sound is at a frequency where the ear is much less sensitive. Anyway, I
thought some people might be interested in high HZ for other (more
fundamental) reasons, so I posted the patch.

	Jean-Marc
 
-- 
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Increasing HZ (patch for HZ > 1000)

[Martin J. Bligh]

> I think this may be of interest to some people. I've attached a patch
> that makes it possible to increase HZ up to 10000. The patch adds some
> HZ-related defines (e.g. SHIFT_HZ) for higher HZ values. It also removes
> some shift by negative number and divide by zero (e.g. in bogomips
> computation) and prevents some overflows. I'm not sure I fixed
> everything, but right now it seems to work with HZ=10000. The only thing
> I'm seeing are messages such as: "orinoco_lock() called with
> hw_unavailable (dev=f75c8000)" and "eth1: IRQ handler is looping too
> much! Resetting.".

Why would you want to *increase* HZ? I'd say 1000 is already too high
personally, but I'm curious what you'd want to do with it? Embedded
real-time stuff?

M.

Increasing HZ (patch for HZ > 1000)

[Jean-Marc Valin]

[-- Attachment #1.1: Type: text/plain, Size: 837 bytes --]

Hi,

I think this may be of interest to some people. I've attached a patch
that makes it possible to increase HZ up to 10000. The patch adds some
HZ-related defines (e.g. SHIFT_HZ) for higher HZ values. It also removes
some shift by negative number and divide by zero (e.g. in bogomips
computation) and prevents some overflows. I'm not sure I fixed
everything, but right now it seems to work with HZ=10000. The only thing
I'm seeing are messages such as: "orinoco_lock() called with
hw_unavailable (dev=f75c8000)" and "eth1: IRQ handler is looping too
much! Resetting.".

I know it's (much) too late for 2.6 but I'm sending the patch anyway so
it (hopefully) doesn't get lost. 

	Jean-Marc

-- 
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

[-- Attachment #1.2: hz.patch --]
[-- Type: text/x-patch, Size: 7974 bytes --]

--- linux-2.6.0-test11/include/linux/timex.h	2003-11-26 15:42:54.000000000 -0500
+++ linux-2.6.0-test11-hz/include/linux/timex.h	2003-12-09 14:33:51.000000000 -0500
@@ -77,6 +77,12 @@
 # define SHIFT_HZ	9
 #elif HZ >= 768 && HZ < 1536
 # define SHIFT_HZ	10
+#elif HZ >= 1536 && HZ < 3072
+# define SHIFT_HZ	11
+#elif HZ >= 3072 && HZ < 6144
+# define SHIFT_HZ	12
+#elif HZ >= 6144 && HZ < 12288
+# define SHIFT_HZ	13
 #else
 # error You lose.
 #endif
--- linux-2.6.0-test11/init/main.c	2003-11-26 15:43:09.000000000 -0500
+++ linux-2.6.0-test11-hz/init/main.c	2003-12-09 14:52:24.000000000 -0500
@@ -212,8 +212,8 @@
 
 /* Round the value and print it */	
 	printk("%lu.%02lu BogoMIPS\n",
-		loops_per_jiffy/(500000/HZ),
-		(loops_per_jiffy/(5000/HZ)) % 100);
+		HZ*(loops_per_jiffy>>3)/62500,
+		(HZ*(loops_per_jiffy>>3)/625)%100);
 }
 
 static int __init debug_kernel(char *str)
--- linux-2.6.0-test11/arch/i386/kernel/cpu/proc.c	2003-11-26 15:45:30.000000000 -0500
+++ linux-2.6.0-test11-hz/arch/i386/kernel/cpu/proc.c	2003-12-09 14:54:20.000000000 -0500
@@ -121,8 +121,8 @@
 			seq_printf(m, " %s", x86_cap_flags[i]);
 
 	seq_printf(m, "\nbogomips\t: %lu.%02lu\n\n",
-		     c->loops_per_jiffy/(500000/HZ),
-		     (c->loops_per_jiffy/(5000/HZ)) % 100);
+                     HZ*(c->loops_per_jiffy>>3)/62500,
+                     (HZ*(c->loops_per_jiffy>>3)/625)%100);
 	return 0;
 }
 
--- linux-2.6.0-test11/kernel/timer.c	2003-11-26 15:45:25.000000000 -0500
+++ linux-2.6.0-test11-hz/kernel/timer.c	2003-12-09 14:57:51.000000000 -0500
@@ -561,7 +561,11 @@
 	if (ltemp > (MAXPHASE / MINSEC) << SHIFT_UPDATE)
 	    ltemp = (MAXPHASE / MINSEC) << SHIFT_UPDATE;
 	time_offset += ltemp;
-	time_adj = -ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
+#if SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE > 0
+	    time_adj = -ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
+#else
+	    time_adj = -ltemp >> (SHIFT_HZ + SHIFT_UPDATE - SHIFT_SCALE);
+#endif
     } else {
 	ltemp = time_offset;
 	if (!(time_status & STA_FLL))
@@ -569,7 +573,11 @@
 	if (ltemp > (MAXPHASE / MINSEC) << SHIFT_UPDATE)
 	    ltemp = (MAXPHASE / MINSEC) << SHIFT_UPDATE;
 	time_offset -= ltemp;
-	time_adj = ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
+#if SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE > 0
+	    time_adj = ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
+#else
+	    time_adj = ltemp >> (SHIFT_HZ + SHIFT_UPDATE - SHIFT_SCALE);
+#endif
     }
 
     /*
--- linux-2.6.0-test11/include/net/tcp.h	2003-11-26 15:43:05.000000000 -0500
+++ linux-2.6.0-test11-hz/include/net/tcp.h	2003-12-09 15:03:50.000000000 -0500
@@ -486,8 +486,8 @@
    so that we select tick to get range about 4 seconds.
  */
 
-#if HZ <= 16 || HZ > 4096
-# error Unsupported: HZ <= 16 or HZ > 4096
+#if HZ <= 16 || HZ > 16384
+# error Unsupported: HZ <= 16 or HZ > 16384
 #elif HZ <= 32
 # define TCP_TW_RECYCLE_TICK (5+2-TCP_TW_RECYCLE_SLOTS_LOG)
 #elif HZ <= 64
@@ -502,8 +502,12 @@
 # define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
 #elif HZ <= 2048
 # define TCP_TW_RECYCLE_TICK (11+2-TCP_TW_RECYCLE_SLOTS_LOG)
-#else
+#elif HZ <= 4096
 # define TCP_TW_RECYCLE_TICK (12+2-TCP_TW_RECYCLE_SLOTS_LOG)
+#elif HZ <= 8192
+# define TCP_TW_RECYCLE_TICK (13+2-TCP_TW_RECYCLE_SLOTS_LOG)
+#else
+# define TCP_TW_RECYCLE_TICK (14+2-TCP_TW_RECYCLE_SLOTS_LOG)
 #endif
 
 /*
--- linux-2.6.0-test11/drivers/char/dtlk.c	2003-11-26 15:43:40.000000000 -0500
+++ linux-2.6.0-test11-hz/drivers/char/dtlk.c	2003-12-09 15:25:12.000000000 -0500
@@ -207,7 +207,7 @@
 				   up to 250 usec for the RDY bit to
 				   go nonzero. */
 				for (retries = 0;
-				     retries < loops_per_jiffy / (4000/HZ);
+				     retries < HZ*(loops_per_jiffy>>5)/125;
 				     retries++)
 					if (inb_p(dtlk_port_tts) &
 					    TTS_WRITABLE)
--- linux-2.6.0-test11/include/linux/isicom.h	2003-11-26 15:43:36.000000000 -0500
+++ linux-2.6.0-test11-hz/include/linux/isicom.h	2003-12-09 15:30:39.000000000 -0500
@@ -147,7 +147,7 @@
 	int			close_delay;
 	unsigned short		channel;
 	unsigned short		status;
-	unsigned short		closing_wait;
+	unsigned int		closing_wait;
 	struct isi_board	* card;
 	struct tty_struct 	* tty;
 	wait_queue_head_t	close_wait;
--- linux-2.6.0-test11/include/linux/hayesesp.h	2003-11-26 15:45:08.000000000 -0500
+++ linux-2.6.0-test11-hz/include/linux/hayesesp.h	2003-12-09 15:30:50.000000000 -0500
@@ -87,8 +87,8 @@
 	int			stat_flags;
 	int			custom_divisor;
 	int			close_delay;
-	unsigned short		closing_wait;
-	unsigned short		closing_wait2;
+	unsigned int		closing_wait;
+	unsigned int		closing_wait2;
 	int			IER; 	/* Interrupt Enable Register */
 	int			MCR; 	/* Modem control register */
 	unsigned long		event;
--- linux-2.6.0-test11/include/linux/generic_serial.h	2003-11-26 15:45:26.000000000 -0500
+++ linux-2.6.0-test11-hz/include/linux/generic_serial.h	2003-12-09 15:31:06.000000000 -0500
@@ -42,7 +42,7 @@
   int                     blocked_open;
   struct tty_struct       *tty;
   unsigned long           event;
-  unsigned short          closing_wait;
+  unsigned int          closing_wait;
   int                     close_delay;
   struct real_driver      *rd;
   int                     wakeup_chars;
--- linux-2.6.0-test11/include/linux/cyclades.h	2003-11-26 15:46:06.000000000 -0500
+++ linux-2.6.0-test11-hz/include/linux/cyclades.h	2003-12-09 15:31:19.000000000 -0500
@@ -581,7 +581,7 @@
 	int			custom_divisor;
 	int                     x_char; /* to be pushed out ASAP */
 	int			close_delay;
-	unsigned short		closing_wait;
+	unsigned int		closing_wait;
 	unsigned long		event;
 	unsigned long		last_active;
 	int			count;	/* # of fd on device */
--- linux-2.6.0-test11/include/linux/serialP.h	2003-11-26 15:42:57.000000000 -0500
+++ linux-2.6.0-test11-hz/include/linux/serialP.h	2003-12-09 15:29:12.000000000 -0500
@@ -47,8 +47,8 @@
 	int	count;
 	u8	*iomem_base;
 	u16	iomem_reg_shift;
-	unsigned short	close_delay;
-	unsigned short	closing_wait; /* time to wait before closing */
+	unsigned int	close_delay;
+	unsigned int	closing_wait; /* time to wait before closing */
 	struct async_icount	icount;	
 	int	io_type;
 	struct async_struct *info;
@@ -69,8 +69,8 @@
 	int			quot;
 	int			x_char;	/* xon/xoff character */
 	int			close_delay;
-	unsigned short		closing_wait;
-	unsigned short		closing_wait2; /* obsolete */
+	unsigned int		closing_wait;
+	unsigned int		closing_wait2; /* obsolete */
 	int			IER; 	/* Interrupt Enable Register */
 	int			MCR; 	/* Modem control register */
 	int			LCR; 	/* Line control register */
--- linux-2.6.0-test11/include/net/irda/ircomm_tty.h	2003-11-26 15:43:37.000000000 -0500
+++ linux-2.6.0-test11-hz/include/net/irda/ircomm_tty.h	2003-12-09 15:28:17.000000000 -0500
@@ -97,8 +97,8 @@
 	struct timer_list watchdog_timer;
 	struct work_struct  tqueue;
 
-        unsigned short    close_delay;
-        unsigned short    closing_wait; /* time to wait before closing */
+        unsigned int    close_delay;
+        unsigned int    closing_wait; /* time to wait before closing */
 
 	int  open_count;
 	int  blocked_open;	/* # of blocked opens */
--- linux-2.6.0-test11/include/linux/serial.h	2003-11-26 15:43:24.000000000 -0500
+++ linux-2.6.0-test11-hz/include/linux/serial.h	2003-12-09 15:27:09.000000000 -0500
@@ -39,12 +39,12 @@
 	int	xmit_fifo_size;
 	int	custom_divisor;
 	int	baud_base;
-	unsigned short	close_delay;
+	unsigned int	close_delay;
 	char	io_type;
 	char	reserved_char[1];
 	int	hub6;
-	unsigned short	closing_wait; /* time to wait before closing */
-	unsigned short	closing_wait2; /* no longer used... */
+	unsigned int	closing_wait; /* time to wait before closing */
+	unsigned int	closing_wait2; /* no longer used... */
 	unsigned char	*iomem_base;
 	unsigned short	iomem_reg_shift;
 	unsigned int	port_high;

[-- Attachment #2: Ceci est une partie de message numériquement signée. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]