Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-09

Server availability

9 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alexander Klenin
Jonas Maebe wrote 10 lines
On 06 Sep 2011, at 11:46, Alexander Klenin wrote: > Can something be done to speed up the bugtracker? > I have just given up waiting for the bug page to load, > and just parroted the URL back to the freepascal.ru. Right after I sent my mail the server was rebooted for some reason, and the web server didn't respond for a while. I'm pretty sure it works fine if you try now (it does for me anyway).

Unfortunately, this is not so.
For example, right now I am waiting for bug_report_advanced_page.php for more then 5 minutes already.

From the traceroute, it seems that the server is hosted at someone's

home, connected by DSL?
Additionally, IP resolves back to "idefix.wise.be" site, which displays a message regarding
disk failure -- no idea if this message is currect or outdated.

For at least last few months, I write down bugs I encounter in the local file, since by the time the "Report Issue" page loads, I forget what I wanted to report.
I suspect the server is severely overloaded.

Alexander S. Klenin

Reply by email

Jonas Maebe
to Alexander Klenin
Alexander Klenin wrote 12 lines
On Tue, Sep 6, 2011 at 20:57, Jonas Maebe wrote: > > Right after I sent my mail the server was rebooted for some reason, > and the > web server didn't respond for a while. I'm pretty sure it works > fine if you > try now (it does for me anyway). Unfortunately, this is not so. For example, right now I am waiting for bug_report_advanced_page.php for more then 5 minutes already.

It loads almost immediately here (5 seconds).

From the traceroute, it seems that the server is hosted at someone's home, connected by DSL?

