You're pinging hosts outside your LAN. You're almost certainly measuring the performance and reliability of your modem and ISP, not your laptop.
Try pinging your modem or another computer at home. You should see ping times less than 10 milliseconds, no matter the packet size. FYI, ping uses ICMP, not UDP. Carl Cole wrote: > Hi Larry, > > I have overstated my case. I haven't tried it enough to see a consistent > pattern. > > Searching the internet regarding Mike's RxIntDelay suggestion, a > consistent thread was that the ping time varied widely. Mine doesn't do > that. I found at least one thread where someone found that large pings > succeeded where small pings failed. In my case, if there is any trend, > it is that large pings fail, but I can't give you a definitive answer. > > For example tonight: > ping www.slashdot.org (64 bytes ~91 ms) > ping www.slashdot.org -s 2000 (2008 bytes ~122 ms) > ping www.slashdot.org -s 4000 (4008 bytes ~156 ms) > > However Firefox sat and sat and sat looking for www.slashdot.org. It > finally came in, perhaps after 10 minutes. > > Perhaps, ping (UDP?) works fine, but but TCP has a bug? How can I test > this? Or large packets vs small packets? > > Another case: > ping www.co.linn.or.us (64 bytes ~72 ms) > ping www.co.linn.or.us -s 2000 (no response) > > Does this mean something about my machine? Compare to www.google.com, > which gives a 64 byte response to any query I have tried. > > Almost exclusively, I have tried this from home. My home network > consists of a QWest DSL modem and a Linksys 10/100 Workgroup Switch. I > have a Debian computer that networks just fine. My son has a WinXP > computer that has no problems. Both computers communicate to a networked > printer. My hunch is that the basic network works. However, I am not a > network guru. I am happy to learn from you. What am I looking for with > tracepath? > > The RxIntDelay discussions that I found mentioned the problem with > version 2.6.17 kernels. It appears there is/was a timing problem with > the E1000 driver, and adding the delay may mitigate the problem. In > later kernels, something else was fixed with the E1000, and the hope was > that this RxIntDelay problem was fixed along with it, but the posters > hadn't actually identified the problem, so they weren't sure. They also > thought a BIOS update might fix it. My computer shows the updated BIOS. > > My SLED has a version 2.6.16 kernel. I am not familiar with SLED. If I > can get connected long enough, I may try to update to SP2. > > Or it may be time to try another distro, possibly one with a newer > kernel. I have Knoppix and Fedora live cd's to try, but it is getting > late for me -- no more time to try them tonight. And little time > tomorrow. However, Thursday and Friday evenings I may be available to > look into a few things. > > Thanks for the input. So far, the mystery continues. > > Regards, > > Carl Cole > > > larry price wrote: >> On Mon, Sep 15, 2008 at 10:09 PM, Carl Cole <[EMAIL PROTECTED]> wrote: >> >> >>> Small pings work consistently, but large pings generally don't. So far, no >>> fix. I will look into this further. >>> >> >> Is this true on every network you connect to, or just some? >> >> Can you pin down the exact size at which pings start failing? >> >> This really sounds like MTU size is misset on the router. >> >> what does /usr/bin/tracepath tell you? >> _______________________________________________ >> EUGLUG mailing list >> [email protected] >> http://www.euglug.org/mailman/listinfo/euglug >> >> > > _______________________________________________ > EUGLUG mailing list > [email protected] > http://www.euglug.org/mailman/listinfo/euglug -- Bob Miller K<bob> [EMAIL PROTECTED] _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
