https://bugzilla.novell.com/show_bug.cgi?id=254783 alpha096@tpg.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Comment #5 from alpha096@tpg.com.au 2007-03-18 21:56 MST ------- Without prejudice nor emotive expression:- 1. This timeout appears to be an absolute time set parameter. This error has plagued open suse linux releases since 10.1 - and never addressed. The question posed initially was not even attempted to be clarified. It is absolute technical and flippant reply to state #4. A great deal of the comms protocol is devoted to redundancy/retry code. A timeout error - despite the mirror being used; without comms issuing a NOACK or complete failure in reply to a request without comms firstly issuing a NOACK, lost packet, subsequent retry and at the very last issuing a 'destination unreachable' response being ignored and in place reporting 'obscure 'time out value' lacks the following. Total disregard and poor understanding of comms redundancy is more than apparent to reply as in 4# above. It displays lack of understanding of the current and potential traffic load both currently and into the future. Without this issue finally being put to resolution, now and in past, time out errors in previous and current versions, in my opinion, is made without any commitment nor understanding of the comms protocol. The reporter would NOT be re-raising this issue again unless this particular functionality was of little importance. Without correction soon, and given an extrapolated measure of how busy the internet will grown in the future is one of lack of concern, lack of the enormity of comms redundancy code and lacks any real concern for Quality Assurance as timeout errors were of major concern and reported in version 10.1 where the issue became less previlent. Online update, in theory should only ever issue a - time out- error in response to the designated sever providing a comms ' destination unreachable'. The current speed WAN connection speed when this error was received is ADSL 2 at a measured site speed download speed of 5500KPBS and 1000KPBS upload speed. Various comms statistics report NO CRC error and IDS displays NOT dropped packets due corruption. A search on the reporter will revile past discussions encounter in previous releases on this exact issue. Whilst inexperience by other users NOT familiar with the enormity of redundancy code built into the protocol may not cause any form of alarm at this erroneous - time out error response. IF we cannot rely in FTP as a secure and faultless for of file transportation the the reporter has no choice to close this bug WONTFIX as this is the overall and under-riding reason for reply #4. A NO Confidence issue is in the mind of the reporter and this issue closed for ever from my point of view. Please do NOT re-open this bug and expect vast amount of time and experience in development to be forth coming in this particular bug error. -- 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, or are watching someone who is.