Geeks To Go is a helpful hub, where thousands of volunteer geeks quickly serve friendly answers and support. Check out the forums and get free advice from the experts. Register now to gain access to all of our features, it's FREE and only takes one minute. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more.

The error screens are usually accompanied by long response time (resolving host, waiting for... establishing secure connection)
and sometimes the webpages upload only partly and I need to refresh in order to keep them going.

The problem is not permanent. It can happen for an hour and then all is good, or just in the morning
regardless of any configuration modification.

This is a check I ran with ICSI Netalyzr today (displaying error lines only)-

Network performance (?): Latency: 190 ms, Loss: 23.0% –

We recorded a packet loss of 23%. This loss is very significant and will lead to serious performance problems.
It could be due either to very high load on our servers due to a large number of visitors, or problems in your network.
All the packet loss appears to have occurred on the path from our server to your computer.

Your ISP's DNS resolver requires 2000 ms to conduct an external lookup. It takes 200 ms for your ISP's DNS resolver to lookup a name on our server.
This is particularly slow, and you may see significant performance degradation as a result.

This suggests that your network enforces a mandatory SMTP proxy which may or may not allow you to send email directly from your system.
This is probably a countermeasure against malware abusing infected machines for generating spam.
You ISP also likely provides a specific mail server that is permitted. Also, webmail services remain unaffected.

The client received an empty response instead of our normal banner. This suggests that a firewall, proxy,
or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.

Direct TCP connections to remote POP3 servers (port 110) succeed, but do not receive the expected content.
The client received an empty response instead of our normal banner. This suggests that a firewall, proxy,
or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP connections to remote IMAP servers (port 143) succeed, but do not receive the expected content.
The client received an empty response instead of our normal banner. This suggests that a firewall, proxy,
or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.