|
Posted by Robert Redelmeier on October 11, 2006, 1:38 pm
If you were Registered and logged in, you could reply and use other advanced thread options
>
>> I use `ttcp` to test network speed. It avoids the disk and
>> occasionally software bottlenecks. It measures OS & hardware. By
>> running it as UDP, I can get an idea if TCP is mistuned. But you
>> need access from both ends. When you can't (usually across the
>> Internet), then hit some reliable site and see what kind of ftp
>> throughput you get.
>
> ttcp would be ok if the file transfer mechanism is FTP.
> If it is SMB, (or NFS) then a request/response test would
> be a better match - say a netperf TCP_RR test with suitable
> request/response sizes to match what SMB is doing.
Agreed. Even the venerable ping can be very useful.
> Be very cautious about UDP bulk transfer benchmarks (ttcp,
> netperf UDP_STREAM). They often have no end-to-end flow
> control and as such may completely saturate a bottleneck
> link, much to the chagrin of other users.
Isn't that the idea :) but a wise precaution to limit testing,
especially test uninterrupted duration.
> When diagnosing "performance issues" I often start by looking
> for retransmissions. Especially for request/response sorts
> of applications, even a single lost TCP segment can ruin the
> whole thing. So, check things like netstat statistics, or
> its platform equivalent. If you can also check link-level
> statistics and statistics at the switch(es) and/or the
> devices joining your LAN's to the MAN.
Always a good idea. Bad/marginal cabling can easily cause
bit errors that usually result in retransmits.
-- Robert
|