There's something fundamentally wrong with your OS architecture when 
copying a directory full of files from one drive to another makes your 
hardware-accelerated mouse cursor so jittery it's literally unusable. 
Sheesh.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> There's something fundamentally wrong with your OS architecture when 
> copying a directory full of files from one drive to another makes your 
> hardware-accelerated mouse cursor so jittery it's literally unusable. 
> Sheesh.

  Are you sure it's a problem with the OS and not the hardware?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> There's something fundamentally wrong with your OS architecture when 
>> copying a directory full of files from one drive to another makes your 
>> hardware-accelerated mouse cursor so jittery it's literally unusable. 
>> Sheesh.
> 
>   Are you sure it's a problem with the OS and not the hardware?

I never had it happen before, nope, and it doesn't happen unless I'm 
flogging at disks.

I mean, I think it's that the touchscreen bit is probably running in 
user space, and the USB channel is probably hogging a bunch of kernel 
CPU decoding packets or something. The CPU time always skyrockets when 
whapping away at USB.

But if you're not handling something as easy as moving the cursor 
pointer in an interrupt routine when the hardware supports sprites for 
the cursor, there's something wrong, methinks. I wish AmigaDOS scaled. :-)

I think I figured out why my Linux audio is inconsistently functional, 
too. There are messages showing up in dmesg about not being able to load 
the new microcode for the audio card or something, and then /dev/audio 
doesn't show up. If I leave the power off long enough after running 
Windows, it seems to work much more reliably, so I'm suspecting Windows 
is reconfiguring the board, then Linux tries to reconfigure it in an 
incompatible way. Or something.  Annoying.  :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

> There's something fundamentally wrong with your OS architecture when 
> copying a directory full of files from one drive to another makes your 
> hardware-accelerated mouse cursor so jittery it's literally unusable.

What annoys me is when you put in a CD or DVD that is a bit scratched, then 
it makes any program that is trying to access the drive (windows explorer, 
CD burner etc) grind to a complete halt until the hardware has recognised 
the disc.

Post a reply to this message

scott wrote:
>> There's something fundamentally wrong with your OS architecture when 
>> copying a directory full of files from one drive to another makes your 
>> hardware-accelerated mouse cursor so jittery it's literally unusable.
> 
> What annoys me is when you put in a CD or DVD that is a bit scratched, 
> then it makes any program that is trying to access the drive (windows 
> explorer, CD burner etc) grind to a complete halt until the hardware has 
> recognised the disc.

Yeah. There are lots of OSes that assume disk access is fast enough you 
can block while it goes on. (Indeed, I think I saw in the release notes 
that they just fixed this in the latest Linux kernel, letting you now 
kill a process waiting on disk access, but it's been like that in UNIX 
since before V7.)

The *real* killer is when things not accessing that disk get locked up. 
I can see it if Explorer for example gets stuck waiting for a disk read 
to return, but something running elsewhere (like your database server) 
without accessing that drive shouldn't wait. I'm honestly not sure how 
much Windows locks things up if you're not accessing that drive. I know 
that heavy I/O (like, say, defragging a disk) can make Windows pretty 
unusable until it finishes, blocking paging and such.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

And lo on Wed, 23 Apr 2008 07:46:23 +0100, scott <sco### [at] laptopcom> did  
spake, saying:

>> There's something fundamentally wrong with your OS architecture when  
>> copying a directory full of files from one drive to another makes your  
>> hardware-accelerated mouse cursor so jittery it's literally unusable.
>
> What annoys me is when you put in a CD or DVD that is a bit scratched,  
> then it makes any program that is trying to access the drive (windows  
> explorer, CD burner etc) grind to a complete halt until the hardware has  
> recognised the disc.

Still does that in Vista too. Oh my other best Vista moment; if you've  
read my blog entry about my boss flattening his photo folders then I  
missed this bit.

Windows Explorer, my boss moves the photos he wants to keep into another  
folder then clicks on the now purposeless folder in the folder tree list  
and presses Del and Yes and the folder heads to the bin, but the file  
window still displays the contents of the now non-existing folder until he  
selects a different folder. Focus hasn't changed so he thinks he's deleted  
the wrong folder by accident because see all the files are stil there;  
that really messed him up until he worked out was was happening.

-- 
Phil Cook

--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Yeah. There are lots of OSes that assume disk access is fast enough you 
> can block while it goes on. (Indeed, I think I saw in the release notes 
> that they just fixed this in the latest Linux kernel, letting you now 
> kill a process waiting on disk access, but it's been like that in UNIX 
> since before V7.)

  Linux indeed had this problem too: If there was an error reading a DVD,
the system would become *extremely* sluggish for something like 5 minutes
(and the program which attempted the read completely unresponsive for that
time). There was a trick to reduce this time, and it was to reduce the
read ahead amount for the DVD drive using /sbin/hdparm -a.

  But as you say, maybe they have fixed that lately because it hasn't been
happening lately, even with erroneus DVDs.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   But as you say, maybe they have fixed that lately because it hasn't been
> happening lately, even with erroneus DVDs.


I don't know if they fixed that specifically. I just saw in the release 
notes of the new kernel you posted a few days ago that it's possible to 
now kill-9 some types of processes blocked on a "fast wait" that isn't 
so fast after all. So steps are being taken.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

> Warp wrote:
>>   But as you say, maybe they have fixed that lately because it hasn't 
>> been
>> happening lately, even with erroneus DVDs.
> 
> 
> I don't know if they fixed that specifically. I just saw in the release 
> notes of the new kernel you posted a few days ago that it's possible to 
> now kill-9 some types of processes blocked on a "fast wait" that isn't 
> so fast after all. So steps are being taken.

I remember having trouble with FUSE filesystems. If I had a sshfs 
filesystem mounted, and a program tried to access a file from it, and 
the network connection dropped, very often the program got completely 
hanged and not even kill -9 got rid of it, until a (looong) timeout.

Post a reply to this message