Just lately, maybe in the last few months, I've had periodic freezes when using google or playing youtube videos. Youtube will seem to hang for 10-30 seconds and then suddenly come to life. Google image searches might fail to load a few images. Nothing major but kind of sounds like there is an underlying problem. I haven't noticed it with anything else, just the google related stuff. Has anyone else noticed this or is it just me? Thanks James
Packet loss? -- My blog http://etbe.coker.com.au Sent from a Galaxy S3 Android phone with K-9 Mail.
Packet loss? --
I can't tell for sure. There are definitely some packets being dropped as seen from SACK packets, but that's expected with inbound policing, and the missing packets are resent in a timely fashion. I'd have to capture quite a lot of packets to see the problem though so I haven't been able to analyse it properly at this time. James
James Harper <james.harper@bendigoit.com.au> writes:
Packet loss? --
I can't tell for sure. There are definitely some packets being dropped as seen from SACK packets, but that's expected with inbound policing, and the missing packets are resent in a timely fashion.
I'd have to capture quite a lot of packets to see the problem though so I haven't been able to analyse it properly at this time.
Making a capture is definitely worth the trouble -- even a large capture is going to be 10s or 100s of MB, especially if you filter it at the libpcap level before you write it out. Also worth glancing at "ip -s l" for anything out of the ordinary. I don't have any specific advice, but I've recently learnt about tshark (wireshark) -z switch to generate stats, and it's handy when I don't already know what to look for. There are a bunch of other things mentioned in Practical Packet Analysis (nostarch press), but the only other one I can remember just now is to toggle the time field between time-since-capture-start and time-since-last-packet, which would make it easy to quickly spot where the gap is. (Re the book, I'd say it's useful to read once, to discover wireshark features, but not worth keeping as a reference text if you already have a good understanding of TCP, IP, UDP, DHCP, DNS, HTTP &c.)
Packet loss? --
I can't tell for sure. There are definitely some packets being dropped as seen from SACK packets, but that's expected with inbound policing, and the missing packets are resent in a timely fashion.
I'd have to capture quite a lot of packets to see the problem though so I haven't been able to analyse it properly at this time.
I've been monitoring this a bit more and have noticed that the freeze's appear to coincide with the appearance of incorrect checksums on outbound packets on the ppp link, which in turn also appear to have SACK options attached. Unless the router (buffalo running openwrt) has building in pppoe checksum offloading, I think I should never see packets with incorrect checksums, so I may be on to something. I'm now simultaneously monitoring both the wlan (where my laptop is) and eth0.2 (pppoe packets go here) in the hope of seeing such a packet coming from my laptop and going out with the bad checksum, but nothing yet. I'm vaguely suspicious that this is a heisenbug. The only time I've seen it is when I've caught it in the middle of a loop like: Here's an ack/sack packet with a bad checksum Hmmm... you didn't get it... here's the same ack/sack packet with a bad checksum I've never seen the above situation develop while I've been monitoring it, only when I start monitoring when it's already developed. OS is Openwrt AA 12.09-rc1 running 3.3.8 kernel. The other alternative is that tcpdump is calculating checksums incorrectly and the actual checksums are fine and the bug is somewhere else. James
I'm asking again, for some reason, does this happen with every browser on every operating system? The reason I ask is that if it's OK on, *for example*, Chrome on Windows I would suggest it *most likely* has less to do with networking and more to do with something on the host layer. It would be very interesting if it does happen with other combinations, not so much if it's just one. On 16/03/13 18:08, James Harper wrote:
Packet loss? -- I can't tell for sure. There are definitely some packets being dropped as seen from SACK packets, but that's expected with inbound policing, and the missing packets are resent in a timely fashion.
I'd have to capture quite a lot of packets to see the problem though so I haven't been able to analyse it properly at this time.
I've been monitoring this a bit more and have noticed that the freeze's appear to coincide with the appearance of incorrect checksums on outbound packets on the ppp link, which in turn also appear to have SACK options attached.
Unless the router (buffalo running openwrt) has building in pppoe checksum offloading, I think I should never see packets with incorrect checksums, so I may be on to something.
I'm now simultaneously monitoring both the wlan (where my laptop is) and eth0.2 (pppoe packets go here) in the hope of seeing such a packet coming from my laptop and going out with the bad checksum, but nothing yet.
I'm vaguely suspicious that this is a heisenbug. The only time I've seen it is when I've caught it in the middle of a loop like: Here's an ack/sack packet with a bad checksum Hmmm... you didn't get it... here's the same ack/sack packet with a bad checksum
I've never seen the above situation develop while I've been monitoring it, only when I start monitoring when it's already developed.
OS is Openwrt AA 12.09-rc1 running 3.3.8 kernel.
The other alternative is that tcpdump is calculating checksums incorrectly and the actual checksums are fine and the bug is somewhere else.
James
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On 11/03/13 18:31, James Harper wrote:
Just lately, maybe in the last few months, I've had periodic freezes when using google or playing youtube videos. Youtube will seem to hang for 10-30 seconds and then suddenly come to life. Google image searches might fail to load a few images. Nothing major but kind of sounds like there is an underlying problem.
I haven't noticed it with anything else, just the google related stuff.
Has anyone else noticed this or is it just me?
Obligatory xkcd reference: http://xkcd.com/619/
On 11.03.13 07:31, James Harper wrote:
Just lately, maybe in the last few months, I've had periodic freezes when using google or playing youtube videos. ...
Has anyone else noticed this or is it just me?
TL;DR: There's a (transitory) fix (worked for me on youtube) at the end. On Ubuntu 10.04.1 LTS I've had similar issues for about a year, but more often on links to ABC and BBC pages. The firefox activity indicator rotates for a quarter of an hour if I let it. On a good night, hitting the reload icon interrupts, bringing the page up within a few seconds. That said, it's stuck on a youtube link now. It has been going for about ten minutes, and is still on 0:00/2:06. Pausing, then hitting Play, doesn't help. Reloading the page containing the link to youtube, and then hitting Play, has now left it spinning fruitlessly for another 5 minutes. Restarting firefox also does not help - another attempt has now been spinning its wheel for a good 5 minutes, with zero progress. The ADSL modem says: Transmit Tx PDUs 15544 Tx Total Bytes 1438042 Tx Total Error Counts 0 Receive Rx PDUs 18250 Rx Total Bytes 20611199 Rx Total Error Counts 0 So I don't think we can blame the line. The Chase: Power cycling the ADSL modem still left firefox hung on the previous page fetch - but subsequently reloading the page, then hitting Play, started the film clip withing a second. That's usually what it takes, in extremis. Then things are good for a while - often the rest of the evening. Sometimes the problem is loss of DNS, and again, rebooting the router/modem fixes that every time. (That's a bit more obvious, though.) Erik -- On the basis of evidence we may be sure that we are wrong but we can never be sure that we are right. - Richard Feynman
Erik Christiansen <dvalin@internode.on.net> wrote:
Sometimes the problem is loss of DNS, and again, rebooting the router/modem fixes that every time. (That's a bit more obvious, though.)
If you have access to hardware, you could try a different router, or the same router temporarily in bridge mode. I've had MTU issues over ADSL; you could try reducing the MTU of the Linux machine temporarily in case that helps (probably not, but... it may be worth mentioning).
On Tue, 12 Mar 2013, Jason White <jason@jasonjgw.net> wrote:
I've had MTU issues over ADSL; you could try reducing the MTU of the Linux machine temporarily in case that helps (probably not, but... it may be worth mentioning).
http://www.linode.com/speedtest/ If there are MTU issues then the problem will probably occur on lots of other sites. A good test site is the Linode speed-test page. A selection of different DCs providing a 100MB test file optimised for best transfer. If that works well then you can rule out lots of different low level problems. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tue, 12 Mar 2013, Jason White <jason@jasonjgw.net> wrote:
I've had MTU issues over ADSL; you could try reducing the MTU of the Linux machine temporarily in case that helps (probably not, but... it may be worth mentioning).
http://www.linode.com/speedtest/
If there are MTU issues then the problem will probably occur on lots of other sites. A good test site is the Linode speed-test page. A selection of different DCs providing a 100MB test file optimised for best transfer. If that works well then you can rule out lots of different low level problems.
Google and youtube (owned by google) are the only two sites I've noticed it on. I wanted to turn on option stripping on the router (openwrt aa) but it seems to be lacking to option stripping target. This would allow me to turn off SACK negotiation which I have seen cause problems before. James
James Harper <james.harper@bendigoit.com.au> wrote:
Google and youtube (owned by google) are the only two sites I've noticed it on.
IPv4 or IPv6? Either way, you could try the other. Both are dual-stack and have AAAA records in DNS.
Both. I turned off IPv6 at home to check. james
On 11/03/13 18:31, James Harper wrote:
Just lately, maybe in the last few months, I've had periodic freezes when using google or playing youtube videos. Youtube will seem to hang for 10-30 seconds and then suddenly come to life. Google image searches might fail to load a few images.
Are you running HTTPS Everywhere by any chance? I'm currently experiencing issues with Google Instant, where searches often need an extra click of the Search button to get results to show. The issue seems to go away when I disable HTTPS Everywhere, although I don't have enough data to blame it just yet.
On 11/03/13 18:31, James Harper wrote:
Just lately, maybe in the last few months, I've had periodic freezes when using google or playing youtube videos. Youtube will seem to hang for 10-30 seconds and then suddenly come to life. Google image searches might fail to load a few images.
Are you running HTTPS Everywhere by any chance? I'm currently experiencing issues with Google Instant, where searches often need an extra click of the Search button to get results to show.
The issue seems to go away when I disable HTTPS Everywhere, although I don't have enough data to blame it just yet.
Everything appears to be https... hadn't considered that as a possibility. Easy enough to test! Thanks James
On 11/03/13 18:31, James Harper wrote:
Just lately, maybe in the last few months, I've had periodic freezes when using google or playing youtube videos. Youtube will seem to hang for 10-30 seconds and then suddenly come to life. Google image searches might fail to load a few images.
Are you running HTTPS Everywhere by any chance? I'm currently experiencing issues with Google Instant, where searches often need an extra click of the Search button to get results to show.
The issue seems to go away when I disable HTTPS Everywhere, although I don't have enough data to blame it just yet.
Everything appears to be https... hadn't considered that as a possibility. Easy enough to test!
Actually thinking about this some more, a long pause in crl checking would cause exactly the sort of symptoms I'm seeing... I wonder if I can turn that off in firefox, I assume so and I'll try turning that off too. That would be much easier to debug! James
James Harper <james.harper@bendigoit.com.au> wrote:
Actually thinking about this some more, a long pause in crl checking would cause exactly the sort of symptoms I'm seeing... I wonder if I can turn that off in firefox, I assume so and I'll try turning that off too.
If you can't find an option to do that, ascertain the name of the CRL server and temporarily associated it with 127.0.0.1 in resolv.conf.
Can you try it with another browser in Linux to narrow down the cause? Chrome is easy to install and remove on Linux - apt-get/yum install chromium-browser etc. On 15/03/13 10:00, Jason White wrote:
James Harper <james.harper@bendigoit.com.au> wrote:
Actually thinking about this some more, a long pause in crl checking would cause exactly the sort of symptoms I'm seeing... I wonder if I can turn that off in firefox, I assume so and I'll try turning that off too. If you can't find an option to do that, ascertain the name of the CRL server and temporarily associated it with 127.0.0.1 in resolv.conf.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Trent W. Buck <trentbuck@gmail.com> wrote:
Nitpick: chrome and chromium are different.
Chrome = Chromium + proprietary extras. Naturally, Chromium is the version provided by Linux distributors. I may be wrong, but my impression is that the distributed versions of Chromium track as closely as possible the publicly available branches that go into Chrome releases.
Quoting Jason White (jason@jasonjgw.net):
Trent W. Buck <trentbuck@gmail.com> wrote:
Nitpick: chrome and chromium are different.
Chrome = Chromium + proprietary extras.
Quibble: Strictly speaking, nobody outside Googlle, Inc. knows for certain all of what, if anything, has been changed in Chrome (relative to the Chromium base code) in addition to adding proprietary additional features and modules, for the simple reason that nobody outside Google, Inc. can inspect the codebase, let alone independently build it. I'm certainly not saying there is any specific reason to suspect Google, Inc. of doing anything untoward under cover of production of uninspectable binaries. (Some might be wary of _any_ firm that did something like purchase DoubleClick for US $3.1B, however, and wonder how much the corporate interests might conflict with one's own.)
participants (9)
-
Erik Christiansen -
James Harper -
Jason White -
Jeremy Visser -
Michael Lindner -
Rick Moen -
Russell Coker -
Toby Corkindale -
trentbuck＠gmail.com