[rhn-users] RedHat updates can be downloaded through a Windows Multilink connection?
Roy A. Crabtree
roy.crabtree at ncat.edu
Mon Sep 5 18:05:31 UTC 2005
John Wirt wrote:
>I have been trying for months to update my installation of RedHat Enterprise WS version 3 Update 2 AMD64/Intel64 EM64T to the latest versions for all packages. The problem is that downloads of multimegabyte packages stall.
>
>The difficulty is apparently has something to do with my network connection.
>
>My Linux machine (a Dell 670 Precision workstation with a Xeon processor) has access to the Internet through my LAN, which is a peer network (Microsoft Windows NETBEUI). The gateway to the Internet is thorough two Zoom modems, one v.92 and one v.90, that are multilined using Windows 2000 Dialup Networking. The configuration of the network is that the machine with the dialup connection to the Internet, which has Windows 2000 SP4, is connected to a 3Com Office Connect hub, which is connected to the Linux machine. Connection sharing from the LAN to the dialup connection is provided by NAT32, which as the name indicates is network address translation software (www.nat32.com). The resulting download capacity is about 100kb (2 56K connections).
>
>The arrangement works fine from Windows. I also connect to the Internet from my laptop, which is also connected to the network. I can upload and download email, files, and web traffic from my laptop all day long with no problems.
>
>The RedHat Up2Date program connects fine and I can select the packages to download but after about 10 minutes in downloading a multi-mebabyte file, the connection begins to stall and run very slowly until a point where it has almost stopped. The downloads stop completely if I attempt any Internet operation (download email, browse to a website) from the gateway machine or the laptop.
>
>If I then shutdown the dialup connection and start over, I can reconnect to the RedHat Network and initiate package updating again. But I can only do about 5 packages at a time, not including any large packages (over 10 mb) without having the downloads stall.
>
>So the problem appears to be the Multilinking. I notice that when I disconnect the multilinked dialup connection, one of the modem does not shut down normally. It takes awhile to close. This is why, I think the problem may have somethin to do with multilinking.
>
>QUESTION: I there any reason to think that Linux has some problem connecting to the Internet though a multilinked connection under Windows 2000? Is there anything I can do in Linux to avoid the problem I have?
>
>
Yes: an old, old, old problem called the "spiraling death" syndrome
first _noticed_ with v32bis/ter modems that
had as its symptom a slowdown that would never recover with modem errors
or intermittent packet hangs;
similar to a spiraling death flow control problem on older still FTP
links and still present at last to the
extent that under many FTP servers, a degrade in the upper bound packet
speed does not recover).
the problem resides in many different places and differing protocol
implementations, where in a particular
layer the protocol recovery for speed degradation does NOT take place,
nor does upward-speed pacing accrue.
A) Modem itself: noisy TN line or bad protocol firmware mismatch on
either side, coupled with a lack of external recovery.
SOlution: switch the telephone outlets, or disconnect to one modem
temporarily to isolate to see if
ONE modem slows down and does NOt recover by itself. Change the MNP
parameters systematically
to see if a mismatch at the MNP level causes a spiraling death; the
predominant theme is match
the EXACT parameter set on BOTH sides of EACH link (which is why
flipping the modems and trialling
each singularly is the first step for __THIS__ type of spiraling
death).
The main ones are going to be (a) flow control at the HW level on
both sides with proper FIFO on
the serial links involved (if that is what they are); make sure
MAXIMUM buffer and high water marks are enabled;
(b) priority of the processes driving the modems as high as
possible, especially the kernel thread(s) involved,
including using RT on Linux or Real priority on Windows; (c) MNP
ATAn parameter matched: start with 64 bytes
or smaller, and gradually increase to 256 bytes or larger (small
for noisy telephone lines or hiccups).
When _BOTH_ modems by themselves stay at maximum pacing (which will
get you a half speed link at least during
the testing), for at least 4 times what you previously achieved with
two spiraling to death, or faster if you wish to
push the limits (the problem may not go away and you may not find
where it is initially), then step 2:
B) Look to the networking links and protocol stacks in between here and
there: IP, MTU, packet sliding window sizes,
revision (IP4 versus IP6), routers, and so forth. Make sure that
the MTU is _small_ enough not to go through
fragmenting (MTU smaller than MNP ATAn size to start, and _matched_
to gain maximum speed),
the window sizes are _small_ enough no to have lost packets (start
with 1 packet in flight and move up),
then assure yourself that dynamics are tuned off (speed pacing,
black hole discovery, the like); start on the
slow and banal side, and then add the flexibility as you go up in
speed. Then step 3:
C) Check the server for variability in maximum speed rate stability
(does it start and stay at one maximum speed
fr each successive link, or does the maximum speed hit a
_different_ level and stabilize there from download
to download, link to link, or channel to channel, or whatever);
check for speed recovery when a temporary
halt occurs (does that particular instance downshift and NEVER go
back up?); track on a systematic basis
to pin down where the problem first occurs, deterministically
repeats, and what cures it or avoids it.
This is more likely to occur on older FTP servers, high volume
channels at high volume/speed. high speed
servers that are dynamically flexible, but tuned with the wrong
timeout/blocksize/windowcount/recovery
parameters for slower links.
Basically:
high priority to lower priority,
your side to their side, near to far, static to dynamic,
HW to FW to protocol to OS driver to transfer server,
completely matched on all parts to
completely matched on close-in parts to
flexibly configured on each end of the same link part,
low/slow/go-at-all to high/fast/pick-up-the-pace
Do you feel the overall flow of the "problem solution" paradigm I am
painting?
Basic wolf fencing.
Then, if all this fails to establish a stable high enough plateau:
D) Try the weird stuff in right field that is COUNTER intuitive (gee,
you would NEVER set it up that ay).
You may find a combination that just happens to work where the
experts think it will not.
E) Look at the setup on your system BIOS for DMA, IRQ and tunings of
the like.
Turn off hyperthreading if it is on, and the reverse. And so on.
F) Update to the latest firmwae or pumpware or driver revs as a last
resort, and ONLY if
you can reload the old ones AND you are willing to risk more
problems on your other
comm usages (sometimes the promise of reloading an old driver or
firmware rev, or changing
an IRQ/DMA/port setting via PnP are problematic; as well as getting
too many configurations
in the Windows registry, for example). And so forth.
G) Consider getting a multilink solution that uses ethernet to a linkbox
out over multiple modem links.
That way you do not have a Windows protocol stack involved. (Sorry,
'tis true it's true this oft'is a problem);
multilink problems often go away when you buy a box whose only
promise is to deliver this.
H) Update to the latest versions of Windows patches and software, and
look at their KB for transmission
hang problems. There probably will be a specific download to fix it
that somehow does not get
included into the Windows next release load ... a very, very old
problem of one vendor bombing another.
Many "speed up" promises made
Sorry this is not necessarily as simple as you might like; but this is
the nature of comm problems.
I had many years of people telling me that UUCP could not fly at 9600
baud on the old 9600 baud modems
with MNP4 ... bunk. I also have people tell me a 100Mbit ethernet card
cannot deliver 12.25 MB/sec to a processor
under 200 MHz. Also bunk.
Bu: systems are seldom tuned or configured properly.
>Note that my network configuration has nothing to do with establishing a multilinked connection using Linux. The multilinked connection is made by Windows 2000. Linux is simply networked to the Windows 2000 machine.
>
>OPTION: My best alternatives are to:
> 1) establish a WiFi connection to the Internet for my network, which I can ddo.
> 2) get a broadband connection to the Internet (either DSL or cable), which I can also do but would rather not because I do not want to give my current ISP, who gives me mailing services that I doubt I can get from any broadband company.
>
>For the time being, I perfer getting Linux to run in my current network configuration. In order to do this, I need to donwlaod and install about 360 packages! It has been slow going. It has taken me a long time to figure out what the problem appears to be.
>
>THE BASIC PROBLEM? Reading some of the messages in this list, it appears that I may be "out of my element" in using a RedHat Enterprise version of Linux. It came on the machine I bought from Dell so I really had no choice. After taking a year to basically get nowhere on updating the operating system on my computer, I will have to pay $175.00 for another year's subscription starting in October?
>
>John Wirt
>
>
>
>
>_______________________________________________
>rhn-users mailing list
>rhn-users at redhat.com
>https://www.redhat.com/mailman/listinfo/rhn-users
>
>
--
--
Roy A. Crabtree
UNC '76 gaa.lifer#11086
NC A&T Fort Room 071
1601 East Market Street
Greensboro, NC 27411
336-334-7856/7/8/9 x2249
roy.crabtree <mailto:roy.crabtree at ncat.edu>@(ncat.edu
<mailto:roy.crabtree at ncat.edu>, alumni.unc.edu
<mailto:roy.crabtree at alumni.unc.edu>, gmail.com
<mailto:roy.crabtree at gmail.com>)
--
(c) RAC/IP, ARE,PRO,PAST
(Copyright) Roy Andrew Crabtree/In Perpetuity
All Rights/Reserved Explicitly
Public Reuse Only
Profits Always Safe Traded
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhn-users/attachments/20050905/92135aa5/attachment.htm>
More information about the rhn-users
mailing list