08-22-2008, 05:23 PM
|
 Re: http grief
Rich Walsh writes:
>
> I'm surprised MTU size was the problem but I can't argue with success.
> However, the choice of 576 may not be optimal.
>
> Formerly, you were using 1500 byte packets, now you're using 576 byte
> packets. This means more overhead and a lower throughput - effectively,
> a slower connection. You may find that setting MTU to 1492 or 1488
> resolves the issue while giving you a "faster" connection.
The situation so far: 576 is totally stable, over hours of active use and
left overnight with a couple of auto-refreshing news sites.
Various values in the 1400 range, including 1492, cause loss of web access
on the same tests sites as before, pretty much at the same rate (loading a
page or two after the switch.)
The various tips on how to recover after that do not work: "setup.cmd"
and/or "tcpstart.cmd" have no effect; "route -n flush" kills all tcp/ip
services and neither "setup.cmd" nor "tcpstart.cmd" have any effect. The
only solution is to reboot.
Is there a way to test the maximum mtu with ping or something similar, as
described in http://www.dslreports.com/faq/695 for instance? It looks like
OS/2 ping either does not fragment packets, or does so silently, even in
debug or verbose modes.
> If your ISP's tech support seems to be fairly knowledgable, you may want
> to ask them if 1492 doesn't work.)
I did and am awaiting the answer. They are very good, but have no
experience with OS/2.
Pierre
--
Pierre Jelenc
The Gigometer www.web-ho.com/gigs.html
The NYC Beer Guide www.nycbeer.org
 |