Codeberg/Community
54
325
Fork
You've already forked Community
12

Feedback Regarding Connection Speed to Codeberg.org #2188

Open
opened 2025年10月26日 16:59:43 +01:00 by january1073 · 8 comments

Comment

Hi All,

I wanted to share some feedback regarding the connection speed I experienced when accessing Codeberg pages. During recent testing, I noticed slightly higher latency compared to GitHub Pages.

Here are the ping results for reference:

Codeberg Page:

`user@ubuntu:~ $ ping -c 5 january1073.codeberg.page
PING january1073.codeberg.page (2a0a:4580:103f:c0de::2) 56 data bytes
64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=1 ttl=60 time=25.5 ms
64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=2 ttl=60 time=39.9 ms
64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=3 ttl=60 time=25.7 ms
64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=4 ttl=60 time=26.7 ms
64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=5 ttl=60 time=26.0 ms

--- january1073.codeberg.page ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 25.453/28.770/39.943/5.601 ms`

GitHub Pages:

`user@ubuntu:~ $ ping -c 5 january1073.github.io
PING january1073.github.io (2606:50c0:8003::153) 56 data bytes
64 bytes from 2606:50c0:8003::153: icmp_seq=1 ttl=60 time=19.5 ms
64 bytes from 2606:50c0:8003::153: icmp_seq=2 ttl=60 time=17.2 ms
64 bytes from 2606:50c0:8003::153: icmp_seq=3 ttl=60 time=16.3 ms
64 bytes from 2606:50c0:8003::153: icmp_seq=4 ttl=60 time=16.0 ms
64 bytes from 2606:50c0:8003::153: icmp_seq=5 ttl=60 time=19.2 ms

--- january1073.github.io ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 16.042/17.647/19.452/1.433 ms`

I understand that network performance can vary due to many factors, but I wanted to share this observation in case it's helpful for your ongoing optimization efforts.

Thank you for your work on Codeberg!

Best,

january1073

### Comment Hi All, I wanted to share some feedback regarding the connection speed I experienced when accessing Codeberg pages. During recent testing, I noticed slightly higher latency compared to GitHub Pages. Here are the ping results for reference: **Codeberg Page:** `user@ubuntu:~ $ ping -c 5 january1073.codeberg.page PING january1073.codeberg.page (2a0a:4580:103f:c0de::2) 56 data bytes 64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=1 ttl=60 time=25.5 ms 64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=2 ttl=60 time=39.9 ms 64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=3 ttl=60 time=25.7 ms 64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=4 ttl=60 time=26.7 ms 64 bytes from 2a0a:4580:103f:c0de::2: icmp_seq=5 ttl=60 time=26.0 ms --- january1073.codeberg.page ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms **rtt min/avg/max/mdev = 25.453/28.770/39.943/5.601 ms`** **GitHub Pages:** `user@ubuntu:~ $ ping -c 5 january1073.github.io PING january1073.github.io (2606:50c0:8003::153) 56 data bytes 64 bytes from 2606:50c0:8003::153: icmp_seq=1 ttl=60 time=19.5 ms 64 bytes from 2606:50c0:8003::153: icmp_seq=2 ttl=60 time=17.2 ms 64 bytes from 2606:50c0:8003::153: icmp_seq=3 ttl=60 time=16.3 ms 64 bytes from 2606:50c0:8003::153: icmp_seq=4 ttl=60 time=16.0 ms 64 bytes from 2606:50c0:8003::153: icmp_seq=5 ttl=60 time=19.2 ms --- january1073.github.io ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms **rtt min/avg/max/mdev = 16.042/17.647/19.452/1.433 ms`** I understand that network performance can vary due to many factors, but I wanted to share this observation in case it's helpful for your ongoing optimization efforts. Thank you for your work on Codeberg! Best, january1073

These test differences are propably caused by the locations of the corresponding datacenters. Your github pages site is probably hosted on a global cdn with datacenters near your.

These test differences are propably caused by the locations of the corresponding datacenters. Your github pages site is probably hosted on a global cdn with datacenters near your.

Thanks for your fast reply. I am located in Germany, near Frankfurt. Github's CDN servers should not be so much nearer than Codeberg's so that it would explain a discrepancy of on average more than 10 ms?

Thanks for your fast reply. I am located in Germany, near Frankfurt. Github's CDN servers should not be so much nearer than Codeberg's so that it would explain a discrepancy of on average more than 10 ms?

I checked it again with traceroute:

  • The connection to Github goes directly to the US and takes 8 hops (screenshot 1).
  • The connection to Codeberg also goes to the US, then via a few routers that don't send any information, and then back to Berlin, Germany; a total of 13 hops.

Strange, isn't it? Can someone explain this to me?

I checked it again with traceroute: * The connection to Github goes directly to the US and takes 8 hops (screenshot 1). * The connection to Codeberg also goes to the US, then via a few routers that don't send any information, and then back to Berlin, Germany; a total of 13 hops. Strange, isn't it? Can someone explain this to me?

