Re: PC speaker driver patch for 2.4.0-test10-pre3
On Tue, 24 Oct 2000, Pavel Machek wrote: > Hi! > > > > [EMAIL PROTECTED] said: > > > > You can also pretty trivially keep track of an error term so that the > > > > clock is right on average: > > > > > > True, but I don't want 'right on average'. I want 'not screwed with at all'. > > > Shifting the timer tick onto the RTC will give me that. > > > > > > Even if we _do_ get the maths right, fudging with the frequency of the > > > system timer is still an ugly hack. > > > > I personally think the system timer is already an ugly hack. HZ is > > arbitrary, slow by modern standards, and introduces latency. > > As the comment you quoted points out, it's also not very accurate. > > Much better would be an agenda structure with one shot timers between > > events and jiffies based on cycle counters. This works on modern hardware > > and scales well for higher processor speeds. > > ...and breaks horribly when your CPU frequency changes... like on most > current notebooks. The unit of time is arbitrary. Cycle counts just happens to be convenient on most machines and very high resolution. The important point is that hanging tasks off a periodic low-resolution timer is not scaling with CPU clock speeds at all and there are ways to throw it out. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
Hi! > > [EMAIL PROTECTED] said: > > > You can also pretty trivially keep track of an error term so that the > > > clock is right on average: > > > > True, but I don't want 'right on average'. I want 'not screwed with at all'. > > Shifting the timer tick onto the RTC will give me that. > > > > Even if we _do_ get the maths right, fudging with the frequency of the > > system timer is still an ugly hack. > > I personally think the system timer is already an ugly hack. HZ is > arbitrary, slow by modern standards, and introduces latency. > As the comment you quoted points out, it's also not very accurate. > Much better would be an agenda structure with one shot timers between > events and jiffies based on cycle counters. This works on modern hardware > and scales well for higher processor speeds. ...and breaks horribly when your CPU frequency changes... like on most current notebooks. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
Hi! [EMAIL PROTECTED] said: You can also pretty trivially keep track of an error term so that the clock is right on average: True, but I don't want 'right on average'. I want 'not screwed with at all'. Shifting the timer tick onto the RTC will give me that. Even if we _do_ get the maths right, fudging with the frequency of the system timer is still an ugly hack. I personally think the system timer is already an ugly hack. HZ is arbitrary, slow by modern standards, and introduces latency. As the comment you quoted points out, it's also not very accurate. Much better would be an agenda structure with one shot timers between events and jiffies based on cycle counters. This works on modern hardware and scales well for higher processor speeds. ...and breaks horribly when your CPU frequency changes... like on most current notebooks. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Tue, 24 Oct 2000, Pavel Machek wrote: Hi! [EMAIL PROTECTED] said: You can also pretty trivially keep track of an error term so that the clock is right on average: True, but I don't want 'right on average'. I want 'not screwed with at all'. Shifting the timer tick onto the RTC will give me that. Even if we _do_ get the maths right, fudging with the frequency of the system timer is still an ugly hack. I personally think the system timer is already an ugly hack. HZ is arbitrary, slow by modern standards, and introduces latency. As the comment you quoted points out, it's also not very accurate. Much better would be an agenda structure with one shot timers between events and jiffies based on cycle counters. This works on modern hardware and scales well for higher processor speeds. ...and breaks horribly when your CPU frequency changes... like on most current notebooks. The unit of time is arbitrary. Cycle counts just happens to be convenient on most machines and very high resolution. The important point is that hanging tasks off a periodic low-resolution timer is not scaling with CPU clock speeds at all and there are ways to throw it out. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > You can also pretty trivially keep track of an error term so that the > > clock is right on average: > > True, but I don't want 'right on average'. I want 'not screwed with at all'. > Shifting the timer tick onto the RTC will give me that. > > Even if we _do_ get the maths right, fudging with the frequency of the > system timer is still an ugly hack. I personally think the system timer is already an ugly hack. HZ is arbitrary, slow by modern standards, and introduces latency. As the comment you quoted points out, it's also not very accurate. Much better would be an agenda structure with one shot timers between events and jiffies based on cycle counters. This works on modern hardware and scales well for higher processor speeds. As for the current inaccuracy, the jitter introduced by using an error term can never be more than a single real interrupt cycle, which is already well below the average userspace latency. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
[EMAIL PROTECTED] said: > You can also pretty trivially keep track of an error term so that the > clock is right on average: True, but I don't want 'right on average'. I want 'not screwed with at all'. Shifting the timer tick onto the RTC will give me that. Even if we _do_ get the maths right, fudging with the frequency of the system timer is still an ugly hack. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote:
> See arch/i386/kernel/time.c:
>
> /* This function must be called with interrupts disabled
> * It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
> *
> * However, the pc-audio speaker driver changes the divisor so that
> * it gets interrupted rather more often - it loads 64 into the
> * counter rather than 11932! This has an adverse impact on
> * do_gettimeoffset() -- it stops working! What is also not
> * good is that the interval that our timer function gets called
> * is no longer 10.0002 ms, but 9.9767 ms. To get around this
> * would require using a different timing source.
You can also pretty trivially keep track of an error term so that the
clock is right on average:
#define CLK_HZ 1193200 /* or whatever */
#define ET_PRECISION 1000
#define ET_TIMER_TICKS CLK_HZ*ET_PRECISION/HZ
#define ET_PCSP_TICKS 64*ET_PRECISION
...
static long et=0;
...
et+=ET_PCSP_TICKS;
if(et>ET_TIMER_TICKS) {
et-=ET_TIMER_TICKS;
simulate_timer_tick();
}
This keeps track of the residual timing error to a few decimal places to
several decimal places and will get closer to HZ than even the current
code.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
[EMAIL PROTECTED] said: > Apparently Linus doesn't like the way it handles interrupts or > something, and is therefore 'wrong.' ::shrug:: As long as it's > available though, I'll use it ;p It's not just 'wrong'. It's 'sick'. But it works. The correct fix is to shift the system timer onto the RTC, leaving the 8253 timer available for us to abuse for the PC speaker. See arch/i386/kernel/time.c: /* This function must be called with interrupts disabled * It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs * * However, the pc-audio speaker driver changes the divisor so that * it gets interrupted rather more often - it loads 64 into the * counter rather than 11932! This has an adverse impact on * do_gettimeoffset() -- it stops working! What is also not * good is that the interval that our timer function gets called * is no longer 10.0002 ms, but 9.9767 ms. To get around this * would require using a different timing source. Maybe someone * could use the RTC - I know that this can interrupt at frequencies * ranging from 8192Hz to 2Hz. If I had the energy, I'd somehow fix * it so that at startup, the timer code in sched.c would select * using either the RTC or the 8253 timer. The decision would be * based on whether there was any other device around that needed * to trample on the 8253. I'd set up the RTC to interrupt at 1024 Hz, * and then do some jiggery to have a version of do_timer that * advanced the clock by 1/1024 s. Every time that reached over 1/100 * of a second, then do all the old code. If the time was kept correct * then do_gettimeoffset could just return 0 - there is no low order * divider that can be accessed. * * Ideally, you would be able to use the RTC for the speaker driver, * but it appears that the speaker driver really needs interrupt more * often than every 120 us or so. * * Anyway, this needs more thought pjsg (1993-08-28) * * If you are really that interested, you should be reading * comp.protocols.time.ntp! */ -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
[EMAIL PROTECTED] said: Apparently Linus doesn't like the way it handles interrupts or something, and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll use it ;p It's not just 'wrong'. It's 'sick'. But it works. The correct fix is to shift the system timer onto the RTC, leaving the 8253 timer available for us to abuse for the PC speaker. See arch/i386/kernel/time.c: /* This function must be called with interrupts disabled * It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs * * However, the pc-audio speaker driver changes the divisor so that * it gets interrupted rather more often - it loads 64 into the * counter rather than 11932! This has an adverse impact on * do_gettimeoffset() -- it stops working! What is also not * good is that the interval that our timer function gets called * is no longer 10.0002 ms, but 9.9767 ms. To get around this * would require using a different timing source. Maybe someone * could use the RTC - I know that this can interrupt at frequencies * ranging from 8192Hz to 2Hz. If I had the energy, I'd somehow fix * it so that at startup, the timer code in sched.c would select * using either the RTC or the 8253 timer. The decision would be * based on whether there was any other device around that needed * to trample on the 8253. I'd set up the RTC to interrupt at 1024 Hz, * and then do some jiggery to have a version of do_timer that * advanced the clock by 1/1024 s. Every time that reached over 1/100 * of a second, then do all the old code. If the time was kept correct * then do_gettimeoffset could just return 0 - there is no low order * divider that can be accessed. * * Ideally, you would be able to use the RTC for the speaker driver, * but it appears that the speaker driver really needs interrupt more * often than every 120 us or so. * * Anyway, this needs more thought pjsg (1993-08-28) * * If you are really that interested, you should be reading * comp.protocols.time.ntp! */ -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote:
See arch/i386/kernel/time.c:
/* This function must be called with interrupts disabled
* It was inspired by Steve McCanne's microtime-i386 for BSD. -- jrs
*
* However, the pc-audio speaker driver changes the divisor so that
* it gets interrupted rather more often - it loads 64 into the
* counter rather than 11932! This has an adverse impact on
* do_gettimeoffset() -- it stops working! What is also not
* good is that the interval that our timer function gets called
* is no longer 10.0002 ms, but 9.9767 ms. To get around this
* would require using a different timing source.
You can also pretty trivially keep track of an error term so that the
clock is right on average:
#define CLK_HZ 1193200 /* or whatever */
#define ET_PRECISION 1000
#define ET_TIMER_TICKS CLK_HZ*ET_PRECISION/HZ
#define ET_PCSP_TICKS 64*ET_PRECISION
...
static long et=0;
...
et+=ET_PCSP_TICKS;
if(etET_TIMER_TICKS) {
et-=ET_TIMER_TICKS;
simulate_timer_tick();
}
This keeps track of the residual timing error to a few decimal places to
several decimal places and will get closer to HZ than even the current
code.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
[EMAIL PROTECTED] said: You can also pretty trivially keep track of an error term so that the clock is right on average: True, but I don't want 'right on average'. I want 'not screwed with at all'. Shifting the timer tick onto the RTC will give me that. Even if we _do_ get the maths right, fudging with the frequency of the system timer is still an ugly hack. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 23 Oct 2000, David Woodhouse wrote: [EMAIL PROTECTED] said: You can also pretty trivially keep track of an error term so that the clock is right on average: True, but I don't want 'right on average'. I want 'not screwed with at all'. Shifting the timer tick onto the RTC will give me that. Even if we _do_ get the maths right, fudging with the frequency of the system timer is still an ugly hack. I personally think the system timer is already an ugly hack. HZ is arbitrary, slow by modern standards, and introduces latency. As the comment you quoted points out, it's also not very accurate. Much better would be an agenda structure with one shot timers between events and jiffies based on cycle counters. This works on modern hardware and scales well for higher processor speeds. As for the current inaccuracy, the jitter introduced by using an error term can never be more than a single real interrupt cycle, which is already well below the average userspace latency. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Sun, 22 Oct 2000, Dr. Kelsey Hudson wrote: >Date: Sun, 22 Oct 2000 13:39:09 -0700 (PDT) >From: Dr. Kelsey Hudson <[EMAIL PROTECTED]> >To: Mike A. Harris <[EMAIL PROTECTED]> >Cc: David Woodhouse <[EMAIL PROTECTED]>, > Linux Kernel mailing list <[EMAIL PROTECTED]> >Content-Type: TEXT/PLAIN; charset=US-ASCII >Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3 > >> Is there a major compelling reason that this patch isn't included >> in the standard kernel tree? >> >> >> -- >> Mike A. Harris - Linux advocate - Open source advocate >> Computer Consultant - Capslock Consulting >> Copyright 2000 all rights reserved >> -- > >Apparently Linus doesn't like the way it handles interrupts or something, >and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll >use it ;p Someone has explained to me why it isn't included, and it made decent sense to me. Probably best left as a patch... -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- #[Mike A. Harris bash tip #1 - separate history files per virtual console] # Put the following at the bottom of your ~/.bash_profile [ ! -d ~/.bash_histdir ] && mkdir ~/.bash_histdir tty |grep "^/dev/tty[0-9]" >& /dev/null && \ export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
> Is there a major compelling reason that this patch isn't included > in the standard kernel tree? > > > -- > Mike A. Harris - Linux advocate - Open source advocate > Computer Consultant - Capslock Consulting > Copyright 2000 all rights reserved > -- Apparently Linus doesn't like the way it handles interrupts or something, and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll use it ;p Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
Is there a major compelling reason that this patch isn't included in the standard kernel tree? -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Apparently Linus doesn't like the way it handles interrupts or something, and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll use it ;p Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Sun, 22 Oct 2000, Dr. Kelsey Hudson wrote: Date: Sun, 22 Oct 2000 13:39:09 -0700 (PDT) From: Dr. Kelsey Hudson [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: David Woodhouse [EMAIL PROTECTED], Linux Kernel mailing list [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: PC speaker driver patch for 2.4.0-test10-pre3 Is there a major compelling reason that this patch isn't included in the standard kernel tree? -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Apparently Linus doesn't like the way it handles interrupts or something, and is therefore 'wrong.' ::shrug:: As long as it's available though, I'll use it ;p Someone has explained to me why it isn't included, and it made decent sense to me. Probably best left as a patch... -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- #[Mike A. Harris bash tip #1 - separate history files per virtual console] # Put the following at the bottom of your ~/.bash_profile [ ! -d ~/.bash_histdir ] mkdir ~/.bash_histdir tty |grep "^/dev/tty[0-9]" /dev/null \ export HISTFILE=~/.bash_histdir/.$(tty | sed -e 's/.*\///') - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
> >Thanks to Erik Inge Bols=F8 for porting it to 2.3.45, this saving me m= > ost of=20 > >the work. > > Is there a major compelling reason that this patch isn't included > in the standard kernel tree? It goes hacking around with the clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Tue, 17 Oct 2000, Mike A. Harris wrote: > Is there a major compelling reason that this patch isn't included > in the standard kernel tree? It does _evil_ things with the timers. If we shift the system timer tick onto the RTC, it won't be so evil, and I'd consider trying to submit it for 2.5. Patches accepted. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
Thanks to Erik Inge Bols=F8 for porting it to 2.3.45, this saving me m= ost of=20 the work. Is there a major compelling reason that this patch isn't included in the standard kernel tree? It goes hacking around with the clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 16 Oct 2000, David Woodhouse wrote: >Date: Mon, 16 Oct 2000 16:07:13 +0100 >From: David Woodhouse <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Content-Type: text/plain; charset=iso-8859-15 >Subject: PC speaker driver patch for 2.4.0-test10-pre3 > >ftp.uk.linux.org:/pub/people/dwmw2/pcsp/patch-pcsp-soundcore-2.4.0-test10-pre3 > >Thanks to Erik Inge Bolsø for porting it to 2.3.45, this saving me most of >the work. Is there a major compelling reason that this patch isn't included in the standard kernel tree? -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- [Quote: Linus Torvalds linux-2.4.0-test8-pre6 release message - Sept 6, 2000] But I have this ugly feeling that I'm coming down with the same flu that everybody else in my family had the last week, so I'd better release this before I start puking on my keyboard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PC speaker driver patch for 2.4.0-test10-pre3
On Mon, 16 Oct 2000, David Woodhouse wrote: Date: Mon, 16 Oct 2000 16:07:13 +0100 From: David Woodhouse [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-15 Subject: PC speaker driver patch for 2.4.0-test10-pre3 ftp.uk.linux.org:/pub/people/dwmw2/pcsp/patch-pcsp-soundcore-2.4.0-test10-pre3 Thanks to Erik Inge Bolsø for porting it to 2.3.45, this saving me most of the work. Is there a major compelling reason that this patch isn't included in the standard kernel tree? -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- [Quote: Linus Torvalds linux-2.4.0-test8-pre6 release message - Sept 6, 2000] But I have this ugly feeling that I'm coming down with the same flu that everybody else in my family had the last week, so I'd better release this before I start puking on my keyboard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
