RyT43LRBHW5CT3TxqW9KEVIT7FBc4XeIrpIEsOoeTK4JELmPw==   
   NLD9ftVPuOOIOyUS5u5Z/g0ko49CLwKc6+3JEEGgQu10bqN7EZO/lszZb3SYS6yN   
   h26KgzD0TunlBgXPsiV+3/feU9P7ysrAVhIkct7/nf2dzx4A"; mail-complain   
   s-to="abuse@albasani.net"   
   From: "Ruediger Ihle"    
      
   On Sat, 11 Dec 2010 21:25:53 UTC, "Rich Walsh"  wrote:   
      
   > I don't know of any app on OS/2 that uses isochronous transfer and thus has   
   > a "right" to be timing-sensitive.     
      
   USB audio does. And a strange IR remote control device supported by one   
   of my drivers...   
      
      
   > Apps using bulk transfer should not expect data to arrive on any schedule.     
   > If they do, they're probably badly designed.   
      
   Almost any USB2.0 digital TV stick uses high-speed bulk transfers. These   
   devices deliver a continous MPEG transport stream at about 16MBits/s and   
   don't really have internal buffers. I'm not sure about USB network adapters,   
   but I would expect something similar.   
      
   BTW, it's not the pure interrupt load, that causes the problems. Since   
   The USB drivers use context hooks for transfering data. That means an    
   arbitrary thread in the system will be "hijacked" to perform operations   
   on behalf of USB. This can be the main GUI thread of any app or a deamon   
   process dedicated for some other important task. We see this extensively   
   when a USB2.0 device is attached. Since the root hub implementation in    
   USBEHCD even blocks inside such a context hook handler, it may cause    
   the whole system to become unresponsive for a several seconds.   
      
      
   > In any case, the vast majority of users are doing interrupt-driven bulk   
   > transfers to/from storage devices and would like to see the process move   
   > along as quickly as possible.   
      
   I don't really like my media streaming to be interrupted by copying   
   some files to a USB stick. The behavior on attachment/detachment is   
   bad enough.    
      
   BTW, a good place for improvements on the storage side would be    
   FAT32.IFS. I don't know which file systems other people use on USB    
   media, but for me this file system is the only one that is compatible   
   with most other OSes and that allows long file names. And the OS/2    
   implementation is incredibly slow.   
      
      
   > > a parameter to control this is certainly feasible. I'll think about it.   
   >    
   > Please do.   
      
   A parameter would be required, definitively.   
      
      
      
      
   --    
   Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]   
   http://www.s-t.de   
      
      
   --- Internet Rex 2.31   
    * Origin: S&T (1:261/20.999)