@january1073

are you really doing a traceroute from your local machine or using some weird "web tool" 2020s style?

(just use traceroute from your shell)

@january1073 are you really doing a traceroute from your local machine or using some weird "web tool" 2020s style? (just use traceroute from your shell)

@ashimokawa: yes, I was doing traceroute from a weird web tool. sorry.

because:

my shell gives me this (see also the attached screenshot):

traceroute to january1073.codeberg.page (217.197.84.141), 64 hops max
 1 192.168.2.1 7.602ms 8.515ms 7.252ms 
 2 62.155.246.126 12.916ms 14.603ms 16.247ms 
 3 62.153.188.102 22.774ms 23.951ms 22.612ms 
 4 185.1.74.3 22.778ms 23.810ms 21.228ms 
 5 * * * 
 6 * * * 
 7 * * * 
 8 * * * 
 9 * * * 
 10 * * * 
 11 * * * 
 12 * * * 
 13 * * * 
 14 * * * 
 15 * * * 
 16 * * * 
 17 * * * 
 18 * * * 
 19 * * * 
 20 * * * 
 21 * * * 
 22 * * * 
 23 * * * 
 24 * * * 
 25 * * * 
 26 * * * 
 27 * * * 
 28 * * * 
...

someone an idea what is going on when I try to reach codeberg's server from here, frankfurt area?

@ashimokawa: yes, I was doing traceroute from a weird web tool. sorry. because: my shell gives me this (see also the attached screenshot): ```user@ubuntu:~ $ traceroute january1073.codeberg.page traceroute to january1073.codeberg.page (217.197.84.141), 64 hops max 1 192.168.2.1 7.602ms 8.515ms 7.252ms 2 62.155.246.126 12.916ms 14.603ms 16.247ms 3 62.153.188.102 22.774ms 23.951ms 22.612ms 4 185.1.74.3 22.778ms 23.810ms 21.228ms 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * ... ``` someone an idea what is going on when I try to reach codeberg's server from here, frankfurt area?

@january1073
By using the "web tool" you traced from the site of that web tool, not from you.
Some routers block ICMP probes, that is why you see that output. you can try TCP SYN instead

sudo traceroute -T january1073.codeberg.page
@january1073 By using the "web tool" you traced from the site of that web tool, not from you. Some routers block ICMP probes, that is why you see that output. you can try TCP SYN instead ``` sudo traceroute -T january1073.codeberg.page ```

May I add my view on this?
Looking into this issue myself.

Facts:
codeberg.page is hosted on codeberg-infrastructure running at IN-Berlin, connected to the BCIX.
gh-pages is hosted on a Fastly cache which is placed close or in the network of your ISP.

Outcome:
Therefore the performance of gh-pages is always faster and codeberg cannot compete.


~# sudo traceroute -T6A january1073.github.io
traceroute to january1073.github.io (2606:50c0:8003::153), 30 hops max, 80 byte packets
 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.313 ms 0.277 ms *
 2 * 2a02:<redacted> (2a02:<redacted>) [AS3209] 9.799 ms *
 3 * * 2a02:<redacted> (2a02:<redacted>) [AS3209] 17.969 ms
 4 * * *
 5 * 2620:11a:c000:627:fa57:: (2620:11a:c000:627:fa57::) [AS54113] 19.420 ms *
 6 2606:50c0:8003::153 (2606:50c0:8003::153) [AS54113] 19.293 ms * *
~# sudo traceroute -T6A january1073.codeberg.page
traceroute to january1073.codeberg.page (2a0a:4580:103f:c0de::2), 30 hops max, 80 byte packets
 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.621 ms 0.463 ms 0.581 ms
 2 2a02:<redacted> (2a02:<redacted>) [AS3209] 12.658 ms * *
 3 <redacted> (2a02:<redacted>) [AS3209] 14.235 ms * *
 4 * * *
 5 * * *
 6 * * *
 7 bcix.gw-ak-1.in-berlin.de (2001:7f8:19:1::73e6:1) [*] 41.522 ms * *
 8 2a0a:4580:103f:c0de::2 (2a0a:4580:103f:c0de::2) [AS29670] 27.728 ms * *
