Re: Checklist (sub-thread of: "Slow file sharing performance: lost pidgeons")

Hans Steegers wrote:
> Hi Alan,
> 
> 
>>Maybe we could to put together a check list of information we want before
> 
> we
> 
>>feel it's worth looking at a problem? We coud then post this as a standard
>>reply when insufficient information is not given on the first request.
> 
> 
> Maybe it is a solution: some don't even bother to read any documentation.
> They have a problem and need a solution instantly. Sometimes unhindered by
> any knowledge and full of misconceptions about networking. All they know is
> that CIPE doesn't work the way they expected it should work, and blame the
> software for it. Sometimes caused by the fatal combination of arrogance,
> ignorance and incompetence. Requiring the provision of sufficient
> information before looking into the problem may prevent wasting unnecessary
> time and energy.

I have searched the documentation I could find and elsewhere, yet I 
haven't seen this particular problem.

My initial testing was via dial up, as that was all I had available. 
This past weekend, I bought a wireless router/firewall and placed it 
between my Linux firewall and cable modem.  This allows me two 
additional methods of connecting to my Linux firewall.  One via the 4 
port switched hub at 100 Mb and also via wireless at 11 Mb.  Note that 
with these 3 methods, the connection to the Linux firewall is always 
through eth0.  The only difference is the connection bandwidth.  When I 
connect via either the switch or wireless, everything works fine.  When 
I used dial up, the problems return.  This only appears to apply to 
protocols that use UDP.  FTP, which uses TCP, doesn't experience that 
problem.  My conclusion is that the problem is with Samba & NFS and not 
CIPE.  I would expect this is due to the lack of UDP flow control, 
except as may be provided by a particular service.  My experience, where 
file sharing from the notebook backs this up, as data from the notebook 
would be initially limited by the dialup connection and there would be 
no concern about over-running some slower device further on.

I worked with Allan, because he seemed to have the most to offer for 
this problem.  I didn't mean to exclude anyone else.



> 
> We could expect the following in cases such as James's in order to be able
> to diagnose the cause of such problems:
> 
> * Summary of the setup: what is connected to what and over what
> medium/network, so we get a picture what is to be achieved..
> * Summary, followed by a detailed description of the problem: just stating
> "it doesn't work" isn't very helpful.
> 
> Note: The summaries are to allow others to see whether they can help without
> needing to read the detailed description and attachements.
> 
> And provided as attachements, if applicable:
> * Output of ifconfig of involved cipxx, ethx/pppx devices
> * Output of route -n (route print)
> * Output of ipchains or iptables ruleset (list command)
> * Options files and up/down scripts of all involved cipe interfaces
> * pktdump output if applicable or on request.
> 
> NOTE: Public ip-addresses can be replaced by a.a.a.a, b.b.b.b, etc for
> privacy reasons, etc.
> 
> Another requirement could be: Mandatory posting of the final solution to his
> problem by the poster, even it was caused by a silly overlooked mistake. Too
> often threads in this mailing list are ending nowhere, which is a waste and
> makes it frustrating to search for solutions in the mailing list archives.
> 
> Maybe you, or somebody else, has additional suggestions?
> 
> Hans Steegers
> 
> -----Original Message-----
> From: Allan Latham <[email protected]>
> To: [email protected] <[email protected]>
> Date: Monday, September 08, 2003 10:40 AM
> Subject: Re: Slow file sharing performance: pidgeons lost!
> 
> 
> 
>>Hi Hans
>>
>>that's partly my fault. As I expected large tcpdump output files I ask for
>>them directly rather than having them mailed to the enitre list.
>>
>>In fact they are small. James could safely send them to all of us for more
>>thoughts on the problem. I can't forward them myself out of privacy
>>considerations.
>>
>>Maybe we could to put together a check list of information we want before
> 
> we
> 
>>feel it's worth looking at a problem? We coud then post this as a standard
>>reply when insufficient information is not given on the first request.
>>
>>Best regards
>>
>>Allan
>>
> 
> 
> 
> 
> --
> Message sent by the [email protected] mailing list.
> Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>



--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>