Is anyone else noticing that downloading images on the forums became a *lot* slower since this year-ish?
Even at work where we have an insanely fast connection the forums are as slow as at home, so there seems to be a bottleneck somewhere.
Ulco, if you read this, does it also take you 5-10 seconds to load an image here?
That's about how long it takes for me, too but I guess that I wouldn't call it excessively slow. I'm in the States and Planetside is based in the U.K. I'm supposing. So possibly yes, there may be something that prevents an instantaneous reaction.
It may be server related. I know that I would limit the bandwidth of serving images or files considering the nature and size of them (someone could put up a near 5mb image).
I didn't notice it, Martin. Jpg's like 1900x1200 load in half a second here. May also depend on your own provider? I'm on a simple phoneline from KPN, no glass fibre, but still pretty fast.
Yeah, to add, I don't really notice a slowdown. Images from the forum open in a popup window for me most the time (sometimes a download), but when I click the window, even for a 1080p window, it's loaded already. And I use cellular 4G internet off my phone in a rural area -- in general my latency is high but download is decent at about 1 - 5mbps (20mbps peak during a random blue moon)
Png's are another matter; they load slowly because they're heavier, and I remember staff not really appreciating clogging up the server with those heavy files.
Me neither. No slowdown. Only at work, when I-net connection is really lazy. Maybe it's a question of some maintenance period Tangled Universe. I mean, of course applicable only if your work and home have the same provider!
Quote from: Dune on October 12, 2018, 02:11:19 AM
Png's are another matter; they load slowly because they're heavier, and I remember staff not really appreciating clogging up the server with those heavy files.
It's just a image. If the max is 5mb it's to be expected. They are the best web format for quality preservation. Even a max quality jpeg creates jpeg artefacts. For little details and stuff it can get in the way. For example night sky's look like garbage in JPG.
You're right, I know the quality issue. But for some images it's just not necessary to show the very very best, and use unnecessary space. In busy renders you won't see the artifacts at a casual look. It's not to be printed or so. But of course 5Mb = 5Mb.
We are no longer based in the UK, and the server has been hosted in the US for... oh about a decade. :D No maintenance issues that I'm aware of, certainly not consistent ones. And although we switched servers less than a year ago, it was an upgrade, and not to a different host. We've been on the same host in the same datacenter for several years now. So nothing on that side that could explain the issues you're seeing.
I just downloaded an 845MB file from the server at an average of 14MB (that's *bytes" not *bits*) per second. It took about a minute to download nearly a gig. :D I'm on symmetric gigabit here in the Bay Area, California, US. So the bandwidth to the server itself probably isn't an issue. However the route to your ISP may not be great Martin. I can't test that easily, but you could. Do a ping test to start, and maybe a tracert, to our server. See what comes up. For me it's about like this:
Ping average: around 60ms
For comparison Google is 3ms, Adobe.com is a surprising ~150ms (after repeated tests).
Tracert shows 20 hops, which is kind of a lot considering I'm in the US already. To be fair 8 of those are within my ISP though and are very low latency, and hops to Google are 16, so not much better (and yet 3ms ping time, so all is well there). Curious what you'll come up with.
The other thing is anecdotally I have noticed more PNGs, large JPGs, etc. over the past year or two. So it's possible that your expectation of "it's only a 1920x1080 image, it should load faster" is sometimes not aligning with reality just because someone chose to save a 3MB image at that resolution, which is entirely unnecessary in 99% of cases.
- Oshyan
I don't have 20 hops, but I do have timeouts along the way, and the latency is pretty high for connections. I'm in Seattle though. Pretty sure the first route is my phone and subsequent unonfigured nginx.
Also when you post cmd results in a code bracket, the forum says the post is empty, even though the text above was there...
If I ping to LA I get 167ms and tracert to your server is 101ms. That's not very good, is it?
Thanks Oshyan for clarifying and suggesting to ping/tracert.
I performed a ping once and a tracert twice and especially the tracert is interesting.
Something's off at hop 6.
Perhaps I should ask my ISP (Ziggo, do you also use that Ulco?).
What's HOP? No, I'm at KPN.
Ulco, a hop is basically each step the traffic goes server to server over the web.
Would you be willing to perform a tracert as well?
Quote from: Tangled-Universe on October 14, 2018, 06:20:30 AM
Thanks Oshyan for clarifying and suggesting to ping/tracert.
I performed a ping once and a tracert twice and especially the tracert is interesting.
Something's off at hop 6.
Perhaps I should ask my ISP (Ziggo, do you also use that Ulco?).
I also timeout on hop 6 haha
Mind you, your ISP may not be able to help, as this is long outside the realm of your ISP, and part of another ISP/Server. In rare cases your network may be partially down, which could prevent DNS handshakes with certain servers in certain regions. Similar to when a domain is migrating to a new host, as the DNS go online, it has access to more of the net. The same thing could be happening at hop 6, it's network is having issues.
I do notice though, it seems once you hit that second Atlas server, the rest of the hops are all pretty slow up to 20 hops.
Hop 6 is before Amsterdam, which is our exchange connecting to the USA through Atlas.
So I think something is going on in my country before the connection gets overseas.
That yours is bogging down at hop 6 is coincidence I'd guess.
Quote from: Tangled-Universe on October 14, 2018, 04:28:10 PM
Hop 6 is before Amsterdam, which is our exchange connecting to the USA through Atlas.
So I think something is going on in my country before the connection gets overseas.
That yours is bogging down at hop 6 is coincidence I'd guess.
Of course, hence the laughing.
I'll also note you're piping through aorta.net which is known for their network troubles. That first hop could just be a dead aorta server which is... frequent. I actually once had to move a friends server to my data-center because of his global reach problem.
I should note that not all servers in a tracert will necessarily respond to this request. I see request timeouts all the time. Heck, try cnn.com, I get a timeout on hop 8, but their server itself responds just fine and the site loads, of course.
Also, no 150ms is not terrible for overseas to US. Not great either. But it shouldn't be causing really long site load times.
- Oshyan
Quote from: Oshyan on October 14, 2018, 06:35:05 PM
I should note that not all servers in a tracert will necessarily respond to this request. I see request timeouts all the time. Heck, try cnn.com, I get a timeout on hop 8, but their server itself responds just fine and the site loads, of course.
Also, no 150ms is not terrible for overseas to US. Not great either. But it shouldn't be causing really long site load times.
- Oshyan
They should. The only reason they didn't, is they are overloaded via traffic, the packet was sent to the control brain (as apposed to data) and thus dropped because it's flagged priority (to not interfere with hardware). In that case, that hop in a traffic forwarding scenario can drop, or hang, and possibly timeout.
A firewall issue where the server just doesn't respond to this would cause the Tracert to end, and it would not note the trace being
complete but
aborted. Subsequently though a completely dead server (not just dead network wise during that tracert) would also case an aborted tracert.
However because it's complete, the packet was sent, and went through, the servers router was just having issues. These packets are sent three times consecutively. So if all three fail, but the rout is complete, it's definitely a routing issue, rather than a dead route.
This is also why high priority data centers use an actual server as a "Core" router, and often allow these low priority packets, that way if it's sent to via the control plane route, it is handled for debugging purposes. Such as gaming nodes. Physical routers have virtually no computing power and
should drop these packets when it's under load.
It's very probable that hop is hanging, and causing the slowdown when actually processing taffic data. I get straight timeout pages a lot on here, but it's not a speed issue, just network routing. I'm also not sure using CNN and high-traffic routes are good comparisons. It's likely you'd see dropped packets considering consecutive traffic to that destination.
Your understanding differs from mine. Tracert is basically pinging all servers from you to a destination server and requesting a response. If a server is configured to not respond to ping (ICMP) requests, it will time out. Many servers are configured this way for security or other reasons and will thus result in a timeout. ICMP is also generally a low priority request so yes, congestion may also result in a timeout. I've seen one or two timeouts in many tracerts I've run over the years, it seldom indicated an issue, and often persisted over many routes to the same end point. It almost certainly indicated a server that was configured not to respond for whatever reason.
From Microsoft themselves:
Quote
Request Timed Out
This message indicates that no Echo Reply messages were received within the default time of 1 second. This can be due to many different causes; the most common include network congestion, failure of the ARP request, packet filtering, routing error, or a silent discard.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc940095(v=technet.10)
Additionally, from ServerFault:
Quote
Routers can be configured to not respond with an ICMP message that traceroute depends on. Also, MPLS can do that because it is not routing, it is label switching.
When a router needs to create an ICMP message to send back to the source host, that is a low priority task that it may no get around to in time. Also, some router administrators don't want their busy routers to even need to spend cycles doing that, so they disable it altogether. It could also be that network administrators don't want to give away that information.
So a timeout on a *single* host may not mean anything at all.
Quote
There is only one real instance when a timeout on a traceroute is a bad thing. That is when you see timeouts that continue forward in the route. By that I mean when you see an individual timeout and then many more after that. There are two main instances when this can happen, the first and most common is that there is a firewall that was configured to block these packets in the route. The other instance is that a router is dropping packets going THROUGH it (i.e. Forwarding Plane(arms) packets) and this is can be a VERY bad sign. This is usually caused by one of three reasons either the router is overloaded, the router having a software or physical failure or the router is configured to do this(null route/blackholes).
https://www.hostdime.com/resources/trace-routes-timeouts/
- Oshyan
Quote from: Oshyan on October 14, 2018, 11:45:25 PM
Your understanding differs from mine. Tracert is basically pinging all servers from you to a destination server and requesting a response. If a server is configured to not respond to ping (ICMP) requests, it will time out. Many servers are configured this way for security or other reasons and will thus result in a timeout. ICMP is also generally a low priority request so yes, congestion may also result in a timeout. I've seen one or two timeouts in many tracerts I've run over the years, it seldom indicated an issue, and often persisted over many routes to the same end point. It almost certainly indicated a server that was configured not to respond for whatever reason.
From Microsoft themselves:
Quote
Request Timed Out
This message indicates that no Echo Reply messages were received within the default time of 1 second. This can be due to many different causes; the most common include network congestion, failure of the ARP request, packet filtering, routing error, or a silent discard.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc940095(v=technet.10)
Additionally, from ServerFault:
Quote
Routers can be configured to not respond with an ICMP message that traceroute depends on. Also, MPLS can do that because it is not routing, it is label switching.
When a router needs to create an ICMP message to send back to the source host, that is a low priority task that it may no get around to in time. Also, some router administrators don't want their busy routers to even need to spend cycles doing that, so they disable it altogether. It could also be that network administrators don't want to give away that information.
So a timeout on a *single* host may not mean anything at all.
Quote
There is only one real instance when a timeout on a traceroute is a bad thing. That is when you see timeouts that continue forward in the route. By that I mean when you see an individual timeout and then many more after that. There are two main instances when this can happen, the first and most common is that there is a firewall that was configured to block these packets in the route. The other instance is that a router is dropping packets going THROUGH it (i.e. Forwarding Plane(arms) packets) and this is can be a VERY bad sign. This is usually caused by one of three reasons either the router is overloaded, the router having a software or physical failure or the router is configured to do this(null route/blackholes).
https://www.hostdime.com/resources/trace-routes-timeouts/
- Oshyan
What you're failing to understand is if the router doesn't handle ICMP requests, the
entire tracert command aborts, so it would end there, and you'd know there is a firewall block/routing loop/misconfiguration at that router. "Traceroute proceeds unless all (three) sent packets are lost more than twice, then the connection is lost and the route cannot be evaluated" Wikipedia (https://en.wikipedia.org/wiki/Traceroute). If the three pings are lost, it tries again, if those three requests fail, it aborts.
It can't get to the next host if it's been blocked, which is why the command aborts..
For example, if I do not use my VPN, and use MetroPCS, tracert will be blocked by the first route, and abort, as my ISP doesn't allow ICMP requests.
Most servers in the commercial world don't block ICMP requests or even UDP or TCP requests of the echo nature, because of debugging concerns of networks and global reach.
And it's simply by about 1000 fold, that the router is just ignoring the request and passing it through (control path) rather than replying, because it's busy. When it hits the control path on a physical router it will almost 100% of the time be dropped unless it's idle. In fact without custom roms I don't think you can even change this low priority behavior unless using a actual server as a core firewall for the data center / network. This is because the CPU of a router is designed specifically for it's data path usage and has hardly any control path power.
We're still reading and understanding this stuff differently, it seems (including Wikipedia). A server can be configured to forward the packet but not send an ICMP response to a ping request on timeout. If a hop fails, it does *not* kill the sequence inherently (that's obvious because, uh, look at Martin's screenshot, there are servers that follow it). Rather, the tracert function sends another request with an incremented TTL and the server that didn't send back a response to ping may *still* forward that request to the *next* server.
Your update to the reply above basically agrees now with what I'm saying:
QuoteWhen it hits the control path on a physical router it will almost 100% of the time be dropped unless it's idle. In fact without custom roms I don't think you can even change this low priority behavior unless using a actual server as a core firewall for the data center / network. This is because the CPU of a router is designed specifically for it's data path usage and has hardly any control path power.
That right there says that a timeout is *not* necessarily indicative of any problem - of a part of the route that is "not working right or unusually slow" - because most routers are not going to be idle.
- Oshyan
Quote from: Oshyan on October 15, 2018, 12:19:45 AM
We're still reading and understanding this stuff differently, it seems (including Wikipedia). A server can be configured to forward the packet but not send an ICMP response to a ping request on timeout. If a hop fails, it does *not* kill the sequence inherently (that's obvious because, uh, look at Martin's screenshot, there are servers that follow it). Rather, the tracert function sends another request with an incremented TTL and the server that didn't send back a response to ping may *still* forward that request to the *next* server.
Your update to the reply above basically agrees now with what I'm saying:
QuoteWhen it hits the control path on a physical router it will almost 100% of the time be dropped unless it's idle. In fact without custom roms I don't think you can even change this low priority behavior unless using a actual server as a core firewall for the data center / network. This is because the CPU of a router is designed specifically for it's data path usage and has hardly any control path power.
That right there says that a timeout is *not* necessarily indicative of any problem - of a part of the route that is "not working right or unusually slow" - because most routers are not going to be idle.
- Oshyan
The timeout is because their is no response, not because the request has been altogether blocked. The request continued on it's path. That's why the wikipedia specifies a second attempt if all three timeout and it can't continue on it's route (which you can see in your network activity). If it continues on it's route, there is no need to try again, and just list the timeouts, as it got no reply.
A firewall will either accept or not accept these packages. If it doesn't accept them, the route is blocked at that point. I'm not aware of any "Deny but Reply" flag. It's based on a 0/1 flag. You can reroute the request somewhere else that would reply. But none of that helps diagnose network issues and isn't a standard thing to do in the least. An example of this is my old host datashack, you could not ICMP the data-center, but they would pass-through to a specific server if that was the destination.
A router also can handle tons (like enough to handle networks like Facebook and such) of data paths, so if it's getting to the control path, inherently, it's blogged down, Oshyan. If requests are constantly hitting the control path and relying on priority, there is most certainly a network issue and the router is overloaded.
Additionally, here is a couple more tracerts to planetside and you can see hop 6 (with networklayer) I get a timeout, but not always, but than again, I get timeouts visiting planetside occasionally for no reason almost immediately, and that server could be the reason unless planetside is going down occasionally briefly, but likely, like most the time, it's a network thing.
132ms and a timeout at hop 7.... ???