Loading ...
Sorry, an error occurred while loading the content.

Re: I need a hint (or several)...

Expand Messages
  • iithomas
    ... W2K SP3 - and also tested at another pc at connected to the same hub running Win98SE (*same* result: a 2143KB file took 13-15 seconds to copy). ...
    Message 1 of 7 , Jan 3, 2005
    • 0 Attachment
      --- In nslu2-general@yahoogroups.com, "Michael Wagner" <michael@t...>
      wrote:
      > ----- Original Message -----
      > From: "iithomas" <ppyahoo@t...>
      >
      > > I have a NSLU2 unmodified (as is) and have serious performance
      > > problems with the attached LaCie Porsche 250GB USB2 drive. I can't
      > > get more than ca 150KB/sec in reading/writing from/to the drive. (I
      > > have a 100Mb Fast Ethernet with no other problems of this kind.)
      >
      > What OS are you using as the client?

      W2K SP3 - and also tested at another pc at connected to the same hub
      running Win98SE (*same* result: a 2143KB file took 13-15 seconds to copy).

      >
      > I had this problem with W2K as a client (about 150KB/s).

      Interesting that You have the *same* slow performance rate as I have.
      BUT as I get the same result with my Win98SE pc (same hub) it's maybe
      caused by soemthing else !?
      (Also note that through the same hub other file transfers (that is:
      not to/from NSLU2) are going fast(er), e g from the mentioned Win98SE
      pc to my W2K pc etc.)

      > With WIN98 as a client (same network, same data, same source, WIN98
      machine
      > is 1/10th the speed) I get 1.8MB/s.
      >
      > I found several microsoft knowledgebase articles which refer to the fact
      > that W2K will misunderstand and set the wrong communications
      parameters in a
      > number of cases talking to what it thinks are older servers.
      >
      > The NSLU2 says it is a Windows NT 4.9 machine (there never was such a
      > release of NT AFAIK).
      >
      > So I am guessing that W2K is misunderstanding the server at the
      other end.
      >
      > My bypass for the moment was to use the WIN98 box to load the hard disk.
      >
      > The MS KB articles implied there was a "feature" of W2K you could
      turn off
      > that would "solve" the performance problem. I haven't gone there yet.
      >
      > More when I know more.
      >
      > > I can see five types of possible reasons to the problem:
      > > 1. NSLU2 is running at 10Mb speed against the network/Ethernet.
      >
      > I doubt it, since I'm getting 1.8MB/sec out of it, which is about
      18Mb/sec >
      > 10Mb/sec

      Yes, but it could e g be that NSLU2 in this case have "downnegotiated"
      (to 10Mb/sec or lower) the speed by some reason.
      >
      > > 2. NSLU2 is not using DMA mode when accessing the drive (instead PIO
      > > mode of some sort or whatever).
      > > 3. The USB "connection" is not running correctly at USB2 "mode" (?).
      > > 4. Some sort of internal "process" is interfering constantly with the
      > > data transfer to/from the drive.
      > > 5. Hardware failure.
      >
      > You missed "client is driving the server wrong". The MS KB articles
      talked
      > about a feature called, I think, optimistic locking (not to be
      confused with
      > the foxpro feature of similar name). W2K can in some conditions
      mistakenly
      > turn this on, then wait after each write for some acknowledgement or
      > handshake or something it isn't going to get from a server that doesn't
      > support the feature.

      I have searched for "optimistic locking" with Google but did only find
      that term in connection with Access (or other SQL-type) databases.

      BTW, I have implemented a couple of MS "knowledge base" tips with *no
      result*. ( http://support.microsoft.com/kb/223140 and
      http://support.microsoft.com/default.aspx?scid=kb;EN-US;q321098 and
      one I can't find a MS url for, description:

      Possible task scheduling bug:
      ... a bug that exists in both Windows XP and in Windows 2000. The bug
      causes Windows to check for any scheduled tasks that might exist on a
      remote machine before displaying the browse contents.

      This particular bug is also controlled by the registry. To solve the
      problem, just remove the following registry key:
      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
      Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}.
      )

      >
      > Michael Wagner
      > michael@h...
      > 905-761-9094
      > Director, Hamond Industries Ltd
      > - - - - - - - - -
      > Web site: www.hamond.com
      > weB LOG www.stampingoutaliving.com

      Thanks for the info !
      Thomas Berg
    • Michael Wagner
      ... Sorry, that was opportunistic locking. You re right, optimistic locking is a database term. ... That s what you can expect from MS :-) Try 296264. I
      Message 2 of 7 , Jan 3, 2005
      • 0 Attachment
        At 03/01/2005 07:47 PM, you wrote:
        >I have searched for "optimistic locking" with Google but did only find
        >that term in connection with Access (or other SQL-type) databases.

        Sorry, that was opportunistic locking. You're right, optimistic locking is
        a database term.

        >I have implemented a couple of MS "knowledge base" tips with *no result*.

        That's what you can expect from MS :-)

        Try 296264. I haven't tried it yet, so no guarantees.

        Michael

        http://home.cogeco.ca/~michaelwagner/personal-page.htm
        "All I wanna do is have a little fun before I die" Sheryl Crow
      • Rob Lockhart
        ... Actually, a good switch would be better than a crossover cable. I believe that full duplex communications require either forcing on both ends, or
        Message 3 of 7 , Jan 8, 2005
        • 0 Attachment
          On 1/3/2005 1:36 AM EST, unix fan wrote:

          >
          > You forgot about the box in the middle, your router or switch. What
          > is it?
          >
          > It's quite possible the connection to the NSLU2 has been incorrectly
          > autonegotiated with a mismatched duplex setting. Even high end Cisco
          > routers and Sun Workstations have this problem. That trashes the
          > network connection (lots of errors). I don't know how you can tell
          > what the router/switch port duplex setting is. But if you want to
          > probe at the problem, go buy a crossover cable and connect the NSLU2
          > directly to your computer's NIC )i.e., the RJ45 port. That would at
          > least get the router and the cabling to it out of the equation.
          >

          Actually, a good switch would be better than a crossover cable. I
          believe that full duplex communications require either forcing on both
          ends, or auto-negotiating with a NWAY hardware switch. One PC to
          another PC will likely not autonegotiate to 100Mbps full-duplex (may
          only be half duplex). If autonegotiations does not occur, the default
          behavior is to use forced half-duplex.

          You are right, though, that the wrong negotiations will cause all sorts
          of errors (and obviously collisions), which would cause excessive
          retransmissions and thus lower throughput.

          Most people don't have routers; they are called broadband routers but
          they are nothing more than a network switch connected to some ARM or
          equivalent processor for filtering and NAT to the WAN port.

          In regards to cabling, to ensure you're using the right kind of cable,
          you can do the following:

          Holding the cable in your hand with the tab sticking down and the the
          RJ45 connector pointing away from you as if you were going to plug it
          into a jack, pin 1 is the leftmost wire on the RJ45 connector. Check
          that the wires for pins 1 and 2 are opposite colors. I.e., if pin 1 is
          white with orange stripe, pin 2 should be orange with white stripe. Do
          the same for pins 3 and 6. If this is fine on both ends, then your
          cable is fine. I have seen some RJ45 connected cables made for digital
          phones that don't require the CAT5 / T568B (I think) wiring
          specification. It will work for 10Mbps but at 100Mbps it causes an
          excessive amount of crosstalk that can mess up a lot of ethernet
          switches and hubs. I have seen it for myself.

          Hope that helps.

          Regards,
          -Rob
        Your message has been successfully submitted and would be delivered to recipients shortly.