root@dns-trixie:~# 
May I add my view on this? Looking into this issue myself. Facts: `codeberg.page` is hosted on codeberg-infrastructure running at IN-Berlin, connected to the BCIX. `gh-pages` is hosted on a Fastly cache which is placed close or in the network of your ISP. Outcome: Therefore the performance of `gh-pages` is always faster and codeberg cannot compete. ``` ~# sudo traceroute -T6A january1073.github.io traceroute to january1073.github.io (2606:50c0:8003::153), 30 hops max, 80 byte packets 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.313 ms 0.277 ms * 2 * 2a02:<redacted> (2a02:<redacted>) [AS3209] 9.799 ms * 3 * * 2a02:<redacted> (2a02:<redacted>) [AS3209] 17.969 ms 4 * * * 5 * 2620:11a:c000:627:fa57:: (2620:11a:c000:627:fa57::) [AS54113] 19.420 ms * 6 2606:50c0:8003::153 (2606:50c0:8003::153) [AS54113] 19.293 ms * * ~# sudo traceroute -T6A january1073.codeberg.page traceroute to january1073.codeberg.page (2a0a:4580:103f:c0de::2), 30 hops max, 80 byte packets 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.621 ms 0.463 ms 0.581 ms 2 2a02:<redacted> (2a02:<redacted>) [AS3209] 12.658 ms * * 3 <redacted> (2a02:<redacted>) [AS3209] 14.235 ms * * 4 * * * 5 * * * 6 * * * 7 bcix.gw-ak-1.in-berlin.de (2001:7f8:19:1::73e6:1) [*] 41.522 ms * * 8 2a0a:4580:103f:c0de::2 (2a0a:4580:103f:c0de::2) [AS29670] 27.728 ms * * root@dns-trixie:~# ```

@goetz wrote in #2188 (comment):

May I add my view on this? Looking into this issue myself.

Facts: codeberg.page is hosted on codeberg-infrastructure running at IN-Berlin, connected to the BCIX. gh-pages is hosted on a Fastly cache which is placed close or in the network of your ISP.

Outcome: Therefore the performance of gh-pages is always faster and codeberg cannot compete.


~# sudo traceroute -T6A january1073.github.io
traceroute to january1073.github.io (2606:50c0:8003::153), 30 hops max, 80 byte packets
 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.313 ms 0.277 ms *
 2 * 2a02:<redacted> (2a02:<redacted>) [AS3209] 9.799 ms *
 3 * * 2a02:<redacted> (2a02:<redacted>) [AS3209] 17.969 ms
 4 * * *
 5 * 2620:11a:c000:627:fa57:: (2620:11a:c000:627:fa57::) [AS54113] 19.420 ms *
 6 2606:50c0:8003::153 (2606:50c0:8003::153) [AS54113] 19.293 ms * *
~# sudo traceroute -T6A january1073.codeberg.page
traceroute to january1073.codeberg.page (2a0a:4580:103f:c0de::2), 30 hops max, 80 byte packets
 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.621 ms 0.463 ms 0.581 ms
 2 2a02:<redacted> (2a02:<redacted>) [AS3209] 12.658 ms * *
 3 <redacted> (2a02:<redacted>) [AS3209] 14.235 ms * *
 4 * * *
 5 * * *
 6 * * *
 7 bcix.gw-ak-1.in-berlin.de (2001:7f8:19:1::73e6:1) [*] 41.522 ms * *
 8 2a0a:4580:103f:c0de::2 (2a0a:4580:103f:c0de::2) [AS29670] 27.728 ms * *
root@dns-trixie:~# 

Thanks, @goetz, for your research and reply. That helps me to understand the issue.

@goetz wrote in https://codeberg.org/Codeberg/Community/issues/2188#issuecomment-8289650: > May I add my view on this? Looking into this issue myself. > > Facts: `codeberg.page` is hosted on codeberg-infrastructure running at IN-Berlin, connected to the BCIX. `gh-pages` is hosted on a Fastly cache which is placed close or in the network of your ISP. > > Outcome: Therefore the performance of `gh-pages` is always faster and codeberg cannot compete. > > ```text > > ~# sudo traceroute -T6A january1073.github.io > traceroute to january1073.github.io (2606:50c0:8003::153), 30 hops max, 80 byte packets > 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.313 ms 0.277 ms * > 2 * 2a02:<redacted> (2a02:<redacted>) [AS3209] 9.799 ms * > 3 * * 2a02:<redacted> (2a02:<redacted>) [AS3209] 17.969 ms > 4 * * * > 5 * 2620:11a:c000:627:fa57:: (2620:11a:c000:627:fa57::) [AS54113] 19.420 ms * > 6 2606:50c0:8003::153 (2606:50c0:8003::153) [AS54113] 19.293 ms * * > > ~# sudo traceroute -T6A january1073.codeberg.page > traceroute to january1073.codeberg.page (2a0a:4580:103f:c0de::2), 30 hops max, 80 byte packets > 1 2a02:<redacted> (2a02:<redacted>) [AS3209] 0.621 ms 0.463 ms 0.581 ms > 2 2a02:<redacted> (2a02:<redacted>) [AS3209] 12.658 ms * * > 3 <redacted> (2a02:<redacted>) [AS3209] 14.235 ms * * > 4 * * * > 5 * * * > 6 * * * > 7 bcix.gw-ak-1.in-berlin.de (2001:7f8:19:1::73e6:1) [*] 41.522 ms * * > 8 2a0a:4580:103f:c0de::2 (2a0a:4580:103f:c0de::2) [AS29670] 27.728 ms * * > root@dns-trixie:~# > ``` Thanks, @goetz, for your research and reply. That helps me to understand the issue.
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure

Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers

Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support

This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#2188
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?