No, it's hosted at a company. It's a commercial dsl connection (I don't know by heart what the bandwidth is).

Additionally, IP resolves back to "idefix.wise.be" site, which displays a message regarding disk failure -- no idea if this message is currect or outdated.

It's a relic from a very long time ago.

Show quoted text 5 lines
For at least last few months, I write down bugs I encounter in the local file, since by the time the "Report Issue" page loads, I forget what I wanted to report. I suspect the server is severely overloaded.

In general, not really. It does run out of memory sometimes (we're not sure of the cause; both mantis and mysql have been pointed at as potential culprits), but right now it has a load of 0.14 and 4.8GB free memory (out of 8GB, with 1.8GB used as cache).

Jonas

Reply by email

Alexander Klenin
to Jonas Maebe
Jonas Maebe wrote 11 lines
> For at least last few months, I write down bugs I encounter in the local > file, > since by the time the "Report Issue" page loads, I forget what I > wanted to report. > I suspect the server is severely overloaded. In general, not really. It does run out of memory sometimes (we're not sure of the cause; both mantis and mysql have been pointed at as potential culprits), but right now it has a load of 0.14 and 4.8GB free memory (out of 8GB, with 1.8GB used as cache).

Hm. This may be an issue with my provider then.
However, the only site affected is freepascal.org, which is very strange. Will try to call the provider to investigate.

Alexander S. Klenin

Reply by email

Jonas Maebe
to Alexander Klenin
Alexander Klenin wrote
Hm. This may be an issue with my provider then. However, the only site affected is freepascal.org, which is very strange. Will try to call the provider to investigate.

There is one known problem: the server is behind a brain dead firewall, which drops most icmp packets (except for ping). This includes the "fragmentation needed" packets used for path mtu discovery (http://www.networksorcery.com/enp/rfc/rfc1191.txt).

We have enabled TCP-based mtu discovery (http://tools.ietf.org/html/rfc4821 ), but it appears to be slower. Alternatively, you can try to clamp the maximum segment size of all tcp connections manually: http://lartc.org/howto/lartc.cookbook.mtu-mss.html (try 1400 or so, and work up from there). It will slightly reduce the efficiency of your connection though (for all tcp connections, also to other servers).

Jonas

Reply by email

Unknown author
to Jonas Maebe
Jonas Maebe wrote 11 lines
On 06 Sep 2011, at 13:24, Alexander Klenin wrote: > Hm. This may be an issue with my provider then. > However, the only site affected is freepascal.org, which is very strange. > Will try to call the provider to investigate. There is one known problem: the server is behind a brain dead firewall, which drops most icmp packets (except for ping). This includes the "fragmentation needed" packets used for path mtu discovery (http://www.networksorcery.com/enp/rfc/rfc1191.txt).

If there is a firewall, it is at the ISP.

The server itself is located before the company firewall.

Maybe the router drops the icmp packets.

Michael.

Reply by email

Nikolai Zhubr
to Alexander Klenin: Hm. This may be an issue with my provider then. However, the only site affected is…

06.09.2011 15:24, Alexander Klenin:

Show quoted text 17 lines
On Tue, Sep 6, 2011 at 22:17, Jonas Maebe wrote: >> For at least last few months, I write down bugs I encounter in the local >> file, >> since by the time the "Report Issue" page loads, I forget what I >> wanted to report. >> I suspect the server is severely overloaded. > > In general, not really. It does run out of memory sometimes (we're not sure > of the cause; both mantis and mysql have been pointed at as potential > culprits), but right now it has a load of 0.14 and 4.8GB free memory (out of > 8GB, with 1.8GB used as cache). > Hm. This may be an issue with my provider then. However, the only site affected is freepascal.org, which is very strange. Will try to call the provider to investigate.

Just checked: right now mantis seems rather quick for me, at least for reading. I'd say it shows up immediately. (St.Petersburg)

HTH

Nikolai

Reply by email

Alexander Klenin
to Jonas Maebe: There is one known problem: the server is behind a brain dead firewall, which drops most…
Jonas Maebe wrote 12 lines
There is one known problem: the server is behind a brain dead firewall, which drops most icmp packets (except for ping). This includes the "fragmentation needed" packets used for path mtu discovery (http://www.networksorcery.com/enp/rfc/rfc1191.txt). We have enabled TCP-based mtu discovery (http://tools.ietf.org/html/rfc4821), but it appears to be slower. Alternatively, you can try to clamp the maximum  segment size of all tcp connections manually: http://lartc.org/howto/lartc.cookbook.mtu-mss.html (try 1400 or so, and work up from there). It will slightly reduce the efficiency of your connection though (for all tcp connections, also to other servers).

I am on Windows, so I have enabled EnablePMTUBHDetect parameter instead, as per http://support.microsoft.com/kb/314053

It have helped somewhat -- now instead of waiting for the full page, half of the page is downloaded, and then the waiting starts. I am not a TCP expert, so have no idea what may cause this.

Alexander S. Klenin

Reply by email

Jonas Maebe
to Alexander Klenin
Alexander Klenin wrote 7 lines
I am on Windows, so I have enabled EnablePMTUBHDetect parameter instead, as per http://support.microsoft.com/kb/314053 It have helped somewhat -- now instead of waiting for the full page, half of the page is downloaded, and then the waiting starts. I am not a TCP expert, so have no idea what may cause this.

You can also try changing the MTU (the "Tcpip\Parameters\Interfaces\ID for Adapter" key according to that same page) to e.g. 1400. Then things will probably start working fine.

Jonas

Reply by email

Micha Nelissen
to Jonas Maebe: There is one known problem: the server is behind a brain dead firewall, which drops most…
Jonas Maebe wrote
There is one known problem: the server is behind a brain dead firewall, which drops most icmp packets (except for ping). This includes the "fragmentation needed" packets used for path mtu discovery (http://www.networksorcery.com/enp/rfc/rfc1191.txt).

$ ping -s 1472 idefix.wisa.be
1480 bytes from svn.freepascal.org (62.166.198.202): icmp_seq=1 ttl=48 time=186 ms
1480 bytes from svn.freepascal.org (62.166.198.202): icmp_seq=2 ttl=48 time=256 ms
1480 bytes from svn.freepascal.org (62.166.198.202): icmp_seq=3 ttl=48 time=321 ms
1480 bytes from svn.freepascal.org (62.166.198.202): icmp_seq=4 ttl=48 time=111 ms
1480 bytes from svn.freepascal.org (62.166.198.202): icmp_seq=5 ttl=48 time=87.7 ms

works for me ... so MTU does not seem to be lowered, at least using the path I use. Maybe you're on a different path that does have lower MTU somehow? Can you try the same command?

Regards, Micha

Reply by email