I was aware of tcpdump, but not netwatch. Thanks for the pointer.
BTW, count me in the list of converts to "apt-cache search" "apt-get
install" from RPM-world, which I used to think was great. Debian is not
perfect, but downloading/installing packages for it nearly is! An elapsed
time of about 2 minutes from hearing about a utility for the first time to
having it installed is pretty amazing.
Doesn't seem to work so well on s390 without eth0 though. (To bring me
slightly back on topic)
Scott Chapman
Gregg C Levine
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
et.att.net> cc:
Sent by: Linux on 390 Subject: Re: MTU size
Port
<[EMAIL PROTECTED]
EDU>
03/20/03 03:00 PM
Please respond to
Linux on 390 Port
Hello again from Gregg C Levine
I have netwatch running here. That works for me. Tcpdump does work. It
does a good job showing the packets flowing into my machine from
either a VNC console, or even a SSH terminal.
-------------------
Gregg C Levine [EMAIL PROTECTED]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."� Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> -----Original Message-----
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf
Of
> Post, Mark K
> Sent: Thursday, March 20, 2003 2:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [LINUX-390] MTU size
>
> Scott,
>
> I would probably use Ethereal. tcpdump is another option.
>
>
> Mark Post
>
> -----Original Message-----
> From: Scott Chapman [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2003 6:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: MTU size
>
>
> How does one monitor/measure the average packet size across a
network?
>
> Scott Chapman
>
>
>
>
> Vic Cross
> <[EMAIL PROTECTED] To:
> [EMAIL PROTECTED]
> au> cc:
> Sent by: Linux on Subject: Re: MTU
size
> 390 Port
> <[EMAIL PROTECTED]
> IST.EDU>
>
>
> 03/19/03 05:59 PM
> Please respond to
> Linux on 390 Port
>
>
>
>
>
>
> On 20.03.2003 at 08:04:08, "Post, Mark K" <[EMAIL PROTECTED]> wrote:
>
> > Yes, no, yes.
>
> I think it needs a little more than that. ;-)
>
> It's part of a router's job to fragment packets if necessary. If VM
TCP/IP
> really has to work *that* hard to fragment packets, then it would be
> another
> argument for virtual Linux routers.
>
> By changing the MTU for a link that can handle a large MTU, you are
> artificially
> constraining that link to a lower level of performance. If we
carried this
> thought to its logical conclusion, we would never use an MTU greater
than
> 576
> because we could never be certain that some link somewhere did not
use the
> minimum MTU.
>
> Sure, it can be an issue if packets go through the network with the
"Do Not
> Fragment" flag set. These won't make it through a link/device whose
MTU
> size is
> smaller than the size of the packet. ISTR this is the basis of Path
MTU
> Discovery, a process that works out the optimum MTU size for each
session,
> but
> I'm not sure how widely or consistently it is implemented.
>
> It's a matter of looking at your traffic patterns. If your main
traffic
> flow
> from your guests is out to the LAN, then the system overall might
benefit
> from
> changing the MTU (though now your Linux guest will be making more
packets,
> so
> the CTC driver will have more work to do, potentially eating up the
reduced
> VM
> TCP/IP load). If the guests spend a lot of time talking amongst
each
> other,
> then reducing the MTU will cause more work for the guests through
> unnecessary
> fragmentation.
>
> It's all for nought, though, if your average packet size is less
than 1492
> bytes
> anyway (very often the case).
>
> Cheers,
> Vic Cross
