https://bugzilla.novell.com/show_bug.cgi?id=413093
User alpha096@virginbroadband.com.au added comment
https://bugzilla.novell.com/show_bug.cgi?id=413093#c4
Scott Couston changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Info Provider|alpha096@virginbroadband.com.au |
--- Comment #4 from Scott Couston 2008-08-06 08:52:56 MDT ---
I will try to answer all your question I understand.
1 The one constant is that I can download and install any community repository,
either the exception of openoffice as above with ever having even a retry.
I would also like to preface the below information as hopefully a constructive
relationship, I would never presume to be able to manage a huge amount of
Client PC or offer substantial ISP functionality. Some of my idea may have
merit. - I hope so
The requested file repository location originates from the server withing each
screen capture and is defained as.
http:///download.opensuse.orgrepository/repositories/OpenOffice.org:/STABLE/...
I am there for not using a mirror unless your download server mounts the
directory
/repositories/OpenOffice.org:/STABLE/openSUSE_10.3/
on another low perforation/bandwidth server AND/OR the original files are
corrupt in some way that a Verepair may indicate if run on that volume
containing the directory
/repositories/OpenOffice.org:/STABLE/openSUSE_10.3/
My other thoughts are that if the
/repositories/OpenOffice.org:/STABLE/openSUSE_10.3/
files reside on a server with totally insufficient cache room and is running on
border Manager without sufficient cache available size.
One other fial though you may like to consider is to DECREASE the retry value.
Often when comms are over significant distandance and the packet retry interval
to to short. This creates a problem where the ack does not arrive back at the
server in the set time, due to distance, and there-try could is increased to
solve this issue.
By doing this you create a larger problem as for example
1st pack sent and noack in defined time set so retry 1 is sent.
Meanwhile the ach arrives from the first packet and the client is only
satisfiedof an intact packet, however by this time the server sebds another
retry and the game start all over again at an exponential level.
With distace comms is is better to set a longer time frame for ack, and to
re-set the re-try back to defaul or even increase its value.
You can understand how a huge amount of bandwidth is chewed up by (SPX)
equivalent protocol control as its fill of re-tries and untimely configured
acks for the comms distance traffic can left without user intervention the
total bandwidth consumed by all file redundancy messages in the force a huge
delays. If No acks/or late acks arrive it is too late and all redundancy
checkes and measures are activated. Ever increasing re-tries that follows an
exponesial rise in the (SPX) part of TCP/IP .By both decreasing the time before
packet re-try is sent, and then possibly lower the retry factor time abd amount
we often solve log distance comms lines. The established time difference
betweeen London and Australia is almost 4 second in delay and that sole reason
iw why noust non IP traffic is sent by SNA/T or Transparent SNA you can lokup a
little later if you are interested.
Yes I am located in the 3rd largest city of Australia, where all comms are
digital and all cells have been on a 3G network for over 12 months county wide.
ALL other updates that commence with the http://download.*........never fail or
even ask for a re-try and nothing has changed in any LAN settings for many
weeks. If it s not broke dont fit it ;-)
If the trouble some is on a seperate volume, could you run a vrepair just out
of interest and check the amount of disk space allocated to Boarder Manager.
and check all the set options to to with RX/TX are set the same if multiple
netware servers are used.
If all above is true take a look at the set parameter before ack is received
and what time is placed on this parameter and then check the packet re-try is
not anything but default.
If again the directory does reside on a different server, check that sever has
sufficient cache memory and check the hot fix logs to see if the HDD is not
slowly falling apart,but above all check the HDD in all download servers are
ALL the SAME SCSI high performance devices and you are using the same SCSI
controller cards.
Other default set values may need adjustment purely as be are aprox 4 seconds
in delay of data traffic which make totally encapsulated comms like x25
difficult to manage. We use most all external comms as SNA/T via our satellite
- remember we are along way away and just a big island.
Kind Regards Scott
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
