unrelated 2.4.x (x=0-9) sound

unrelated 2.4.x (x=0-9) sound

[Samium Gromoff]

     hello guys...
    this time it is not a crash, just a misfeature... ;)
    i`m used to have the following issue:
  sound clicks and flakiness while scrolling console
  text in mc. 

    less is also hit by this issue, but this is some
  strange: if in mc case _each_ keypress produce
  clicks, in less case only the first scrollup
  after switching to less` console does...

    important detail: it clicks *much* more when
  scrolling up (when scrolling down, clicks are quite
  hard to realize).

    one more important detail: for me it is quite
  _annoyingly_ reproducible... ;)

    this behaviour is seen by me on two boxes:
  p166/24M/Zida 2dvx/s3V+/sb16_genuine
  5x86-150/12M/Asus SP4G/trident 512/es688

    also the load _while_ playing mp3 _and_ scrolling
  is ~60% on p166 (not 100% i mean).

    this doesnt depend on the nature of sound, ie
  if sound source is plain wav, which doesnt use cpu,
  these clicks are here, not more, not less...

    something makes me think/remember that this is not
  the case on 2.2.x, but i`m far not sure...

---


cheers,


   Samium Gromoff

Re: unrelated 2.4.x (x=0-9) sound

[Alan Cox]

>     this time it is not a crash, just a misfeature... ;)
>     i`m used to have the following issue:
>   sound clicks and flakiness while scrolling console
>   text in mc. 

Well there are three causes for this generally

1.	Video cards pulling stupid pranks to get good benchmark results
2.	Chipsets that don't give the ISA bus any useful share of bandwidth
	during AGP or PCI traffic
3.	The console locks

#3 is fixed in -ac
#2 isnt generally fixable but some bioses let you alter the fairness/pci
	rules
#1 normally only appears in X11

Re: unrelated 2.4.x (x=0-9) sound

[Alan Cox]

>     i.e. you mean that PCI-ISA bridge doesnt provide enough
>   realtimeness to fill internal sb buffer?

Yep.

>      i have the next "but": isn`t internal sb buffer
>   enough large to flatten these io peaks?

>From memory the internal buffer is something like 64 or 128 bytes.

>      but next why: why "find /" does not achieve
>   same effect? the datastream is _way_ larger!

It may depend whether the CPU is generating the traffic or not. On some
bridges CPU generated writes win all bus arbitrations by default

unrelated 2.4.x (x=0-9) sound

[Samium Gromoff]

> 2.      Chipsets that don't give the ISA bus any useful share of bandwidth
>         during AGP or PCI traffic
    i.e. you mean that PCI-ISA bridge doesnt provide enough
  realtimeness to fill internal sb buffer?

     yes it sounds like that, because i can hardly
  realize their existence at 11025... (but i suppose
  if they were, i hardly would be able to hear them...)

     i have the next "but": isn`t internal sb buffer
  enough large to flatten these io peaks?

     even more: sound click even when i strike the key once, with 100% probability.

     ofcourse this is maybe because mc sends alot of data
  over the bus in the response to the keypress.
  
     it also explains why less clicks only after
  first-after-consoleswitch-keypress.

     but next why: why "find /" does not achieve
  same effect? the datastream is _way_ larger!

---


cheers,


   Samium Gromoff

unrelated 2.4.x (x=0-9) sound

[Samium Gromoff]

     oh hell... 
     Sorry, writing in parallel in two different
  threads really hurts...
     should forward this to [OT] Howl of soul...


> > >      i feel like the media isn`t downgrading because
> > >  the badblocks _arent_ physical: low-level drive
> > >  reformat doesnt show anything.

> > the low-level format merely remaps bad blocks to spare ones.
> > eventually, you'll run out of spare blocks, and then...
>     no no no - when ibm DFT (drive fitness test)
>   runs on physical bblks i _hear_ this! (and also
   it tells me).

[ship]



---


cheers,


   Samium Gromoff

unrelated 2.4.x (x=0-9) sound

[Samium Gromoff]

> >      i feel like the media isn`t downgrading because
> >  the badblocks _arent_ physical: low-level drive
> >  reformat doesnt show anything.

> the low-level format merely remaps bad blocks to spare ones.
> eventually, you'll run out of spare blocks, and then...
    no no no - when ibm DFT (drive fitness test)
  runs on physical bblks i _hear_ this! (and also
  it tells me).

    also how do you like _continuous_ 100-200 - large
  zone of bblks, and _nothing_ more!

    it these were real bblks, they appears like
  dots on surface, thus killing _physically_ neighbouring
  sectors of _different_ cylinders, so there should be
  some cyclic pattern of them.

    And in my case the is not pattern - there is only
  a sequence of 100-200 bblks...

    You ask how do i know this? I had wrote a modification
  to debugreiserfs which in early versions scanned
  journal for bblks and zeroified them, so they
  are remapped(?), and later i rewroted it to scan
  the whole drive, so i know here the situation...

> but the whole point of checksum errors is that the corrupted
> transfer is discarded and retried.  just like with TCP or UDP.
  okay, i`d selected the wrong exmple, but
  imagine:
   1. drive gets data over udma along with crc.
   2. drive checks crc(data) with crc_from_udma_cable,
    and it is okay.
     3a. drive corrupts data.
     4a. drive writes the corrupted data, with right crc.
     3b. drive corrupts crc.
     4b. drive writes the right data with corrupted crc.
   The only assumption here is needed, is that
  these corruptions belongs only to the udma-specific
  process... (e.g why UDMA?)

> also, aren't the corruptions to specific blocks?  the kind
> of checksum failure you're talking about would be uniformly
> distributed over all transfers, not sector-specific.
   internal drive super-optimizing firmware is black magik... (remember pentium-math issues?)

---


cheers,


   Samium Gromoff