nic card jerky can't ftp write network slow

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Sat Sep 22 06:20:56 2001
Newsgroups: comp.unix.sco.misc
Path: typhoon.ne.mediaone.net!chnws06.ne.mediaone.net!24.147.2.43!chnws02.mediaone.net!newsfeed2.skycache.com!newsfeed1.cidera.com!Cidera!sjcppf01.usenetserver.com!usenetserver.com!cyclone.bc.net!nntp.cs.ubc.ca!enigma.xenitec.on.ca!news.xenitec.on.ca!news
From: Bela Lubkin <belal@caldera.com>
Subject: Re: TCP-IP problems on OS505
Resent-From: mmdf@xenitec.on.ca
Submit-To: scomsc@xenitec.on.ca
Content-Type: text/plain; charset=us-ascii
Cc: Karel Adams <k_adams@glo.be>
Organization: [resent by] The SCOMSC gateway and Propagation Society
Content-Disposition: inline
Date: Sat, 22 Sep 2001 08:59:37 GMT
Message-ID: <20010922015936.F5148@mammoth.ca.caldera.com> 
User-Agent: Mutt/1.2.5i
To: scomsc@xenitec.on.ca
Mime-Version: 1.0
In-Reply-To: <bmWq7.5987$35.610950@iguano.antw.online.be>; from k_adams@glo.be on Sat, Sep 22, 2001 at 06:39:00AM -0000
References: <bmWq7.5987$35.610950@iguano.antw.online.be> 
Sender: belal@caldera.com
Precedence: list
Lines: 68
Xref: chnws06.ne.mediaone.net comp.unix.sco.misc:103673

Karel Adams wrote:

> I am re-installing OS505.
> Basis install was no problem, also I applied RS505A
> Next I setup tcp-ip config, no problem,
> I can ping across the network in all directions.
> Next I downloaded patches to some other machine
> in the network and wanted to ftp them, trouble starts here.
> I can open an ftp session, and in it I can mkdir,
> cd and whatever. But when I try to 'put' a file, the
> directory entry is created but nothing gets written,
> and after a while the ftp client will time out.
> I then setup up trust relations and tried to rcp the files:
> exactly the same story. Everything is possible, except
> to write a file (reading one is without problem!)
> All these are identical with the client on os504,linux,
> or win98. It is a local 192.168.0 network with no
> additional routing.
> One thing I have observed: my telnet sessions are
> 'jerky', i.e. characters typed at the console sometimes
> take a few seconds before appearing.
> 
> Any clues? Re-install TCP-IP?

These are all symptoms of your NIC driver failing to see incoming
packets in a timely manner.  It is missing interrupts.  `netstat -i` may
be informative (better `netstat -in` to avoid name lookups, which may
not work well under these circumstances).  Next, look at `ndstat -l` for
more details.

Here are some likely causes:

- The NIC driver and NIC disagree about the cable (media) type; e.g. one
thinks it's 10Mbit while the other thinks it's 100Mbit; or one is trying
to operate half-duplex and the other full.  Go into `netconfig`, look
for cable settings under the "Advanced" setup for the NIC.  If anything
is set to "auto", change it to explicitly the right cable type you're
actually attached to.  "auto" is a technical term meaning "take a wild
guess and go completely haywire if you're wrong".  (Of course it is not
really a "cable" type but the agreed-upon protocol being spoken by
everyone else on that cable -- probably a router or hub.)

- The NIC and its driver disagree about what IRQ is being used to
service interrupts.  Compare BIOS setup information, `hwconfig -h`, `hw
-vr pci`, etc.  Or the NIC is sharing an IRQ with some other driver, and
something is going wrong.  IRQs are supposed to be sharable, but it's
complex and many drivers do the wrong thing in ways which make them bad
neighbors, unable to share IRQs properly.  Use BIOS setup, physical
movement of cards from one slot to another, etc., to browbeat the system
into not trying to share interrupts between those particular boards.

- You have a NIC which is similar enough to one of the ones supported by
the base 5.0.5 / rs505a operating system to be recognized, and
more-or-less operated, but not in a useful manner.  You say you're
"reinstalling" so presumably it used to work.  Maybe you previously had
a driver update which makes the same driver aware of the quirks of your
particular hardware model.

I vote for the first possibility -- cable type mismatch.  You can
further probe for this by pinging the machine and observing `netstat -i`
stats.  I predict you'll see incoming packets just fine.  Then ping the
machine with large packets, just below the size of a full ethernet
frame: `ping -s 1400 badmachine`.  Now I suspect you will not see
incoming packets.  I don't understand why NICs are able to receive at
all when they're listening at the wrong speed, but they are; it just
doesn't work well.

>Bela<
 

Take Control of Maintaining Your Mac

Take Control of Syncing Data in Leopard

Take Control of Upgrading to Snow Leopard

Take Control of Buying a Mac

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.