FTP slow xfer SCO OpenServer 5.06?
Perry Whelan
are fully licensed & registerd. They're attached to a 100Mbps switch &
have 100Mpbs NIC's. Using the stock ftp server/client to xfer files,
a ~500MB file xfer'd in ~2hr <-- I'm not exagerating! Even 5GB file
ought not take that long...
Is there some governer setting somewhere I'm not finding? Any ideas?
Thanks,
Perry
to...@aplawrence.com
: So, this is a bit odd. I've got 2 SCO OpenServer 5.06 servers, both
Usually this sort of thing is from bad (cheap) Nic cards and/or
mis-negotiation with the switch: see
http://www.pcunix.com/Bofcusm/645.html
http://www.pcunix.com/SCOFAQ/scotec4.html#duplexspeed
http://www.pcunix.com/SCOFAQ/scotec4.html#autonegotiate
and http://www.pcunix.com/Bofcusm/1235.html
--
to...@aplawrence.com Unix/Linux resources: http://aplawrence.com
Inexpensive phone/email support
Download Free Linux Skills Test: http://pcunix.com/skilltests.html
Bill Campbell
Have you tried using other methods of transferring the files such
as scp, ncftp, rsync, etc.?
What kind of NICs? There's a world of difference between them, and there's
a lot of junk out there masquerading as NICs. We stick to 3COM,
and Intel primarily.
Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
The only logical reason to take guns away from responsible people is to
give irresponsible people an edge in the perpetration of their crimes
against us. -- The Idaho Observer, Vol. 1, No. 2 February 1997
Mike Brown
Are you getting collisions on your network? Check "ndstat -l" to what
other network problems are showing up. Run "sar 1 10" during the
transfer to see if the host machine has a high CPU utilization.
I have had this problem a few times on Compaq servers with cards based
on a TI ThunderLAN chipset. I replaced them with NC3123 cards (Intel PRO/100)
which solved the problem.
Mike
--
Michael Brown
The Kingsway Group
gbur...@databasix.com
: So, this is a bit odd. I've got 2 SCO OpenServer 5.06 servers, both
Gotta agree with Bill on the NICs. Throw away those Netgear (bets?) and
get some 3Com cards.
--
gburnore at DataBasix dot Com
---------------------------------------------------------------------------
How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore | нлГКнГоГКнГГнлКнГоГКнГнГоГКнГннлГ
| нлГКнГоГКнГГнлКнГоГКнГнГоГКнГннлГ
Official .sig, Accept no substitutes. | нлГКнГоГКнГГнлКнГоГКнГнГоГКнГннлГ
| нл 0 1 7 2 3 / нГо 3 7 4 9 3 0 лГ
Black Helicopter Repair Services, Ltd.| Official Proof of Purchase
===========================================================================
Bill Vermillion
<gbur...@databasix.com> wrote:
>Perry Whelan <me...@wi.rr.com> wrote:
>: So, this is a bit odd. I've got 2 SCO OpenServer 5.06 servers, both
>: are fully licensed & registerd. They're attached to a 100Mbps switch &
>: have 100Mpbs NIC's. Using the stock ftp server/client to xfer files,
>: a ~500MB file xfer'd in ~2hr <-- I'm not exagerating! Even 5GB file
>: ought not take that long...
>: Is there some governer setting somewhere I'm not finding? Any ideas?
>Gotta agree with Bill on the NICs. Throw away those Netgear
>(bets?) and get some 3Com cards.
The really bad NICs are the RealTek. And >some< Netgear NICs were
wonderful - those that used the original DEC chips - the ones that
iNTEL bought. I think some of the current Netgears are using
the LiteOn chipset which is a DEC tulip clone.
--
Bill Vermillion - bv @ wjv . com
Bill Campbell
>In article <bartp3$it2$5...@blackhelicopter.databasix.com>,
> <gbur...@databasix.com> wrote:
>>Gotta agree with Bill on the NICs. Throw away those Netgear
>>(bets?) and get some 3Com cards.
>
>The really bad NICs are the RealTek. And >some< Netgear NICs were
>wonderful - those that used the original DEC chips - the ones that
>iNTEL bought. I think some of the current Netgears are using
>the LiteOn chipset which is a DEC tulip clone.
I've had problems with many of the non-DEC Tulips. We often use
recycled 3c905B 10/100 cards that are available locally for about
$20US each. They carry a lifetime warranty from 3COM, and on the
few occassions we've had a defective card, it's been replaced
without any questions.
Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
You need only reflect that one of the best ways to get yourself a
reputation as a dangerous citizen these days is to go about repeating
the very phrases which our founding fathers used in the struggle for
independence.
-- Charles A. Beard
Jeff Liebermann
>So, this is a bit odd. I've got 2 SCO OpenServer 5.06 servers, both
>are fully licensed & registerd. They're attached to a 100Mbps switch &
>have 100Mpbs NIC's. Using the stock ftp server/client to xfer files,
>a ~500MB file xfer'd in ~2hr <-- I'm not exagerating! Even 5GB file
>ought not take that long...
Did ftp performacne work correctly BEFORE you upgraded to 3.2v5.0.6?
The first step to solving any problem is to assign the blame. Plug a
known working 3rd computah into the switch and try file transfers
to/from both of the two OSR5 machines. Perhaps *ONE* of the OSR5
servers is screwing up, not both.
If your unspecified NIC's are 3Scum 3C905 cards, some of the early
versions before Rev C had the nasty habit of not successfully NWAY
negotiating the speed with some switches. The fix is to tweak the
space.c file for the 3C905 to NOT auto-negotiate and to use a suitable
speed and protocol. I suggest 100baseTX half-duplex. If that works,
try full-duplex. Be sure to unplug the cable from the switch when
changeing speeds and full/half duplex to reset the port.
Are you sure that the packets are actually going directly between the
two machines? Run:
traceroute other_machine_ip
and
netstat -rn
to be sure. I got fooled a while back when RIP setup a bizarre route
out to a remote router. It actually worked, but was dismally slow.
If you're not using RIP, kill the routed daemon and comment it out of
/etc/tcp to prevent it from restarting. Oh yeah, try:
ping other_machine_ip
If it's slower than a snail, something odd it going on in between
machines. I have a Netgear FS-508 the periodically goes insane where
the only symptoms are extremely long delays through the switch.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
je...@comix.santa-cruz.ca.us je...@cruzio.com
Jeff Liebermann
>http://www.pcunix.com/SCOFAQ/scotec4.html#autonegotiate
Oh-oh. That's slightly misleading. There are more modes and
combinations. See:
http://scyld.com/expert/NWay.html
for the complete explanation of NWAY. The order and sequence is:
1. 100BASE-TX Full Duplex
2. 100BASE-T4 Half Duplex
3. 100BASE-TX Half Duplex
4. 10BASE-T Full Duplex
5. 10BASE-T Half Duplex
Negotiation starts at the top and settles to the bottom. If the NIC
cannot negotiate, you get 10base-T half duplex by default.
Note the 100base-T4 which is where most of the NIC/switch negotiations
get stuck. There's also a potential screwup as some cards (i.e.
3C905A) will only successfully perform an NWAY negotiation on power
up. Rebooting doesn't seem to convince it to try again. Worse, it
may actually be successfully re-negotiating, but forgetting to inform
the OSR5 driver of the change. Dunno. I've never bothered to
investigate.
Perry Whelan
SCO OpenServer 5.06.
Both have Intel 10/100 NICS
I tried setting both to half-duplex 100Mbps, rebooting -- still no
change.
Oh, and it's a Netgear 10/100 16port switch, and these are the only 2
machines connected to it!
Any further ideas on things to check into?
Jeff Liebermann
>They are not upgraded machines, they are fresh Enterprise installs of
>SCO OpenServer 5.06.
With updates? Run:
customquery listpatches | head -1
>Both have Intel 10/100 NICS
Both have model numbers of Intel NIC's. I'll assume they're supported
and that you've checked for updated drivers. Intel Pro100 series
cards do NWAY correctly, so I don't think that's the problem.
>I tried setting both to half-duplex 100Mbps, rebooting -- still no
>change.
>
>Oh, and it's a Netgear 10/100 16port switch, and these are the only 2
>machines connected to it!
Well, we're assuming that the unspecified Netgear switch is OK.
However, with only two devices installed, it smells like a new
installation. Can you temporarily replace the switch with a hub or
another switch to eliminate the switch as the problem? Also, check
the ethernet cables and connections. Mashed RJ45 connectors are
common.
>Any further ideas on things to check into?
Sure. What kind of ping times are you getting between machines? That
should show some kind of problem. See:
http://www.cruzio.com/~jeffl/sco/diag2.txt
for a really old doc on network diagnostics. See if netstat shows a
large percentage of collisions or errors.
Perry Whelan
> out to a remote router. It actually worked, but was dismally slow.
> If you're not using RIP, kill the routed daemon and comment it out of
> /etc/tcp to prevent it from restarting. Oh yeah, try:
> ping other_machine_ip
> If it's slower than a snail, something odd it going on in between
> machines. I have a Netgear FS-508 the periodically goes insane where
> the only symptoms are extremely long delays through the switch.
Jeff, interisting; I'd not noticed your post on this. I *was using a
Netgear FS series switch, when the 2 boxes were placed on a different
switch the problem completely dissapears...
Is it somehow possible that the Intel series cards have issues w/ the
Netgear FS series switches? I've tried auto, full/half | 10/100 as
well as different drivers.?.
Cheers,
Perry
Jeff Liebermann
>> I got fooled a while back when RIP setup a bizarre route
>> out to a remote router. It actually worked, but was dismally slow.
>> If you're not using RIP, kill the routed daemon and comment it out of
>> /etc/tcp to prevent it from restarting. Oh yeah, try:
>> ping other_machine_ip
>> If it's slower than a snail, something odd it going on in between
>> machines. I have a Netgear FS-508 the periodically goes insane where
>> the only symptoms are extremely long delays through the switch.
>
>Jeff, interisting; I'd not noticed your post on this. I *was using a
>Netgear FS series switch, when the 2 boxes were placed on a different
>switch the problem completely dissapears...
Yep. I haven't seen this on the FS-508 (I have several of these in
service). However, the FS-108 is a problem for me. I've had
failures, oddities, and mysterious hangs with three of these dogs.
However, I do like the metal box, the cool blue colour, and the nifty
flashing lights.
>Is it somehow possible that the Intel series cards have issues w/ the
>Netgear FS series switches? I've tried auto, full/half | 10/100 as
>well as different drivers.?.
Dunno. It could be both the switch and the card. A good test would
be to power cycle the switch and see if it recovers. If that fixes
it, it's the switch with the problem. However, if just power cycling
the computahs fixes the problem, leaving the switch alone, then
there's something goofy in the computah. I've never had the problem
with Intel Pro10 and Pro100 cards on various switches. However, 3Scum
3C905, 3C905A, and 3C905B cards drive me nuts (the 3C905C works fine).
I can reboot the computah and the stupid card will not NWAY negotiate
with an FS-108. However, if I power cycle the computah, it negotiates
just fine. My fix has been to find another switch (Linksys EF4116)
that works. Locking the speed of the 3C905 also helps. I do both
when possible.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# je...@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager je...@cruzio.com AE6KS
Bill Vermillion
Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>On Sun, 25 May 2003 20:08:38 +0000 (UTC), to...@aplawrence.com wrote:
>
>>http://www.pcunix.com/SCOFAQ/scotec4.html#autonegotiate
>
>Oh-oh. That's slightly misleading. There are more modes and
>combinations. See:
> http://scyld.com/expert/NWay.html
>for the complete explanation of NWAY. The order and sequence is:
> 1. 100BASE-TX Full Duplex
> 2. 100BASE-T4 Half Duplex
> 3. 100BASE-TX Half Duplex
> 4. 10BASE-T Full Duplex
> 5. 10BASE-T Half Duplex
>Negotiation starts at the top and settles to the bottom. If the NIC
>cannot negotiate, you get 10base-T half duplex by default.
>Note the 100base-T4 which is where most of the NIC/switch negotiations
>get stuck. There's also a potential screwup as some cards (i.e.
>3C905A) will only successfully perform an NWAY negotiation on power
>up. Rebooting doesn't seem to convince it to try again. Worse, it
>may actually be successfully re-negotiating, but forgetting to inform
>the OSR5 driver of the change. Dunno. I've never bothered to
>investigate.
For a fairly in-depth discussion of this [refers to Cisco Catalyst
troubleshooting but applicable to the whole process] see
the following link.
http://www.cisco.com/warp/public/473/46.html
It expalins pretty well why/how auto-negotiation fails, and why it
gives the slow performance seen when it does.
Bill
Bill Vermillion
Perry Whelan <me...@wi.rr.com> wrote:
>They are not upgraded machines, they are fresh Enterprise installs of
>SCO OpenServer 5.06.
>
>Both have Intel 10/100 NICS
>I tried setting both to half-duplex 100Mbps, rebooting -- still no
>change.
>Oh, and it's a Netgear 10/100 16port switch, and these are the only 2
>machines connected to it!
Did you power cycle the switch at the same time you rebooted these
machines?