> just to let you know what the ARCHOS jukebox does when connected properly per USB 
>2.0:

Sounds like it'd be a nice product to have ... :)


> ---------------------------------------------------------------------------
> I measured the following:
>
> #hdparm -t /dev/sda1
>
> /dev/sda1:
>  Timing buffered disk reads:  64 MB in  8.71 seconds =  7.35 MB/sec
>
> ... not too bad? that is probably just limited by the disk speed.....

Could well be.  A PII/300 gets about 12 MB/sec on fast-ish drives.

You certainly see delays from usb-storage serializing every request,
so that plays games there too.  But your K6-2/300 isn't all that much
slower than a PII/300, so I'd suspect that disk speed is right.

On the other hand, your Bonnie numbers were faster, which isn't
what I'm used to seeing.  Not that I'd worry, Bonnie is more like real
world performance.

Good to see some numbers from other folk, too.  Four CDs copied
and verified in about one minute ... that speed makes a difference!

- Dave


> #hdparm -T /dev/sda1
>
> /dev/sda1:
>  Timing buffer-cache reads:   128 MB in  2.84 seconds = 45.07 MB/sec
>
> This brings my cpu (AMD K6/2 300 Mhz) to full load (100%). so the CPU seems to be 
>the limit.
>
> # bonnie
> File './Bonnie.7746', size: 104857600
> Writing with putc()...done
> Rewriting...done
> Writing intelligently...done
> Reading with getc()...done
> Reading intelligently...done
> Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
>               -------Sequential Output-------- ---Sequential Input-- --Random--
>               -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
> Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
>           100  5092 44.5 12174 33.4  4502 17.5  9156 66.7 15867 28.8 2822.1 43.0
>
> this isn't slow either.....
> ----------------------------------------------
>
> So in effect, I use "rsync" to copy mp3-files from my Linux box to the ARCHOS at a 
>rather
interesting
> speed.
> If you watch it, its approx 1-2  seconds per title really copied, plus the time for 
>checking the
> already transferred ones.
>
> For a "rsync" with no copy actions I need 23 seconds on approx 4000 files on both 
>sides. When
copying
> 191 Megs (4 complete CDs) via rsync (including the file compare) this is about 65 
>seconds.
>
> So its really usable!
>
>     Christian
>
> ..............................
>
>
> David Brownell wrote:
>
> > I forget, didn't you verify that this problem repeated just
> > as cleanly using this device in USB 1.1 mode?
> >
> > I'm recalling this as an issue where the usb-storage
> > driver needed to update its error handling, and there
> > was no particular "USB 2.0" issue.  And at any rate
> > the patch is to usb-storage ...
> >
> > I'm glad that with the patch, you can use another USB 2.0
> > device with Linux!
> >
> > - Dave
> >
> > > >>> Proposed workaround:
> > >
> > > set us->notify also in cases where the urb returns status DID_ERROR, not
> > > only DID_ABORT:
> > >
> > > patch:
> >
> 
>-----------------------------------------------------------------------------------------------
> > >
> > > --- usb.c       Tue Apr 16 21:17:56 2002
> > > +++ usb.c-cm    Tue Apr 16 21:16:56 2002
> > > @@ -465,7 +465,12 @@
> > >                                 US_DEBUGP("scsi cmd done,
> > > result=0x%x\n",
> > >                                            us->srb->result);
> > >                                 set_current_state(TASK_INTERRUPTIBLE);
> > > -                               us->srb->scsi_done(us->srb);
> > > +/*05-Apr-02 cm*/
> > > +                               if (us->srb->scsi_done)
> > > +                                    us->srb->scsi_done(us->srb);
> > > +                               US_DEBUGP("scsi_done() called\n");
> > > +                               if (us->srb->result == DID_ERROR <<
> > > 16)    /* scsi_abort may wait here */
> > > +                                   complete(&(us->notify));
> > >                         } else {
> > >                                 US_DEBUGP("scsi command aborted\n");
> > >                                 set_current_state(TASK_INTERRUPTIBLE);
> >
> 
>------------------------------------------------------------------------------------------------
> > >
> > > Any Comments?
> > >
> > > I can come around the problem with the patch, but I feel not strong
> > > enough to correct this problem the "proper" way.
> > >
> > > On the other hand I feel that the SCSI command abortion procedure may be
> > > broken anyhow when perfomed in the presence of lower layer errors
> > > (which may be the cause for the abortion in the first place)
> > >
> > > What shall we do?
> > >
> > >  Christian
> > >
> > >
> > > PS: I want to keep this neat device "archos jukebox", snice this bug is
> > > perfectly reproducible.............
> > >
> > >
> > >
> > > --
> > > Christian Mahr (privat)                  [EMAIL PROTECTED]
> > >
> > >



_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to